I work on the team developing Ubuntu and Snapcraft and recently spoke to @brson and @alexcrichton about creating and publishing a snap of Rust. They requested that we raise an issue here for creating a snap so that it can be included as a call for participation in a future This Week in Rust news letter.
For those unfamiliar with snaps and snapcraft, you can get a quick introduction from our video Snaps and snapcraft.io explained in 3 minutes.
As requested an issue to snap rustup has also been filed:
flexiondotorg
All 9 comments
Should we also work on all the other similar projects as well e.g. flatpak?
nagisa
on 1 Jun 2017
Appimage seems to be not required, as rust binaries are already self contained.
For flatpak, which is more focused at gui applications, rust is probably mostly interesting from the sdk point of view, e.g. when you want to build applications that build on rust. There is also an issue on the flatpak repo about this.
est31
on 1 Jun 2017
My personal perspective is that it is desirable to package Rust in formats that a large set of our users want (I have always wanted debs and rpms - we've just never succeeded in producing them), and where our release process can support it, and snap seems to be the preferred way to package for some subset of the Linux ecosystem going forward.
I don't think we're ready to commit to officially deploying Rust snaps, but I think it is a worthy project to explore what it will take to produce them. I'd like to encourage motivated contributors to look into it.
And I'd suggest we do it with the following in mind:
Produce snaps by converting our official, highly-compatible, tarballs to snaps; not by building Rust from scratch. This is more-or-less how the official non-rustup packages are produced today; derived from the 'canonical' (har) packaging.
By doing it that way people can do the work out of tree, and even begin publishing non-official snaps built off the official release artifacts. If and when the snaps become mature and we want to incorporate them into the release process, it's a simple matter to pull them in-tree.
The basic process would be to download the manifest, which contains all the artifacts from the build, and parse out the components for a given platform, download those and repackage them in whatever way best suites the snaps.
wrt flatpak, I think it makes sense to create them as well, as long as that ends up being the recommended way of installing third-party compilers for the Fedora world. Though I also understand that snaps will be compatible with those systems as well, and (I believe) we should ultimately expect a Rust snap to show up in the Fedora software store if the user has the correct pieces installed.
brson
on 3 Jun 2017
I posted this to TWiR.
brson
on 3 Jun 2017
See also #36106
eyelash
on 25 Aug 2017
Appimage seems to be not required, as rust binaries are already self contained.
Wouldn't hurt, either - to the contrary, would make generating AppImages easy...
probonopd
on 27 Aug 2017
Any news on this?
pachulo
on 10 Apr 2019
MitchellBerry
on 10 Jun 2019
Looks like the package in Snap Store is deleted. There is a working snapcraft.yml in this repo. I can confirm that it works with 1.43.0 release. (amd64 arch using Ubuntu 18.04 LTS)
tunix
on 1 May 2020
Related issues
overvenus
路
3Comments
behnam
路
3Comments
jmegaffin
路
3Comments
wthrowe
路
3Comments
zhendongsu
路
3Comments
Most helpful comment
Appimage seems to be not required, as rust binaries are already self contained.
For flatpak, which is more focused at gui applications, rust is probably mostly interesting from the sdk point of view, e.g. when you want to build applications that build on rust. There is also an issue on the flatpak repo about this.