Build and distribute Snappy packages

[Tyriar]

Ubuntu 16.04 is going to include a new type of package that installs the application in a more isolated manner.

• https://developer.ubuntu.com/en/desktop/
• https://developer.ubuntu.com/en/snappy/#tour
• http://www.pcworld.com/article/3056668/linux/ubuntu-1604-will-support-snaps-alongside-deb-packages-for-improved-software-installation.html

[sergiusens]

Hello there, I have something sort of working.

It is not on the store yet, but you can download it from http://people.canonical.com/~sergiusens/snappy/vscode_1.0_amd64.snap

There are two snappy related bugs still open for this (which are being worked on):

• LP: #1577514
• LP: #1577520

So it would need to be installed by running

sudo snap install --devmode vscode*.snap

The most important thing that I still need to resolve it plugin installation. That is an area I could use pointers for btw.

I have 4 commits here https://github.com/sergiusens/vscode/commits/release/1.0.0

This branch has:

• a gulp task to create the snap layout.
• snapcraft specific assets.
• a launcher (shell) specific to snapcraft (this won't be necessary for future builds though).
• a local plugin (parts/plugins/x-nodejs) until I (or someone else) adds support for either gulp as a top level plugin or clean up what I did here to also support gulp.

sergiusens@a840a34 you might want to cherry pick regarless.

[Tyriar]

Hey @sergiusens, thanks a lot for your work on this. The snap file size is 92mb compared to 30-45 for the other package types, are snaps not compressed by default or was this just left out?

We probably won't delve into distributing a snap until at least #1577514 is fixed. It sounds like it will be an Electron fix that will then take time for us to uplevel to.

I only thing I can see that's preventing your commits landing in master is moving the build resources (parts, snapcraft.yaml) to resources/linux/snap and the build artifacts to .build/linux/snap. If you get around to upleveling your branch and making those changes we'd be glad to merge a PR and add it to the CI build.

[sergiusens]

@Tyriar ok, sounds like a plan, I'll work on that

[sergiusens]

@Tyriar about size, we need to include things in which are not part of the core os which is the common dependency for everything. This could be much smaller but isn't yet as I haven't trimmed down all of it yet.

I'll get to the other items as soon as I look at it. I also based out of release/1.0.0 which I guess the intenton is to get this into master/devel instead?

[Tyriar]

@sergiusens yeah if you update your work to work on master with the tweaks I mentioned then we can push this and I'll get notified if it breaks. It will also make it convenient for anyone who wants to use snappy packages from an OSS build.

[flexiondotorg]

@Tyriar Microsoft Visual Studio Code is published as a snap in the store as vscode using classic confinement in the beta channel. We'd love for your team to take ownership of this snap and publish new versions directly to the store :-)

The rationale for using classic confinement is that vscode is a code editor and users may reasonably expect to be able to edit files anywhere on the system. Use classic confinement means that LP: #1577514 is no longer relevant and neither is LP: #1577520, although the later issue is also now resolved in snapd when applications are strictly confined.

Snaps have a number of useful characteristics such as being simple to create, support multiple Linux distributions, enable very simple installation instructions and provide access to install metrics via the Snap store. There are also various hooks and services [3] available to automate the build and publish pipeline.

[Tyriar]

@flexiondotorg thanks for reaching out again, could you email me the process for taking ownership and publishing?