Adding parts

When building a snap with Snapcraft, parts are used to describe your application, where its various components can be found, its build and run-time requirements, and those of its dependencies. Consequently, a snap always has one or more parts.

A part’s definition within snapcraft.yaml is purposely flexible to allow for varied and disparate sources.

At its simplest, a part will locate a project’s source code and to invoke a plugin to build and deploy the consequent application within your snap environment. But a part can equally be used to source and unpack a binary executable from an RPM file, or override into the correct location.

A part can also download tagged code from a remote repository, pull in dependencies, define a build order, and completely override both the snapcraft build and the snapcraft stage phases of the process.

For more details on how parts are built within the snapcraft environment, including build stages and the directories they use, see Parts lifecycle.

Defining a part

The snapcraft init command creates the following part template in snapcraft.yaml:

parts:
  my-part:
    # See 'snapcraft plugins'
    plugin: nil

A part starts with an arbitrary name, such as my-part, which is followed by enough Snapcraft parts metadata to build the functionality you require.

The core of a typical part will commonly consist of the following metadata:

  • plugin Used to simplify and accelerate your build on commonly used frameworks and platforms. A plugin will often add, and may require, its own additional metadata. See Snapcraft plugins for more details. Examples: python, go, java, cmake, autotools
  • source The location of the file or files needed to build your part. It can refer to a directory tree, a compressed archive, or a revision control repository.
    Examples: ., https://github.com/coderholic/pyradio.git, gnu-hello.tar.gz
  • build-packages A list of the packages required to build your part. Package names are those used by the build host’s package manager, such as apt or dnf. Examples: [pkg-config, libncursesw5-dev, sed ]
  • build-snaps A list of the snaps required to build your part. Snap names can include track and channel options (<track>/<risk>/<branch>). Examples: [go/1.16/stable, kde-frameworks-5-core18-sdk]
  • stage-packages A list of the packages required by your part to run. Package names are those used by the build host’s package manager, such as apt or dnf. Examples: [gnome-themes-standard, libncursesw5, dbus]
  • stage-snaps A list of the snaps required by your part to run. As with build-snaps, you can optionally add the track and channel of the snaps you wish to include. Examples: [ffmpeg-sdk-gplv3, codium/latest/stable]

As per the YAML specification, the members of a list in snapcraft.yaml can be formatted in either of the following ways:

build-packages: [g++, make, git, sed]

build-packages:
- g++
- make
- git
- sed

For help on working out which packages you need for both building and staging your snap, take a look at Build and staging dependencies, and see Snapcraft parts metadata for a complete list of supported parts keywords.

Parts can also be sourced from shell scripts outside of the snapcraft.yaml. See Overrides for details.

Given that the bullet point about build-packages mentions, “Package names are those used by the build host’s package manager, such as apt or dnf.”, perhaps the following bullet point about stage-packages should mention a couple different examples other than the same apt and dnf.

Is there a reason that the list of metadata includes build-packages and stage-packages, but not build-snaps and stage-snaps?

1 Like

No, these were missed after an update to add support - thanks for letting us know.

Issue 1

There are some grammatical issues in this bullet here. Note the double usage of “can,” and the missing period after “revision control repository.” Also, the sentence is a run-on. Could be changed to the following:

source The location of the file or files needed to build your part. It can refer to a directory tree, a compressed archive, or a revision control repository. Examples: ., https://github.com/coderholic/pyradio.git, gnu-hello.tar.gz

Issue 2

Looks like there is an extraneous comma after said. We could add another package, or just remove the extra comma:

build-packages A list of the packages required to build your part. Package names are those used by the build host’s package manager, such as apt or dnf. Examples: [pkg-config, libncursesw5-dev, sed]

Other than that, I did not see any other issues!

1 Like

Also, not sure on this one, but do we think it might be beneficial if we change this from revision control repository to version control repository.

If you search “revision control repository,” the search results pull up the GNU RCS version control system, which might confuse some people learning snap. It might be more beginner friendly to use version control system since most users building snaps would likely be familiar with git.

1 Like

Thanks so much for taking to the time to make these (great) corrections/suggestions. I’ve updated the doc to include them.