The snapcraft team is pleased to announce that version 2.35 has been released.
This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:
New in this release
Each build instance created now correctly works out isolated temporary folder locations for those users running many builds in parallel. There is also better detection of existing or missing lxd installations so first time users can better understand any problems with the host they are currently trying to use.
snapcraft from the snap,
snapcraft now injects itself into the actual snap instead of
apt installing the deb (for the case of today of only supporting one base), providing parity with the local environment at hand.
Work has been added to get rid of all the corner cases and provide useful feedback to users and making the experience feel more native.
Additionally, support has been added for using remote lxd instances.
To enable the persistent build containers feature the
SNAPCRAFT_CONTAINER_BUILDS environment variable needs to be set.
Here’s an example of using a remote lxd instance:
On this new version we added more information to the build manifest, like the contents of lock files, the debs and snaps installed in the machine, information from uname and the fingerprint of the container used for the build. To record the build manifest, set the environment variable
SNAPCRAFT_BUILD_INFO. The manifest will be saved and distributed inside the snap. After the build, you can inspect it in the prime/snap/manifest.yaml.
Command Line Interface
new command: pack
pack command replaces the now deprecated use of
snap <snap-dir> with the goal of decoupling the concept of working on an actual snapcraft project and packing up a directory layout into a snap.
new command: refresh
This command is only available when persistent build containers are enabled and exists to make the environment feel as native as possible. Prior to the existence of this command, building continuously in a container triggered a refresh of the packaging archive every time, now this
refresh only takes place on container creation or when called through
new command: edit-collaborators
This command will eventually replace the use of the store invites mechanism to setup other people as collaborators to the project. It is currently hidden as the production snap store has it currently disabled. A future release once things have stabilized will expose the command to users. It is harmless to use today as a proper error will show up.
In the meantime, here is how it works when using the integration store:
Initial support for running the snapcraft snap on solus has been added. It should work well enough for things like performing store operations, packing up snaps; or if lxd is installed and setup, most operations should work through use of persistent build containers or cleanbuild.
We look forward to knowing how this initial experience performs.
Snapcraft currently only really runs well on Ubuntu 16.04, but we’re working on adding support for other releases and Linux distributions. This is the first release where you can use the Snapcraft snap on Ubuntu 14.04 (Trusty). This is particularly important for snaps based on ROS (Robot Operating System) Indigo, which targets Trusty. Here’s a demo of just that:
This plugin developed by Rajesh, a .NET developer at Microsoft, allows you to create .NET 2.x based snaps, currently embedding the runtime with plans to enhance it to understand content snaps of .NET runtimes which could be leveraged by projects.
The syntax is pretty straightforward and builds on language understood by upstream so getting started for a current .NET developer should feel like a pleasant journey.
Here is the plugin in action:
This release sees the addition of a Ruby plugin, written by James Beedy. It supports a number of different Ruby versions by building them from source, which takes a little while but makes it pretty versatile. It could definitely use some exercise! Here’s an example of building a snap of the Travis gem:
The Catkin plugin has long supported rosdep to resolve and fetch system dependencies (i.e. Debian packages). However, rosdep also supports resolving pip dependencies. This release adds support for those, so they don’t need to specified elsewhere in the snapcraft.yaml.
To get the source for this release, check it out on github.
A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.
— Sergio and the team