Open cr1901 opened 3 years ago
Rustup is not meant to be used in this fashion certainly. I think you would probably do best to discuss with the Cargo team how they develop and debug in this kind of situation. I'm not sure how overrides, partial toolchains, and so on would interact in this kind of situation.
If it turns out that we're doing something wrong within Rustup itself once you've had your discussions with Cargo, we can revisit it on this issue.
This may be very difficult to solve. Cargo would somehow need to discover which toolchain should be used, which can be difficult to discover correctly. That would need to be cached, and the existing caching is already a bit tricky and buggy.
There is documentation at https://doc.crates.io/contrib/process/working-on-cargo.html#running-cargo for how to work around this issue.
@ehuss
There is documentation at https://doc.crates.io/contrib/process/working-on-cargo.html#running-cargo for how to work around this issue.
Ahhh, this is very useful to know. Anyways, if it's very difficult to solve, then it may as well remain unsupported. As a possible solution: how difficult would it be for rustup
proxies to notify a non-proxy cargo
that its running a proxy rustc
(doesn't matter which toolchain, just that the proxy was run)? Then non-proxy cargo
could print out a nice big warning that "this is unsupported, expect things to break" for the next person who tries what I did?
When Rustup invokes something via a proxy we set the RUSTUP_TOOLCHAIN
environment variable I believe. You might be able to use that to detect it in Cargo, but honestly it's not a guaranteed API so I wouldn't want to tie Cargo to it. In reality it's probably better to use the mechanisms the Cargo team recommend.
In reality it's probably better to use the mechanisms the Cargo team recommend.
Right, but there will be other people, like me, who still try what I did first before reading the docs. My question is more like "can't there be an error/big warning that points back to the Cargo docs?", knowing that people will experiment without reading the docs? And if so, is there a way for cargo
to know that you're doing something unsupported from the rustup
side of things.
If RUSTUP_TOOLCHAIN
is not a stable API, and there's no way to reliably detect the proxy from cargo
, then I guess "read the docs when cargo
invokes the wrong rustc
" is the correct answer. I supposed "cargo
stopped working when it previously worked" if a big enough warning sign. Anyways I'll migrate both my issues over if infra hasn't done so already when I get the chance, and come back to this issue if necessary.
Should this issue be xferred to cargo
as well? I can't seem to tag @rust-lang/infra, like the previous issue did.
@rust-lang/infra could one of you move this to cargo ?
Problem This too may be a
cargo
problem, but since it involves therustc
proxy, I'll open here first.Consider a crate with the following
src/lib.rs
andCargo.toml
:My default
rustup
toolchain isnightly
, and I have anoverride
to usestable
in this directory.rustup
is on the path first, so the proxies will be picked up first. In addition, I have an externalcargo
that I built for testing that I'm using instead of the proxy thatrustup
provides. When invoking this particularcargo
binary, which is not a proxy, I get the following error:Steps
git clone https://github.com/rust-lang/cargo; cd cargo; cargo build
.use
d.rustup
override to anything besides your default toolchain.cargo
, and not thecargo
proxy provided byrustup
.Possible Solution(s) Since
cargo
invokesrustc
, and therustc
proxy is first on my path, the externalcargo
is invoking therustc
proxy. However, theoverride
is not taking effect except for the final crate. I can confirm that all artifacts are built with the defaultrustc
in my case (nightly
), until the final crate is compiled. At this point,rustc
invoked from externalcargo
starts honoring the override, and crate compilation fails due to version mismatch.Is this not supported? It's fine if using an external
cargo
unsupported, but I do wonder if:cargo
in the presence ofrustup
on the path?cargo
could auto-detect whether there's a version-mismatch that warrants recompiling dependencies? Does this setup break auto-detect?Notes
System Information: