Snap packages: What is the purpose of the "staging" and "priming" steps?

Question

I have successfully created and uploaded a snap package (the tutorials are great). However, I am left wondering what exactly happens during each of the build steps and how I might take advantage of them.

The process seems to be pull -> build -> stage -> prime -> snap.

By my observation, it appears "pull" puts files in the parts/<part name>/src/ folder, "build" puts files in the parts/<part name>/build/ folder, "stage" puts files in the stage/ folder and "prime" puts files in the prime/ and parts/<part name>/install/ folder.

As a novice, I would tell you I start with a snapcraft.yaml file, I call snapcraft and I get a snap; a one step process. I know each "part" has a stage: and prime: section, but I don't know how or why to take advantage of these steps. The only thing I have found useful is install: along with $SNAPCRAFT_PART_INSTALL environment variable available to the snapcraft.yaml file.

What do the stage: and prime: sections allow me to do that can't achieve with install: and $SNAPCRAFT_PART_INSTALL?

Answer 1

As a novice, I would tell you I start with a snapcraft.yaml file, I call snapcraft and I get a snap; a one step process.

That's fair, and if your snaps are relatively simple, this may be all you ever need! But you were right-on when determining the lifecycle steps: they are, in order;

1. Pull

   The pull step happens per-part. This is where the source* (source, source-tag, etc.) properties are utilized. If source is pointing at a git repo, it'll clone it, etc.

2. Build

   The build step happens per-part. This is where the source pulled in the previous step is built. This is done in a part-specific directory so it happens in isolation, but they can build against the contents of the staging area (the "stage" directory) in case you have inter-part dependencies (using the after keyword to tell snapcraft that the dependency needs to be staged before building the dependent part).

3. Stage

   The stage step happens per-part. This is the first time all the disparate parts that make up the snap are actually placed in the same area (the "stage" directory). If multiple parts are providing the same file with differing contents, Snapcraft doesn't know which one you want. This is where the stage keyword comes into play. You can white- or black-list files coming from the part to avoid conflicts when staging the parts together (or for any other reason you might not want those files in the staging area).

4. Prime

   The prime step also happens per-part. This is very similar to the stage step, but files go into the priming area instead of the staging area. This exists because the staging area may contain header files and similar things necessary to build dependent parts, but one may not want those files to end up in the final snap. To this end, you have another filtering keyword called prime to create a white- or black-list for files coming from that part to be primed.

5. Snap

   The snap step is not per-part. This step runs after all parts have been primed, at which time the prime directory contains all data and metadata necessary to run as a snap. This step literally just calls mksquashfs on the prime directory for you.

Note that each of these lifecycle steps can be run individually for all or individual parts, and they can be cleaned as well.

• Run specific step for all parts: snapcraft <step>, e.g. snapcraft build.
• Run specific step for a single part: snapcraft <step> <part>
• Clean specific step for all parts: snapcraft clean -s <step>, e.g. snapcraft clean -s build
• Clean specific step for a single part: snapcraft clean <part> -s <step>.

I hope that answered your question. For more information look at the Snapcraft lifecycle documentation. The stage and prime keywords are also further explained in the parts metadata documentation.