What are you thinking more specifically? rustup is intended (for now at least) to be run out of $CARGO_HOME/bin, so if we were going to make this configurable we would effectively be changing the location of CARGO_HOME.
This is doable, but it means that the way PATH is setup will also need to change, that the proxies will need to tell cargo where it's home is (though it already incidentally does this, but I sort of want it not to). The location of CARGO_HOME is also closely related to the location of RUSTUP_HOME - it's likely that if you want to change one you want to change both.
FWIW if CARGO_HOME is set at install time rustup-init will obey it, and it'll _probably_ just work.
I mostly want tools to not put configuration along with the binaries.
For rustup installations I would like its configuration to live in some path specified by an environment variable (RUSTUP_CONFIG maybe) and all binary things it installs should go to $XDG_DATA_HOME and not along with the config – libraries into $XDG_DATA_HOME/lib, binaries to $XDG_DATA_HOME/bin, docs to $XDG_DATA_HOME/shared/doc etc etc. Basically what I’m looking for is at least a --install-root=whatever I want option.
I think the default shouldn't be $HOME/.cargo either, that's not following XDG base directory spec and is polluting $HOME.
It should go into $XDG_DATA_HOME/cargo or $HOME/.local/share/cargo if $XDG_DATA_HOME is not defined.
@shmerl that's https://github.com/rust-lang/rfcs/pull/1615
@steveklabnik: Thanks, I didn't realize it was such a thorny issue. I thought using XDG shouldn't cause any such trouble. Still, I'm strongly in favor of it.
I would love to be able to install rust on a computer as root so that multiple users can all use rust. I think this requires separating rustup's location from the location where each user running cargo will have cargo download packages.
What if users are using a NFS such a lustre? it cannot installed into NFS and be distributed.
Would be nice if rustup followed the same patterns as cargo install.
rustup_init option)$CARGO_INSTALL_ROOTinstall.root of $CARGO_HOME/config.The rust repo's x.py and cargo install both support manually changing the prefix, but the "official install tool" has no such concept.
An example of why someone might like to install elsewhere: Ones' home dir may be on an attached network share (not uncommon in many a corporate environment). These network drives are not normally known for their speed and would be a sub-optimal location for a cache.
rustup-init honours the CARGO_HOME and RUSTUP_HOME environment variables if they're set before the start of the installer.
Great, so we can close this out?
Sent with GitHawk
Is XDG base directory support already implemented though? I.e. default shouldn't be $HOME/.cargo, it should follow XDG if no variable for CARGO_HOME and RUSTUP_HOME is set.
rustup doesn't use XDG dirs, no.
So it's still a problem then. Wasn't there some effort to implement it though a while ago? Looks like it stalled.
But this particular issue can probably be closed, since you can indeed use CARGO_HOME and RUSTUP_HOME to set the location. XDG dirs support is a bit different issue.
I just hit this issue where my home is mounted with NFS in a cross platform environment (x86, Arm, others), but there's only one bin directory. (edit: reworded)
@tommythorn as explained earlier in this issue, CARGO_HOME is obeyed from the environment for both cargo and rustup.
@tommythorn
(x86, Arm, others),
in a cross platform environment
Since binaries are platform specific. perhaps, rust putting binaries in those in $CARGO_HOME/@platform e.g /@x86 /@arm /@win32 /@win64 /@whatever, would satisfy NFS use-case sharing same CARGO_HOME across many OS-es where a compilation could happen, and binary of that platform invoked?
Most helpful comment
I think the default shouldn't be
$HOME/.cargoeither, that's not following XDG base directory spec and is polluting$HOME.It should go into
$XDG_DATA_HOME/cargoor$HOME/.local/share/cargoif$XDG_DATA_HOMEis not defined.