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.
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:
[pkg-config, libncursesw5-dev, sed, ]
[gnome-themes-standard, libncursesw5, dbus]
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.
Last updated 11 months ago. Help improve this document in the forum.