3 ms·

Right, which is why I said for such distros I expect rustup-obtainable extras to be packaged as well and installed in the same way. Again, unsure if this is th

Right, which is why I said for such distros I expect rustup-obtainable extras to be packaged as well and installed in the same way. Again, unsure if this is the actual plan.

kbenson 10y ago
I'm not sure where you said that, so I'm not sure what context to interpret that in. Does "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? My only point in this part of the thread, which has little to do with the "we use gcc because it's stable" argument, is just that you shouldn't expect the distros the change how they ship just for rust, which expecting them to use rustup would be (in what I think are the majority of cases). If rust as a community expects rustup to be what distros use, then I think there's a disconnect from reality happening, and it's worth looking at because if that's important to rust (which I don't know, honestly), then it should be addressed. I understand that you may not know if this is the actual plan. Note: I don't particularly think rust requirly a nightly build for this is important. Organizations will look at it and assess it as a tool as needed, and if they think it's worth using and they want to roll it out, they'll package it in some manner if that's important to them (and that might just be a tarball, at the simpler level), or they won't if it's not. Stability is important, but at the tooling level, it's much less so, and being able to make sure all yours devs are in lockstep is probably more important (for large orgs).
- Manishearth 10y ago
  > "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? yep. I was referring to "If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo." What I meant was: instead of users installing rustup and then installing all the toolchains through rustup (`rustup install stable`, `rustup install arm-linux-gnueabi`, `rustup install clippy`), they can also install `rustc`, `rustc-arm-linux-androideabi` (cross toolchain), `rust-clippy` through the package manager (apt-get install or whatever). Cross compile toolchains for C are often similarly packaged (gcc-cross, etc). The way I understand it (again, unofficial, not sure if it's the actual plan :) ), we would like most users to use rustup as the single source of truth for Rust. This won't work for some setups, including distro packaging, and I'm not sure what the plan is there, but I'd expect it to be something similar to what I wrote above. The binaries that rustup downloads will always be available, regardless, if you are okay with downloading a signed binary once and internally distributing it. But I don't expect it will come to that. Though right now Rust hasn't yet gotten all the ducks in a row for proper distro packaging, so that's all you can use. This is being actively worked on, and IIRC all the major work is done (?)
  - kbenson 10y ago
    That basically matches with what I expect, but I'm not sure that distros will even bother to package rustup in the base packages (as something that provides an alternative to a packaged item, not just a supplement, such as cargo). In this respect, the wants and needs of distros are often at odds with those of developers. Developers want the latest with all the features in front of their users, distros want something easy to maintain and support (which often means not changing, or on a predictable schedule). This is particularly hard on interpreted languages, as the version shipped matters a lot more for what will run, not just what will compile in your dev environment. There's a (relatively) long history here. If rustup isn't part of the base (distro-provided) packages, it will definitely be part of some popular add-on repos though.
    - Manishearth 10y ago
      Yeah, I am aware :) I was super annoyed when I found out Ubuntu ships an ancient node and nvm doesn't exist in the distro. I would love for rustup to exist in the distro, but we should (and probably are doing so) plan for cases without it.
      - kbenson 10y ago
        In some cases, all you have to do is the minimal amount to make it easier on the distro users, and people will jump on it. That may be providing repos for debian and red hat based systems where you provide a rustup RPM. That takes care of both making it easy (if not quite as easy as piping a remote source to a shell), and more secure. The keys are cached when the repo is added or first accessed, so if bad rustup packages are uploaded at some later time, the package managers will complain, loudly, at least for people who already had it, which is better than nothing.
        Manishearth 10y ago
        I think Rust is interested in doing more than the minimal amount, and has been discussing with maintainers already, but I'm not aware of the details. They probably can be found on threads on internals.rust-lang.org or users.rust-lang.org though. rustup.rs already does check against Rust release signing keys, so that part is at least trivial to integrate.

Right, which is why I said for such distros I expect rustup-obtainable extras to be packaged as well and installed in the same way. Again, unsure if this is the actual plan.

kbenson 10y ago

I'm not sure where you said that, so I'm not sure what context to interpret that in. Does "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? My only point in this part of the thread, which has little to do with the "we use gcc because it's stable" argument, is just that you shouldn't expect the distros the change how they ship just for rust, which expecting them to use rustup would be (in what I think are the majority of cases). If rust as a community expects rustup to be what distros use, then I think there's a disconnect from reality happening, and it's worth looking at because if that's important to rust (which I don't know, honestly), then it should be addressed. I understand that you may not know if this is the actual plan. Note: I don't particularly think rust requirly a nightly build for this is important. Organizations will look at it and assess it as a tool as needed, and if they think it's worth using and they want to roll it out, they'll package it in some manner if that's important to them (and that might just be a tarball, at the simpler level), or they won't if it's not. Stability is important, but at the tooling level, it's much less so, and being able to make sure all yours devs are in lockstep is probably more important (for large orgs).

Manishearth 10y ago
> "rustup-obtainable extras to be packaged as well and installed in the same way" mean packaged through distro specific packaging mechanism, or something else? yep. I was referring to "If not via rustup, I would expect everything that can be fetched via rustup to be in the package repo." What I meant was: instead of users installing rustup and then installing all the toolchains through rustup (`rustup install stable`, `rustup install arm-linux-gnueabi`, `rustup install clippy`), they can also install `rustc`, `rustc-arm-linux-androideabi` (cross toolchain), `rust-clippy` through the package manager (apt-get install or whatever). Cross compile toolchains for C are often similarly packaged (gcc-cross, etc). The way I understand it (again, unofficial, not sure if it's the actual plan :) ), we would like most users to use rustup as the single source of truth for Rust. This won't work for some setups, including distro packaging, and I'm not sure what the plan is there, but I'd expect it to be something similar to what I wrote above. The binaries that rustup downloads will always be available, regardless, if you are okay with downloading a signed binary once and internally distributing it. But I don't expect it will come to that. Though right now Rust hasn't yet gotten all the ducks in a row for proper distro packaging, so that's all you can use. This is being actively worked on, and IIRC all the major work is done (?)
- kbenson 10y ago
  That basically matches with what I expect, but I'm not sure that distros will even bother to package rustup in the base packages (as something that provides an alternative to a packaged item, not just a supplement, such as cargo). In this respect, the wants and needs of distros are often at odds with those of developers. Developers want the latest with all the features in front of their users, distros want something easy to maintain and support (which often means not changing, or on a predictable schedule). This is particularly hard on interpreted languages, as the version shipped matters a lot more for what will run, not just what will compile in your dev environment. There's a (relatively) long history here. If rustup isn't part of the base (distro-provided) packages, it will definitely be part of some popular add-on repos though.
  - Manishearth 10y ago
    Yeah, I am aware :) I was super annoyed when I found out Ubuntu ships an ancient node and nvm doesn't exist in the distro. I would love for rustup to exist in the distro, but we should (and probably are doing so) plan for cases without it.
    - kbenson 10y ago
      In some cases, all you have to do is the minimal amount to make it easier on the distro users, and people will jump on it. That may be providing repos for debian and red hat based systems where you provide a rustup RPM. That takes care of both making it easy (if not quite as easy as piping a remote source to a shell), and more secure. The keys are cached when the repo is added or first accessed, so if bad rustup packages are uploaded at some later time, the package managers will complain, loudly, at least for people who already had it, which is better than nothing.
      - Manishearth 10y ago
        I think Rust is interested in doing more than the minimal amount, and has been discussing with maintainers already, but I'm not aware of the details. They probably can be found on threads on internals.rust-lang.org or users.rust-lang.org though. rustup.rs already does check against Rust release signing keys, so that part is at least trivial to integrate.