Tracking: Support for platformdirs (platform-specific system directories) such as XDG Paths

[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.