You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a fully reasonable set of steps. A user could experiment with rust and decide to stop but want to keep using their Python tooling that happens to be implemented in Rust.
Also, if I were making a product, I wouldn't want the implementation's language to be a part of our compatibility story
As a Cargo team member, I'm concerned about people mucking with Cargo's internals
The text was updated successfully, but these errors were encountered:
We are in fact working on this in #1233, with the first steps already in flight to make it safe for us to do this migration. However we do need things like #287 to have a good safe default home for binaries on each platform.
This default made more sense when we were a rust tool for rust programmers, but, we've outgrown it.
It's worth noting that I believe cargo-binstall also does something like this, and possibly also cargo-quickinstall (the two are strongly related). But at least in those cases you're more explicitly engaging with cargo, whereas we can do it in some random curl-sh scripts.
Steps
note: I've not run this but am basing it off of cargo-dist's generated
install.sh
and from rustup's source code: https://github.com/rust-lang/rustup/blob/c91692a1bdbd91663dbc5fbb1f1bdd684e711f1c/src/cli/self_update.rs#L908-L925This is a fully reasonable set of steps. A user could experiment with rust and decide to stop but want to keep using their Python tooling that happens to be implemented in Rust.
Also, if I were making a product, I wouldn't want the implementation's language to be a part of our compatibility story
As a Cargo team member, I'm concerned about people mucking with Cargo's internals
The text was updated successfully, but these errors were encountered: