Repository navigation
Tracking: Support for platformdirs (platform-specific system directories) such as XDG Paths #247
Description
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).
Activity
gyscos commentedon Apr 5, 2016
I may have missed the answer before, but why not use XDG specifications again? (
${XDG_DATA_HOME}/rustup)brson commentedon Apr 5, 2016
@gyscos It's because cargo doesn't. That's a change that all Rust tools need to make together.
ollie27 commentedon Apr 6, 2016
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 commentedon Apr 6, 2016
Consistency is important. If you know where one Rust tool puts its stuff you know where they all do.
ollie27 commentedon Apr 6, 2016
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 commentedon Apr 7, 2016
@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 commentedon Apr 7, 2016
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 showcommand 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
~/.rustdirectory 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 commentedon Apr 27, 2016
On OS X it'd be nice to use
~/Library/Applicacation Support(eventually?).critiqjo commentedon May 14, 2016
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_HOMEandRUSTUP_HOMEenvironment variables.flying-sheep commentedon May 14, 2016
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 commentedon May 14, 2016
rustup(when it was known asmultirust-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 commentedon May 14, 2016
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 commentedon May 14, 2016
i also have no idea why there should be any reason to coordinate with cargo. can’t we use XDG and cargo later?
mrhota commentedon Jun 19, 2016
@brson if this is something all Rust tools should do at the same time, does that mean it's RFC material?
20 remaining items
[-]Consider moving to platform-specific configuration directories[/-][+]Tracking: Platform-specific configuration directories[/+][-]Tracking: Platform-specific configuration directories[/-][+]Tracking: Refined configuration directories[/+][-]Tracking: Refined configuration directories[/-][+]Tracking: Support for XDG Paths[/+]$CARGO_HOME(~/.cargo) onrustup self uninstall#285rami3l commentedon May 4, 2026
This issue is from now on the tracking issue for rustup's GSoC 2026 project.
[-]Tracking: Support for XDG Paths[/-][+]Tracking: Support for platformdirs (platform-specific system directories) such as XDG Paths[/+]