Consider moving to platform-specific configuration directories

[brson]

Many people would prefer cargo/rustup conform to various platform-specific standards for storing configuration. cc rust-lang/cargo#2127

(This issue was originally about a different subject, but is now an XDG etc. thread, some comments may make less sense out of context).

[gyscos]

I may have missed the answer before, but why not use XDG specifications again? (${XDG_DATA_HOME}/rustup)

[brson]

@gyscos It's because cargo doesn't. That's a change that all Rust tools need to make together.

[ollie27]

That's a change that all Rust tools need to make together.

Why?

The issue with cargo is that it was released using the wrong directories so now it's a lot harder to change. If rustup uses the correct directories from the start then there isn't a problem and seeing as is has to be moved anyway there isn't even any backwards compatibility issues for people using the beta.

On windows for example it should be something like %LocalAppData%\rustup.

[brson]

Why?

Consistency is important. If you know where one Rust tool puts its stuff you know where they all do.

[ollie27]

Well I reckon changing both cargo and rustup at the same time is going to be harder than just changing cargo.

Is knowing where the .rustup folder is important?

[brson]

@ollie27 I think it is yes. Like with .cargo, .git etc sometimes it's convenient to poke at internals. With rustup it seems to be important to know where the toolchains are stored for example.

[gyscos]

Putting things in the XDG folders doesn't make them opaque and inaccessible. Printing the path to downloaded toolchains (or showing this information in a rustup show command or anything) could help further.

Since cargo and rustup use different folders, I'd argue consistency is already lost (it's not like we had a ~/.rust directory with everything related - nor that this would be a better solution). If we can afford to rename rustup's folder while keeping it separate, then it makes sense to lead by the example and directly take the correct destination.

[kamalmarhubi]

On OS X it'd be nice to use ~/Library/Applicacation Support (eventually?).

[critiqjo]

The preferences crate can help with finding the platform-specific app-directory base, but it is not as great as appdirs yet.

Personally, I don't mind the status quo, since we have CARGO_HOME and RUSTUP_HOME environment variables.

[flying-sheep]

I'm really frustrated at the amount of projects deciding they're special snowflakes that don't need to follow standards.

Let's fix this now, before rustup is out of beta, to have inertia into the right direction.

[Diggsey]

rustup (when it was known as multirust-rs) used to follow the standard, at least for windows and mac, but was changed back to match the behaviour of cargo. If we're to make the change now it will need to be a concerted effort across the two projects with a well-tested upgrade path. I'd certainly like to make the change but it just hasn't been a priority, when there are so many other things that need doing.

[flying-sheep]

exactly that’s what always happens and what frustrates me. decisions like that are implemented ad-hoc, the fixes put on backburner, and once people would have time for it there’s suddenly inertia in the wrong direction and people have built tools relying on the hacky ad-hoc behavior that was never meant to last.

we have to switch now or we will do it never.

and to be honest, we should have thought about that from the inception.

[flying-sheep]

i also have no idea why there should be any reason to coordinate with cargo. can’t we use XDG and cargo later?

[mrhota]

@brson if this is something all Rust tools should do at the same time, does that mean it's RFC material?

[brson]

@mrhota Since it impacts so much of the ecosystem moving to platform-specific locations is probably RFC worthy, yes. It's probably important to be aware of all the activity in this cargo thread. cc @alexcrichton

[brson]

@flying-sheep I prefer to keep Rust's tooling consistent about this. Cargo and rustup are very closely related.

[brson]

This thread is about moving away from the multirust name though. Please do open a different thread do discuss XDG etc.

Edit: on second thought this thread is sufficiently about XDG now that I'll just change the op and make a new issue for the rename.

[brson]

cc #537

[liigo]

It's a chance to discard .multirust directory.

[ssokolow]

I really don't feel like screwing around with countless "special snowflake" applications, each with its own "move the profile" environment variable.

I run into enough games that put their configuration files in $HOME as NON-hidden directories and bypass $HOME using functions like getpwuid that, if I can't containerize them, I'll probably be implementing some kind of LD_PRELOAD shim to make functions like getpwuid lie about where ~ is and/or silently rewrite paths passed into functions like fopen.

(Ideally, the containerization, since that won't be outwitted by static linking)

Regardless of whether this is fixed, I'll come up with some kind of single-command (probably at install time) solution to force things like rustup and cargo to stop making a mess, whether they like it or not.

[flying-sheep]

I really don't feel like screwing around with countless "special snowflake" applications, each with its own "move the profile" environment variable.

yeah, i also really like to do ls ~/.config and get a list of configurable software ❤️

[retep998]

I just want rustup out of my home directory and into AppData. There is absolutely no reason for dot directories on Windows, especially since 1. they're a pain to work with and 2. it doesn't actually hide the folder. So please, be nice and move it to AppData, probably Local.

[chris-morgan]

@retep998 You can, of course, attrib +h %USERPROFILE%\.multirust. But then, people working in Rust on Windows probably have it set to show hidden files anyway.

[frewsxcv]

Would this change the path for configuration files for OSX users?

[ollie27]

I think the important discussion is exactly which directories we should be using. Obviously we should be following OS conventions where possible, that goes without saying.

On Windows I think %LOCALAPPDATA%\rustup makes the most sense.
On Linux I think $XDG_DATA_HOME/rustup with a fallback to ~/.local/share/rustup will follow the XDG Base Directory Specification nicely.

The binaries are currently installed in Cargo's bin directory which I assume is so you only have to add one thing to the $PATH. Are there any other reasons?

I suggest moving them as well to perhaps to %LOCALAPPDATA%\rustup\bin and ~/.local/bin on Windows and Linux respectively. This should mean that rustup will no longer care about Cargo's directories which will simplify things significantly. On some Linux distros like Fedora it will mean you don't have to add anything to the $PATH and with rust-lang/rfcs#1615 the binaries will be next to those installed with cargo install if that's important.

What do other people think? Also what directories should be used on OS X?

[fenhl]

@ollie27 command-line tools on OS X should use the same directories as on Linux, i.e. those defined in the XDG Base Directory spec.

[soc]

Heads up:

Work on cargo is underway in rust-lang/cargo#5183.

The fix for rustup will be next.

[luis-guimaraes-exoawk]

The pull request mentioned by @soc was closed without merging... This is still an important feature

[LucasFA]

For anyone interested, there's a pre-RFC in the forums:
https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747