These are the release notes for Snapcraft 3.0, a major overhaul of the snap build environment.
For general details, including installation instructions, see Snapcraft overview, or take a look at Snapcraft release notes for other Snapcraft releases.
This release adds specific build environments for each snapcraft project you work on. These environments are tuned for each project, and ensure both API and ABI compatibility are in place for every binary built within each respective environment.
Snapcraft’s build environments leverage a snap architecture feature called bases. At build time, the snapcraft tool ensures you are creating your applications inside an environment specifically tailored for the specified base.
To make the transition to Snapcraft 3.0 easy, the entire functionality for this new tool behavior is triggered by making use of the base
keyword in snapcraft.yaml
.
Snapcraft 3.0 also remains backwards compatible. This means you can omit the base
keyword and continue working as you did previously until you are ready to move to a newer or different stack provided by a different base.
The environment runs in a container, which means it’s isolated from the user during normal operation. However, the following commands enable you to step into this encapsulated environment:
--shell
: builds your snap to the lifecycle step prior to that specified and opens a shell into the environment (e.g. running snapcraft prime --shell
will run up to the stage
step and open a shell).--shell-after
: builds your snap to the lifecycle step specified and opens a shell into the environment. (eg. running snapcraft prime --shell-after
will run up to the prime
step and then drop into a shell).--debug
, opens a shell inside the environment after an error occur.The below video shows an example of how the system behaves with the new functionality in place:
With this release of Snapcraft 3.0, we are happy to announce support for macOS via Homebrew. Moreover, the experience is transparent thanks to the use of build environments and its underlying technology.
See Install snapcraft on macOS for further details.
When using the base
keyword in snapcraft.yaml
the following (long deprecated) features become unavailable:
/
in parts.snapcraft cleanbuild
and triggering builds with LXD in certain environment variables.prepare
, build
and install
in parts. These have been replaced by override-build
and snapcraftctl
. These offer override-
for pull
, stage
and prime
too.snap
keyword has been superseded by the prime
keyword.--disable-parallel-build
is no longer available when calling build commands through snapcraft. It can be setup, per part, using the build-attributes
property.--use-geoip
is no longer available when calling build commands through snapcraft. This affected stage-packages
.In addition to the above, the following plugins also become unavailable when using the base
keyword:
tar-content
, superseded by the dump
plugin.copy
, superseded by the dump
plugin.jhbuild
, it has too many dependencies against core
.The following are new when using base
:
A snap’s license can now be defined using the new license keyword and a SPDX 2.0 format value within snapcraft.yaml.
Validation of the license syntax is done using snap pack
schema validation to ensure consistency across the snap ecosystem.
When originally introduced, wrappers were useful when setting up the environment appropriately. However, the runtime architecture has now evolved in such a way that wrappers no longer make sense.
Although it is not the default today, the intention is to make the adapter
value (full
) the default behaviour. The advantage with this design is that when entering a shell through snap run --shell
, the environment would be properly loaded through use of command-chain
entries in snap.yaml
.
The recording below shows how the original command
, defined in snapcraft.yaml
, is still the command
that makes it to snap.yaml
(and the command-chain
feature is used instead):
The architecture and framework has been cemented into the snapcraft
tool to help snapcraft.yaml grow declarative* functionality we’re calling Extensions. We have done this to avoid repetitive tasks, and to avoid snap builders needing deep knowledge of a target software stack.
Extensions have the unique property of being applied to snapcraft.yaml
itself, where they can be expanded upon and, potentially, used in lieu of the extension itself. This would allow for project-specific modifications of the extension.
You can interact with extensions using the following new commands:
list-extensions
, to view the available extensions.extension
, to show information about the extension.expand-extensions
, to display how the snapcraft.yaml
will look like with the extensions applied.Prior to Snapcraft 3.0, you needed to manually clean any part that was found to be dirty due to modifications in the code itself, or because modifications had been made to the part definition in snapcraft.yaml
. This become an unnecessary burden for developers.
The default action for snapcraft to now rebuild parts, either by re-running a lifecycle step without cleaning, for plugins that allow for it (through their underlying architecture), or automatically cleaning and re-running the necessary lifecycle steps for that part.
You can see this in action below:
Previously, if a part did not specify a source, an implicit default source of .
was set by default. This caused considerable confusion.
Starting with Snapcraft 3.0, if a plugins requires a source to be specified, it will be required through the schema and an appropriate error message will be generated.
For plugins where a source isn’t a requirement, such as nil
, no action will be taken and no default will be set.
With the exception of deprecated and removed plugins, the majority of plugins have been reworked to be base
aware.
Since the declaration of the base
keyword is done manually by the user, some plugins have introduced semantic changes for how they operate.
Below is the set of plugins with interesting changes and new properties available to the user:
These are the properties the ant
plugin now operates with:
- ant-properties:
(object)
A dictionary of key-value pairs. Set the following properties when
running ant.
- ant-build-targets:
(list of strings)
Run the given ant targets.
- ant-version:
(string)
The version of ant you want to use to build the source artifacts.
Defaults to the current release downloadable from
https://archive.apache.org/dist/ant/binaries/.
- ant-version-checksum:
(string)
The checksum for ant-version in the form of <digest-type>/<digest>.
As an example "sha512/2a803f578f341e164f6753e410413d16ab60fab...".
- ant-openjdk-version:
(string)
openjdk version available to the base to use. If not set the latest
version available to the base will be used.
catkin
These are the properties the catkin
plugin now operates with:
- catkin-packages:
(list of strings)
List of catkin packages to build.
- source-space:
(string)
The source space containing Catkin packages. By default this is 'src'.
- include-roscore:
(boolean)
Whether or not to include roscore with the part. Defaults to true.
- rosinstall-files:
(list of strings)
List of rosinstall files to merge while pulling. Paths are relative to
the source.
- recursive-rosinstall:
(boolean)
Whether or not to recursively merge/update rosinstall files from fetched
sources. Will continue until all rosinstall files have been merged.
Defaults to false.
- catkin-cmake-args:
(list of strings)
Configure flags to pass onto the cmake invocation from catkin.
- underlay:
(object)
Used to inform Snapcraft that this snap isn't standalone, and is actually
overlaying a workspace from another snap via content sharing. Made up of
two properties:
- build-path:
(string)
Build-time path to existing workspace to underlay the one being built,
for example '$SNAPCRAFT_STAGE/opt/ros/kinetic'.
- run-path:
(string)
Run-time path of the underlay workspace (e.g. a subdirectory of the
content interface's 'target' attribute.)
- catkin-ros-master-uri:
(string)
The URI to ros master setting the env variable ROS_MASTER_URI. Defaults
to http://localhost:11311.
go
These are the properties the go
plugin now operates with:
- go-channel:
(string, default: latest/stable)
The Snap Store channel to install go from. If set to an empty string,
go will be installed using the system's traditional package manager.
- go-packages:
(list of strings)
Go packages to fetch, these must be a "main" package. Dependencies
are pulled in automatically by `go get`.
Packages that are not "main" will not cause an error, but would
not be useful either.
If the package is a part of the go-importpath the local package
corresponding to those sources will be used.
- go-importpath:
(string)
This entry tells the checked out `source` to live within a certain path
within `GOPATH`.
This is not needed and does not affect `go-packages`.
- go-buildtags:
(list of strings)
Tags to use during the go build. Default is not to use any build tags.
godeps
These are the properties the godeps
plugin now operates with:
- go-channel:
(string, default: latest/stable)
The Snap Store channel to install go from. If set to an empty string,
go will be installed using the system's traditional package manager.
- go-packages:
(list of strings)
Go packages to build/install, these must be a "main" package.
Dependencies should have already been retrieved by the `godeps-file`
used for this part.
Packages that are not "main" will not cause an error, but would
not be useful either.
- godeps-file:
(string)
Path to the godeps dependencies file contained within the source
(default: dependencies.tsv)
- go-importpath:
(string)
This entry tells the checked out `source` to live within a certain path
within `GOPATH`. This is required in order to work with absolute imports
and import path checking.
gradle
These are the properties the gradle
plugin now operates with:
- gradle-options:
(list of strings)
Flags to pass to the build using the gradle semantics for parameters.
The 'jar' option is always passed in as the last parameter.
- gradle-output-dir:
(string; default: 'build/libs')
The output directory where the resulting jar or war files from gradle[w]
are generated.
- gradle-version:
(string)
The version of gradle you want to use to build the source artifacts.
Defaults to the current release downloadable from
https://services.gradle.org/distributions/
The entry is ignored if gradlew is found.
- gradle-version-checksum:
(string)
The checksum for gradle-version in the form of <digest-type>/<digest>.
As an example "sha512/2a803f578f341e164f6753e410413d16ab60fab...".
- gradle-openjdk-version:
(string)
openjdk version available to the base to use. If not set the latest
version available to the base will be used.
meson
These are the properties the meson
plugin now operates with:
- meson-version:
(string)
The version of meson to install from PyPI.
If unspecified, the latest released version of meson will be used.
- meson-parameters:
(list of strings)
Pass the given parameters to the meson command.
nodejs
These are the properties the nodejs
plugin now operates with:
- nodejs-version:
(string)
The version of nodejs you want the snap to run on.
This includes npm, as would be downloaded from https://nodejs.org
Defaults to the current LTS release.
- nodejs-package-manager
(string; default: yarn)
The language package manager to use to drive installation
of node packages. Can be either `npm` or `yarn` (default).
- nodejs-yarn-version:
(string)
Applicable when using yarn. Defaults to the latest if not set.
python
These are the properties the python
plugin now operates with:
- requirements:
(list of strings)
List of paths to requirements files.
- constraints:
(list of strings)
List of paths to constraint files.
- process-dependency-links:
(bool; default: false)
Enable the processing of dependency links in pip, which allow one
project to provide places to look for another project
- python-packages:
(list)
A list of dependencies to get from PyPI
- python-version:
(string; default: python3)
The python version to use. Valid options are: python2 and python3
The issues and features worked on for 3.0 can be seen on the 3.0 launchpad milestone which are reflected in the following change list:
Last updated 1 year, 2 months ago.