See Adding parts for a general overview of what parts are and how to use them.
All parts within a project, by means of the logic encoded the plugins they’re using, all go through the same series of steps. Knowing these steps, and which directories are used for each step, can help when creating more advanced snaps, and when troubleshooting build issues.
The steps a part goes through are as follows:
- pull: downloads or otherwise retrieves the components needed to build the part
- build: constructs the part from the previously pulled components
- stage: copies the built components into the a staging area, from where they can be exposed to other parts
- prime: copies the built and exposed components into their final locations for the resulting snap
Each of these lifecycle steps can be run from the command line, and the command can be part specific or apply to all parts in a project:
snapcraft pull [<part-name>]
snapcraft build [<part-name>]
snapcraft stage [<part-name>]
snapcraft prime [<part-name>]
The above steps are automatically chained together when running
snapcraft to build a snap with a single command.
To access the part environment at any stage, add the
--shell argument. For example,
snapcraft prime --shell will run up to the prime step and open a shell. See Iterating over a build for more details.
Each lifecycle step depend on the completion of the previous step, which means to reach the desired lifecycle step, all prior lifecycle steps need to have successfully run.
Parts can also depend on each other, effectively creating a dependency chain from one part to another. Use the
after keyword in
snapcraft.yaml to expose this functionality:
grv: plugin: go go-channel: 1.11/stable after: - libgit2
In the above example, the part named ‘grv’ will be built after the part named
libgit2 has been successfully built and staged.
A plugin’s default behaviour for a stage can be replaced by using either of the following:
override-<step-name>in *snapcraft.yaml. See Overriding steps for more details.
- a local plugin. This can inherit he parent plugin or scaffolding from the original. See Local plugins) for more details.
See Parts environment variables for a list of part-specific environment variables that can be accessed to help build a part.
When running through its build stages, a part will use different working directories. These closely follow the stage names for the lifecycle:
- parts//src: the location of the source during the pull step
- parts//build: the working directory during the build step
- parts//install: a private directory for install components during the build step
- stage: shared by all parts, this directory contains the development libraries, headers, and other components (e.g.; pkgconfig files) that need to be accessible from other parts
- prime: also shared across all parts, this directory holds the final components for the resulting snap.