Snapcraft.yaml schema

I have a few more snapcraft keywords that don’t appear to be listed here:

  • aliases (might be deprecated/obsolete)
  • completer
  • bus-name
  • activates-on
  • daemon-scope

You can cross-check against https://github.com/snapcore/snapcraft/blob/main/snapcraft/projects.py#L236

Brilliant, thank you - I’ll make sure they’re added/investigated and I’ll update this comment when they’re done.

yes, this is obsolete, I wouldn’t bother documenting at this point

this is part of an experimental feature (user services)

1 Like

I think that might be the entirety of my proofreading.

For items like parts.<part-name>.organize, can we add to the description in which environment the file path in the key exists? For example with stage, I think it would be “In the key/value pair, the key represents the path of a file inside the part install directory and the value represents how the file is going to be staged”? This took some trial and error to figure out when doing an override-build first so I knew where to put my build artifacts to be reached by organize

Is there an error in the docs here: https://snapcraft.io/docs/snapcraft-yaml-reference ?

parts.<part-name>.parse-info Type: string but snapcraft refuses it as string, it wants list.

Thank for flagging this. I think you’re correct - I’ve updated the doc.

1 Like

Seems like for parts.<part-name>.source-type, a few of the allowed enum values get cut off and replaced by an ellipsis ... when viewing the documentation through snapcraft.io:

I figured tar would be an acceptable source type, but I could only verify this by clicking to view the discourse page instead. Could we potentially change the page setting so that longer code blocks are not truncated and replaced with an ellipsis and instead wrap to the next line?

Thanks so much for pointing this out. Something must have changed in the way we render the table. I’ll chase this up and get this fixed asap. Thanks!

The possible values for the snap’s type are different between these docs:

The latter does not include ‘core’ as a possible snap type. Also, there seems to be no separate page devoted to the explanation of the snaps with the type core.

The “core” type is historical and only used for the “core” snap. No other snap should sport the “core” type. I’m not even sure snapcraft can build a “core” snap, I know the core snap itself is not built using snapcraft. This is for context, not saying that our docs shouldn’t be clearer on this.

1 Like

Thanks for the added context (and the original query). I’ve now added notes to both of those documents to say that the core type has been deprecated.

cc @dmitry.lyfar

1 Like

I noticed that it is possible to set global environment variables for a snap via environment key in snapcraft.yaml, but it isn’t documented. This is very useful, because these environment variables propagate to all hooks and apps with fewer repetition.

The meta/snap.yaml file for a core22 based snap has the following:

environment:
  LD_LIBRARY_PATH: ${SNAP_LIBRARY_PATH}${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}
  PATH: $SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH

The current drawback when making changes to the above two variables via snapcraft.yaml is that the snap loses the additions made by snapcraft.

1 Like

Hello! Thanks so much for mentioning this, and you’re absolutely right. I have added this now, but I’ve also created a todo task to cover global environment variables in more detail.

1 Like

The documentation for apps. <app-name>. restart-condition is broken, other values besides on-failure are cut off: “Defaults to on-failure. Other values are `[on-failure”.

1 Like

Good spot - thank you for letting us know. We needed to escape the pipe character.

Also the string beginning with “bzr”, I submitted an edit.

Perfect, thanks for making the edit!

I believe filesets have been dropped ? [ for ref: Snapcraft filesets ]

Not only are they still mentioned here, they are the main source of reference for how to use the stage and prime part keywords, which seems a bit confusing now.

Cheers, Just

I performed some fairly major maintenance work on this topic.

I consolidated all the information from:

onto this page, filling any gaps between them. I made sure to resolve any contradictions between this source and the others. The format had to change as a result – a single long table resulted in scrolling without navigation, and it wasn’t an enjoyable experience.

I also gave it a new title to better reflect what readers will find here.

We plan to provide updates to the schema and its formatting in due time.

1 Like