Ah, I see where you are coming from now. Thanks :)
> First, I do want to say, I don't really care about the gcc alternative. I'm not even particularly interested in this tool. I've just found in the past, folks in the Rust community are quite dismissive about "other perspectives", particularly when they differ from "the open development way". I was just trying to urge you not to encourage that dismissive attitude.
I'm usually not dismissive, since I've felt these pains too working in a (less locked down, but locked down nevertheless) similar environment. In this case I was dismissive because it is just as bad for GCC, which makes targeting Rust very unfair. Plugin tools like this always require a bunch of extra work up to even recompiling the compiler, which provides additional barriers to adoption.
--------
So, firstly, I wasn't advocating rustup as a tool which downloads the toolchains. For a reproducible build, that's not good. I was advocating it as a tool which manages toolchains and lets you switch with ease (you load it up with the toolchains you need beforehand, and distribute a .multirust directory to your build machines). This lets you use the supported stable version for actual builds, and nightly for peripheral tooling like linting and fuzzing, which doesn't affect the actual build -- just diagnostics. Note that your concerns about bugs don't apply to tooling, since it doesn't touch the outputted binaries. This may lessen the pain of getting approval, but still, a better solution should exist :)
If you are going to modify and build Rust sources, this isn't a problem anyway. You can get the sources for the latest stable (they're on a branch somewhere) and tweak them so that this tool works (one line change to code), or so that the compiler allows you to use unstable features (make/configure option). This is effectively a "nightly" build on stable sources, sources that will be getting backport fixes for bugs. Note that the APIs used by this tool will not be stable and may change (most likely they won't) if you update to a new compiler.
-----
The above solution is less viable for clippy, since clippy depends on tons of extremely unstable compiler internals (whereas this tool depends on one API call which could change but probably won't) which will break every compiler upgrade. But as I said, there is a fix being planned for clippy. For most users the fix will just involve using rustup. For enterprise users I imagine the possible fixes will either involve downloading the official clippy for their version of the stable compiler once, or, if you are compiling from sources, compiling Rust with clippy included (which probably won't be hard since building clippy will be part of Rust's rustup toolchain packaging anyway, so the steps will be the same and probably just a make/configure option).
> fortunately I think Cargo is already able to do this
Not exactly. Cargo so far is fine with local path dependencies, but it doesn't yet have support for having a locked down internal mirror repo with the relevant sources like many people do for PyPi or npm. That's something enterprise users do want, since vendoring in-tree is not always the solution. I don't know if it's being actively worked on, but it is on the list of things that Rust definitely wants.
> First, I do want to say, I don't really care about the gcc alternative. I'm not even particularly interested in this tool. I've just found in the past, folks in the Rust community are quite dismissive about "other perspectives", particularly when they differ from "the open development way". I was just trying to urge you not to encourage that dismissive attitude.
I'm usually not dismissive, since I've felt these pains too working in a (less locked down, but locked down nevertheless) similar environment. In this case I was dismissive because it is just as bad for GCC, which makes targeting Rust very unfair. Plugin tools like this always require a bunch of extra work up to even recompiling the compiler, which provides additional barriers to adoption.
--------
So, firstly, I wasn't advocating rustup as a tool which downloads the toolchains. For a reproducible build, that's not good. I was advocating it as a tool which manages toolchains and lets you switch with ease (you load it up with the toolchains you need beforehand, and distribute a .multirust directory to your build machines). This lets you use the supported stable version for actual builds, and nightly for peripheral tooling like linting and fuzzing, which doesn't affect the actual build -- just diagnostics. Note that your concerns about bugs don't apply to tooling, since it doesn't touch the outputted binaries. This may lessen the pain of getting approval, but still, a better solution should exist :)
If you are going to modify and build Rust sources, this isn't a problem anyway. You can get the sources for the latest stable (they're on a branch somewhere) and tweak them so that this tool works (one line change to code), or so that the compiler allows you to use unstable features (make/configure option). This is effectively a "nightly" build on stable sources, sources that will be getting backport fixes for bugs. Note that the APIs used by this tool will not be stable and may change (most likely they won't) if you update to a new compiler.
-----
The above solution is less viable for clippy, since clippy depends on tons of extremely unstable compiler internals (whereas this tool depends on one API call which could change but probably won't) which will break every compiler upgrade. But as I said, there is a fix being planned for clippy. For most users the fix will just involve using rustup. For enterprise users I imagine the possible fixes will either involve downloading the official clippy for their version of the stable compiler once, or, if you are compiling from sources, compiling Rust with clippy included (which probably won't be hard since building clippy will be part of Rust's rustup toolchain packaging anyway, so the steps will be the same and probably just a make/configure option).
> fortunately I think Cargo is already able to do this
Not exactly. Cargo so far is fine with local path dependencies, but it doesn't yet have support for having a locked down internal mirror repo with the relevant sources like many people do for PyPi or npm. That's something enterprise users do want, since vendoring in-tree is not always the solution. I don't know if it's being actively worked on, but it is on the list of things that Rust definitely wants.