Using external metadata


#4

Thanks for the clarifications :slight_smile: That all sounds rather tasty nomnomnom

No, I think that makes sense now that you’ve blown the cobwebs from my brain :-p


#5

I wonder if it’s possible to adopt the git describe version from the adopt-info specified part’s source repo when the version key is also set with the value git


#6

I think something like that is available or in the work, cc @sergiusens


#7

Can you clarify? In the meantime I will explain what is already there.

version: git

Works, it is just very opinionated on release tags, from the git man page:

Annotated tags are meant for release while lightweight tags are meant
for private or temporary object labels. For this reason, some git
commands for naming objects (like git describe) will ignore lightweight
tags by default.

For this and other reasons we now have snapcraftctl set-version <version> which can be used in any part and can be picked up by àdopt-info`.


#8

I would like to use the version: git like version string, but instead of describing the recipe containing repo, make it describe the part’s source repo according to the adopt-info key’s value. The described version is enough for me and I want to avoid calling snapcraftctl set-version <version> when possible.


#9

I’ve encountered a problem that in snapcraft 2.43.1(snap) the snapcraftctl command can’t be called in a script called in a override-pull scriptlet:

Pulling hello 
Cloning into '/root/build_hello-snapcrafters/parts/hello/src'...

...

/root/build_hello-snapcrafters/parts/hello/src/../../../snap/local/utilities/set-snap-version.bash: line 35: snapcraftctl: command not found
Failed to run 'override-pull': Exit code was 127.

This issue isn’t reproduced in build.snapcraft.io, nor it is reproduced in snapcraft 3.0


#10

According to the setuptools documentation the description key is equivalent to Snapcraft’s summary key and the long_description key is equivalent to Snapcraft’s description key, however currently Snapcraft uses the description key’s value as the snap description and ignores the long_description key in setup.py, I would like to request changing the behavior to match with setuptools.

UPDATE: Bug #1813364 “The setup.py parse-info method treats description/long_description keys wrongly” : Bugs : Snapcraft


#11

Hi, good catch, if you would want to work on this it would be welcomed!


#12

I’d like to, but unfortunately I’m currently not technically capable of doing so as I don’t speak either Python or Go…


#13

@degville hey, I asked this by other means, it may have been missed due to that, the ask is, can we get this on the main docs somehow? When I asked, it wasn’t even searchable (using the same query which yields results here on the forum: “adopt-info”)


#14

…sorry, this must have fallen off my radar. But yes, definitely. I’ll get it added and make sure it’s returned in the search results. Thanks for the prod!


#15

It looks to me as though there’s a missing metadata source: deb package information.

It isn’t hard to parse the output from, say, apt-cache policy and use snapcraftctl but I can’t be the only one doing that?


#16

I took a stab at a PR for this here: https://github.com/snapcore/snapcraft/pull/2518


#17

I am trying to use scriptlets to set the version for my snap. The build fails every once in a while with Failed to generate snap metadata: 'adopt-info' refers to part 'my-part', but that part is lacking the 'parse-info' property. . I am running snapcraft v3.5 and building on Ubuntu 16.04 with my base set to core. If I clean only the part (python) that is causing this failure and re run snapcraft, the build goes fine and a snap is generated.

Here is my override-pull

override-pull: |
      snapcraftctl pull
      snapcraftctl set-version "$(python3 -c 'from mypackage import version; print(version.__version__)')"

I am referring https://docs.snapcraft.io/using-external-metadata#meta-scriptlet .

Any Idea why is this happening ?


#18

Does this only happen when “re-running” or on first run?


#19

Happens on the first run or any clean run, If I clean the part and build again the build goes through.


#20

One thing missing from the description of the parse-info key is a description of how the metadata file is located.

  • Is it expected to be in the part’s src directory? The build directory? Or the install directory? If it searches multiple locations, which takes precedence?
  • At which step of the build process is the metadata extracted?

#21

The order is:

  • src at the end of pull
  • build at the end of build
  • install at the end of build

Each step updates the previous one. I will encode this in the docs.


#22

common-id: com.example.sampleapp

The desktop ID should end with .desktop if the docs read right
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s02.html#desktop-file-id


#23

No, the common-id is the ID itself, not the name of the .desktop file. The ID in appstream files is what gets matched by this attribute, and that is defined without the .desktop suffix.