Snapcraft.yaml reference

doc
21

Oh, now I noticed that this topic is actually mentioned in The snapcraft format - Documentation for snaps: Universal Linux packages:

%E5%9C%96%E7%89%87
%E5%9C%96%E7%89%87962×307 34.5 KB

though I’m still questioning the necessity of maintaining two separate documents with the same/similar content.

22

I do agree. As the new reference material is both in a new format and split into categories, we were waiting for feedback before removing or fully deprecating the large single reference page. A good moment for this may be when we bring over the REST API reference material which will need to be split in a similar way.

1 Like
23

I keep attempting to use this document as a reference, and I keep finding out that many of the references are deprecated (It is very prominent in Google searches). This is very frustrating.

1 Like
24

I think that this page is missing command-chain

1 Like
25

Thanks! I’ve just added the missing details.

26

I think this page is also missing stop-mode

27

title and license don’t work.

Issues while validating snapcraft.yaml: Additional properties are not allowed (‘license’, ‘title’ were unexpected)

28

What’s the difference between this page and snapcraft-top-level-metadata?

29

It’s the same information formatted as a single page with the other metadata. This is mentioned in the first line, but we could perhaps make it clearer.

1 Like
30

@degville should remove “legacy” adapter and “full”. Default is “full”, so the only really interesting bit is “none”.

However adapter will be dropped altogether for core 20 and its use is quite limited. @sergiusens suggests removing it altogether.

1 Like
31

Thanks for the updates - I’ll make those changes.

Please feel free to edit docs yourself though. Anyone can make modifications, and we want to encourage people to do so. I always look over whatever has changed to keep it consistent.

2 Likes
32

I’m new here and saw this a while ago.

For the apps.<app-name>.command description, Classic Confinement should point to here.

33

Hello - welcome to the forum, and thanks for flagging this. The link should be fixed now.

34

We should add the top-level environment here as well, since it works not just for an app but globally in the snapcraft.yaml (in which case it ends up applying to all of the apps in the generated snap.yaml)

35

is autostart correct? It’s in the parts.<partname> stanza? I thought it was an apps.<appname> item!

See: How to autostart a snap of a desktop application?

1 Like
36

Thanks for spotting this and letting us know! You’re right - it should be in apps., as described in Snapcraft app and service metadata. I’ll fix it now. Edit: fixed.

1 Like
37

Is package-repositories available to use now?

38

Thanks for flagging this - yes, it became available with snapcraft 4.3. I’ll update the docs !

Update: I’ve just tried a simple snap with Snapcraft 4.3 and package-repositories and it seems the feature is still flagged as experimental (it needs the --enable-experimental-package-repositories flag). I’ll ask the Snapcraft team for an ETA on this feature being stable.

3 Likes
39

In the parts.<part-name>.source-subdir section, I think it would be useful to add a note that if you use this, then your build will not have access to files outside the subdir (like one level up for instance).

Otherwise it might seem that using source-subdir is equivalent to cd’ing to the relative directory in an override-build step, when that is not the case.

1 Like
40

The version field is not really mandatory, in fact, if you use adopt-info you should not use it. Maybe it could be written as mandatory*, and then have an explanation in the description, like this:

* This field is normally mandatory, except if you use adopt-info. See Using external metadata for more details.

1 Like