Please publish rustup to crates.io

[joshtriplett]

Please consider publishing rustup releases as a crate on crates.io. That would make it easier to package rustup releases for Linux distributions, or to install rustup via "cargo install rustup" if you have Rust and Cargo already installed via your distribution. (There's a lot of value in having rustup packages even in a distribution that already has Rust packages, such as to install nightly or to install a cross-toolchain.)

[brson]

I'm happy to make publishing rustup part of the release process. I think right now the blocker is that there are some non-crates.io deps, particularly in the download crate.

[brson]

Next step is to get rid of git deps in rustup.

The rustup library may need to be broken into another crate and all the libs version numbers dropped to < 1.0.

[xen0n]

FWIW rustfmt is properly packaged without crate separation by putting CLI drivers in the seemingly implicit path src/bin. Maybe we could do the same by refactoring main() out of rustup-cli after re-organizing everything?

What's most important though, is defining how rustup as a library should be invoked. Maybe the testsuite way is worth considering?

[xen0n]

Also the peculiar way rustup currently installs itself, hard-linking, may be difficult to implement for Cargo installs, but I haven't looked into it. The library interface thing is actually way less relevant if all we want is just enabling cargo install rustup.

[brson]

Oh I misunderstood this issue. I was not considering publication of the rustup binary, only the libs. I don't know how publishing rustup binaries via cargo would work offhand.

[joshtriplett]

@brson I'd like to have the rustup binary crate available via cargo, allowing cargo install --root=/some/path rustup to install rustup to /some/path/bin/rustup. That seems similar to installing a binary from any other crate via cargo install.

This would require rustup to have all its dependencies on crates.io as well.

[infinity0]

Hi I'd like to bump this. Some people would like to be able to install rustup in Debian so they can easily get access to rust nightly, which we don't package in Debian.

This would allow people to run aptitude install rustup instead of curl blah://blah/sh | sh.

[kinnison]

So while we support (to some extent) being packaged, we have no intention to release rustup onto crates.io at this time because we do not want to encourage anyone to think we're providing a stable API in any sense. Also we do still have some internal crates which we don't intend to provide as an API in any sense.

Platforms other than Debian manage to package rustup without it being on crates.io. If there's a really strong reason for wanting it and not being able to deal with it otherwise, please open a fresh issue to discuss the matter.

[infinity0]

@kinnison which platforms other than Debian manage to package rustup?

• fedora 0 results
• gentoo 0 results

[kinnison]

@infinity0 I'm aware of Arch, Void/Alpine, and Nix at least. Someone tried to package it for Chocolatey (Windows) and at one point there was a threat of an msys one though I've not spotted that for a while.

[infinity0]

Fair enough. Those platforms have less strict packaging policies than Debian/Fedora/Gentoo however.

[infinity0]

Not to imply that it's against Debian policy to package rustup without it being on crates.io, it's just that we've developed automated tooling (with the policy in mind) to work with crates.io and it's some extra work to make it work with a github git repository. Not sure what the situation is with Fedora/Gentoo.

[kinnison]

As a rustup author and as a Debian Developer, I'd personally not want rustup packaged for Debian because Debian's cycles are way too long for rustup and people come to expect the new features which unless whatever has replaced "volatile" took it on, people would be annoyed by the packaged version.

[infinity0]

It's easy to keep any package in Debian Experimental or Debian Unstable with an RC bug that blocks it from entering Debian Stable, this is the standard option for unstable user-facing tools like rustup.

[kinnison]

That's fair. At this time, publishing to crates.io would create a burden on rustup which we do not want (either we'd have to restructure into one crate, or else publish library crates which we have no intention of supporting the API of) people would expect cargo install rustup to work, which we do not want to have to deal with, etc. I guess for Debian, either you come up with a way to support creating packages from leaves which are not on crates.io, or you accept that for policy reasons you can't package rustup.

[simonsan]

@kinnison which platforms other than Debian manage to package rustup?

* [fedora 0 results](https://apps.fedoraproject.org/packages/s/rustup)

* [gentoo 0 results](https://packages.gentoo.org/packages/search?q=rustup)

OpenSUSE
https://www.youtube.com/watch?v=7R2ZZZvVoDU

[kinnison]

@simonsan Nixos does a reasonable job of it. The homebrew package is bad. Chocolatey packages a rustup installer.