Using external metadata

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`.

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.

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, nor it is reproduced in snapcraft 3.0

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, I would like to request changing the behavior to match with setuptools.


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

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

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

@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”)


…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!

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?

1 Like

I took a stab at a PR for this here:

1 Like

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 .

Any Idea why is this happening ?

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

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

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?
1 Like

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.


common-id: com.example.sampleapp

The desktop ID should end with .desktop if the docs read right

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.

@sergiusens, have I found a bug?

My snapcraft yaml (snippet):

adopt-info: openra

    common-id: openra-cnc.desktop

    common-id: openra-d2k.desktop

    common-id: openra-ra.desktop

    ... # no common id
    ... # no common id
    ... # no common id

    - usr/local/share/appdata/openra-cnc.appdata.xml
    - usr/local/share/appdata/openra-d2k.appdata.xml
    - usr/local/share/appdata/openra-ra.appdata.xml

This installs three appdata/metainfo files with the IDs of:

  1. openra-cnc.desktop
  2. openra-d2k.desktop
  3. openra-ra.desktop

When I run snapcraft I am returned the following warnings:

Priming openra 
The 'description' and 'summary' properties are specified in adopted info as well as the YAML: taking the properties from the YAML
Common ID None specified in app 'ra-server' is not used in any metadata file.
Common ID None specified in app 'd2k-server' is not used in any metadata file.
Common ID 'openra-d2k.desktop' specified in app 'd2k' is not used in any metadata file.
Common ID 'openra-cnc.desktop' specified in app 'cnc' is not used in any metadata file.
Common ID None specified in app 'cnc-server' is not used in any metadata file.
Snapping 'openra' |                                                
Snapped openra_release-20190314_amd64.snap

Note how it seems it only matched the last entry in parse-info against the common-ids that I have set on each of the three apps. This seemingly means that the cnc and d2k apps aren’t matched against their respective appdata/metainfo files.

This might indeed be a bug as we do not support multiple common-ids as most of the time there was supposed to be on appstream entry per snap as was the assumption made in 2017 when we started this. We will need to dedicate cycles to get this working.

The common-id property should match the id specified in the AppStream metadata file. The .desktop suffix is optional in that file, so it depends on the AppStream metadata file whether you should include the .desktop suffix in common-id or not.