Add support for building snap packages#1441
Add support for building snap packages#1441popey wants to merge 3 commits intorust-lang:masterfrom popey:add-snapcraft
Conversation
|
@popey this looks interesting, would be good to get some more feedback, cc @rust-lang-nursery/rustup-rs-owners @aturon. My thoughts:
Thanks for the PR! |
|
cc @rust-lang/release who would have to manage this |
|
I agree with @Diggsey about the layered-ness - it seems like a better approach would be for Snap to install Rust directly without using rustup or rustup-init. Not sure if that is possible or very hard work. |
|
When we discussed creating snaps of Rust with @alexcrichton the advice we received was making a snap of Rustup was more desirable. We're happy to help create a Rust snap if that is preferable? |
|
As @flexiondotorg said, we had a conversation some months back with the rust development team and the conclusion at that point was that rustup was the best first target. I made and tested the rustup snap based off those conversations. However I'm not precious about this pull request. If you'd rather I created a PR for rust itself, that's cool too :). Let me know what you think, and I can set some time aside to make a new PR if requested. Thanks! |
|
@alexcrichton do you have thoughts on this? |
| parts: | ||
| rustup-init: | ||
| plugin: rust | ||
| source: . |
There was a problem hiding this comment.
I think it should have: build-attributes: [no-self-update]
|
This seems like a fine addition to me! I don't personally have much time to manage this on the snap side of things, but having it done at the start in a semi-unofficial capacity I think should be fine |
Disable self-updating mechanism.
|
Added no-self-update build option as suggested by @mati865 - thanks! "Maintenance: the addition seems fairly simple, but I'm a bit wary of merging stuff that no-one is super familiar with. Assuming this is merged, would you be happy to assist with potential issues relating to the snap install/keeping it up to date?" Sure. There's not a lot to it though. "Installing rust this way becomes... very layered. You would need snap to install rustup-init to install rustup to install rust. Does snap support per-user installs, or is it designed to only install stuff system-wide? If it does support the former, maybe it can automatically run rustup-init during installation? That way you run snap install rustup or similar, and at the end of it have a working rust installation." Currently snap is system wide. I am inclined to agree to the layered comment. We initially wanted to snap up rust itself, but it was suggested we do rustup instead. Keen to understand what would be most appropriate. By way of comparison, the node snap contains node itself along with npm and yarn. Would it make more sense for a 'rust' snap to ship with 'rust' and 'rustup' binaries. The goal is to make it easy for developers to get bootstrapped. Simply typing "snap install rust" to get everything then need to get started is a more compelling argument than snap install rustup-init, then run a bunch more commands. What do you think? |
|
Note: I'm not a member of Rust Project. I think having fully featured rusutp snap would be more useful, like Arch Linux rustup package. Install, add Nonetheless it can't hurt to take this as an experiment and if Rust developers are happy with it release Rustup and Rust as snaps. |
|
Thanks for the input @mati865 - much appreciated. |
|
Pinging @Diggsey, are you waiting for answers regarding your questions or is there something else? |
|
@rust-lang/cargo (esp @joshtriplett ) do you have thoughts on this? |
|
I do think that it'd be better to package rustup, rather than rustup-init. rustup is a generally useful tool, even if you have a system-packaged Rust, to install things like cross-compile targets or nightly Rust. Installing rustup-init and then using that to install rustup seems...odd to me. I do think it makes sense to have snap packages of rustup. |
|
So there is some progress on this -- I have published an edge experimental rustup snap, tomorrow I hope to see if we can get some default aliases in place to make this less painful. Once I've done that we'll have a good solid play and if it looks sane, I'll be taking a proposal to the dev-tools group to suggest that we create a rust brand on the snap store and publish rustup that way. if they agree then we'll need to sort out CI/CD for the edge channel and then something in the release process for publishing to the stable channel of rustup. |
|
@popey and I have had a chat and decided on the following -- Once #1896 and #1897 are dealt with, I will push updates to this PR which deal with the snaps in the way I've been experimenting with here at Snapcraft Summit, and then we'll look to review/merge from there. By keeping things in this PR we hope everyone who is interested/subscribed will be kept in the loop. |
|
Last year, after snapcraft summit, I ended up with a work-in-progress PR at #1898 which did most things we needed, but in a very prototypical way. We weren't really able to come up with a decision about how to move forward so it stagnated a bit. With the new year, and the move to Github Actions as our CI provider, I've reengaged with this, and with James Henstridge on the forums, to see how we might move forward. I may also try and discuss things with some of the rust team at the all hands, in the rustup sessions to see if we can come up with a consensus on how the project might be prepared to have official snaps, because it'd be sad if we couldn't. |
|
For those who are not subscribed to it, #1898 is progressing nicely and may merge soon. That'd make my personal rustup snap be updated on the fly on merges to master (and on releases) and I intend to take things forward at all-hands. I'm probably going to close this when #1898 is released and will sort an issue out for anyone here who wants to track progress on making things official. |
|
I have merged #1898 and as such I consider this dealt with. I will see what we can do to ensure that we're pushing snaps to the edge channel soon. |
Hello!
This pull request adds support for building a snap package of rustup-init. The resulting snap should work on Ubuntu, Debian, Fedora, Linux Mint, Solus and many other distributions. If accepted a member of the rust team could hook this up to our free build service to publish the snap to the store, or use travis to do the same. By default we recommend pushing each commit to the 'edge' channel in the store.
One in the store and tested, a member of the rust team could release a stable version of the snap into the stable channel in the store. Users can then simply
snap install rustup-init --classicand they're ready to start installing all the awesome rust goodness. Therustup-instbinary will be in the path, and thus can be used as normal to bootstrap a rust developer workstation.We've had success with other modern languages including kotlin, go and node, and it would be great to have rust along too!
Rust developers could test this PR works using
snapcraft. I recommend building on an Ubuntu 16.04 machine (a VM is fine) or container. Grab this PR and simply.Get snapcraft
snap install snapcraft --classicWithin the directory containing the
.snapcraft.ymlrun:snapcraftInstall the resulting snap:
snap install rustup-init_stable_amd64.snap --dangerous --classic(the
--dangerousflag is required if you're 'side-loading' rather than getting a signed snap from the store)Happy to answer any questions!