Skip to content

Add support for building snap packages#1441

Closed
popey wants to merge 3 commits intorust-lang:masterfrom
popey:add-snapcraft
Closed

Add support for building snap packages#1441
popey wants to merge 3 commits intorust-lang:masterfrom
popey:add-snapcraft

Conversation

@popey
Copy link
Copy Markdown

@popey popey commented Jun 20, 2018

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 --classic and they're ready to start installing all the awesome rust goodness. The rustup-inst binary 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 --classic

Within the directory containing the .snapcraft.yml run:
snapcraft

Install the resulting snap:
snap install rustup-init_stable_amd64.snap --dangerous --classic
(the --dangerous flag is required if you're 'side-loading' rather than getting a signed snap from the store)

Happy to answer any questions!

@Diggsey
Copy link
Copy Markdown
Contributor

Diggsey commented Jun 20, 2018

@popey this looks interesting, would be good to get some more feedback, cc @rust-lang-nursery/rustup-rs-owners @aturon.

My thoughts:

  • 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?

  • 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.

Thanks for the PR!

@nrc
Copy link
Copy Markdown
Member

nrc commented Jun 20, 2018

cc @rust-lang/release who would have to manage this

@nrc
Copy link
Copy Markdown
Member

nrc commented Jun 20, 2018

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.

@flexiondotorg
Copy link
Copy Markdown

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?

@popey
Copy link
Copy Markdown
Author

popey commented Jul 11, 2018

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!

@nrc
Copy link
Copy Markdown
Member

nrc commented Jul 12, 2018

@alexcrichton do you have thoughts on this?

parts:
rustup-init:
plugin: rust
source: .
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it should have: build-attributes: [no-self-update]

@alexcrichton
Copy link
Copy Markdown
Member

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.
@popey
Copy link
Copy Markdown
Author

popey commented Aug 1, 2018

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?

@mati865
Copy link
Copy Markdown
Member

mati865 commented Aug 2, 2018

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 ~/.cargo/bin to PATH and you are ready to go.

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.

@popey
Copy link
Copy Markdown
Author

popey commented Sep 3, 2018

Thanks for the input @mati865 - much appreciated.
I'm keen to get a better handle on how the rust team would like us to progress here? Would you prefer a rustup snap, or a rustup-init? I'm after a little direction, and then I'm happy to do the engineering to re-work the PR as necessary. Would it be worth asking internally in the Rust team to get consensus? Thanks!

@mati865
Copy link
Copy Markdown
Member

mati865 commented Sep 11, 2018

Pinging @Diggsey, are you waiting for answers regarding your questions or is there something else?

@flexiondotorg
Copy link
Copy Markdown

@Diggsey @mati865 We're still very keen to assist with this. Is there anything more you need from us?

@nrc
Copy link
Copy Markdown
Member

nrc commented Jan 14, 2019

@rust-lang/cargo (esp @joshtriplett ) do you have thoughts on this?

@joshtriplett
Copy link
Copy Markdown
Member

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.

@kinnison
Copy link
Copy Markdown
Contributor

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.

@kinnison
Copy link
Copy Markdown
Contributor

@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.

@kinnison
Copy link
Copy Markdown
Contributor

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.

@kinnison kinnison self-assigned this Jan 10, 2020
@kinnison
Copy link
Copy Markdown
Contributor

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.

@kinnison
Copy link
Copy Markdown
Contributor

kinnison commented May 8, 2020

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.

@kinnison kinnison closed this May 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants