Use OS-native config, cache home directories

[Earnestly]

Maintainer's notes:

• A Pre-RFC has been started that splits out the first half of t his work (making the paths configurable) to have a smaller, more focused conversation

---

For Linux-like systems, we should be using XDG. See arch's wiki for a non-exhaustive list of software with varying degrees of compliance.

For Windows, everything should go in ~/appdata/locallow or ~/appdata/local,since ~/.cargo is just a cache, AFAICT. This is FOLDERID_LocalAppData for SHGetKnownFolderPath, CSIDL_LOCAL_APPDATA for SHGetFolderPath, and %LOCALAPPDATA% in the environment.

[0X1A]

Have been stumped by this as well. Looked for Cargo's config in ~/.config/cargo only to find nothing. Don't really understand why Cargo places its config in ~/.cargo and the environment variable
CARGO_HOME, while nice is entirely useless. If the user's XDG is not set then it would be fine to place in ~/.cargo.

[Earnestly]

@0X1A If the respective XDG_* variables are not set, they should fallback
to the appropriate defaults as defined by the specification. The unfortunate
legacy behaviour cargo needlessly introduced will likely just add the code
bloat.

[Yamakaky]

Is someone working on this ? The more we wait, the more difficult it will be to change the default.

[0X1A]

@Yamakaky AFAIK there isn't anything being done about it

[whitequark]

You can use my xdg crate to implement this.

[nagisa]

cargo install now installs into ~/.cargo/bin.

[whitequark]

... and it really should use ~/.local/bin; there's precedent already in the behavior pip install --user, at least.

[tbu-]

@Stebalien Waiting for rust-lang/rfcs#1615.

[Glandos]

Another issue with not respecting XDG: backups. My current backup profiles knows that it should avoid ~/.cache/ directory. And cargo is creating a lot of things into ~/.cargo that is only cache data, not useful to backup…

[weihanglo]

If anyone wants to help, the already-mentioned pre-RFC is the first step toward a solution, though it is still under discussion and hasn't reached a consensus yet. The original author of that post (epage) doesn't seem to have time to work on it, so it probably needs some other folks to take care of it.

[epage]

To make it more discoverable, I've added a link to my Pre-RFC to the issue. I've also updated the Pre-RFC Motivation section with additional constraints XDG support is operating under that make this non-trivial.

[oli-obk]

Moderator note: It's ok to be angry and frustrated. So are the maintainers at the sheer number of things that need doing and fixing and that they don't get to. Priorities and maintainers change, things fall under the bus. That's life. It's not as easy as just deciding to fix this issue, even if it may seems so from the outside.

Please stay on topic, this meta discussion serves no point other than venting, use your private spaces for that.

I'm aware a multi hundred comment issue with a linked RFC with lots of comments is not enjoyable to read to get the full picture. So a contribution that needs no rust knowledge would be to write a summary of the RFC discussion and open discussion items on the RFC.

[ddevault]

I also started a thread to discuss the matter of who is responsible for fixing bugs like this and when:

https://internals.rust-lang.org/t/rusts-responsibility-to-engage-in-good-neighborly-behavior/22193

[oli-obk]

Moderator note: this is not productive. In what open source community has it ever helped to just comment more and more about something that everyone is aware of?

I don't want further discussion here, the internals threads are staying unhidden. Further venting here will result in temporary bans for cooling off

[Manishearth]

FWIW for people interested in trying to figure out this problem, Josh Triplett wrote a pretty good summary of the concerns here. It does not drill into the specifics of the various challenges; it talks about the non-obvious sources of the challenges, but it also alludes to current efforts to work on this. If people are interested in knowing more, I would suggest engaging with Josh in that thread.

AIUI even writing something up about "what has been tried already, what work needs to be done, what are good areas of research" requires a fair amount of work but it might be valuable for people in the know to do that and potentially list it in the header of this issue so that there is food for collaboration.

[oli-obk]

Since I'm gonna mark some more things as off-topic now, here's some information about how discussions/issues are supposed to be performed/used and how and why we're moderating things as we are:

• issues are places for tracking the development of things. long discussions make them particularly unusable, partly because github linear threads are not very good for looking up information later, partly because you then end up with lots of text to go through to figure something out. We encourage most discussion to happen on zulip and internals and rarely posting on issues.
• on top of that, meta discussions (moderation, prioritization, +1 comments), just hide the technical discussions and posts, which is why we mark them as off topic. They don't disappear, but they don't distract from the posts containing technical information.
• as I stated before, we are aware of this issue and the importance to folk. There are people actively doing design work to avoid breaking even more people, which is higher priority than resolving annoyances (which can be really annoying, yes). There are people doing preliminary cleanup work and implementation work to experiment and test and give feedback to the design work. All of that is happening. Drowning those folk in discussions about them not being fast or good enough is not going to make them more motivated to solve this problem.
• personal note: I really want this solved, so consider how frustrating it feels for mods to have to moderate folk (who make a good technical point that you agree with) because of their behavior.
• if you have any concerns about moderation, it is not helpful to bring this up in the thread where it's not on topic and just results in more meta discussion. Bring it up to us in an email or DMs on zulip.

[Ygg01]

Question for mods, if someone wants to help with this issue, how can one help? I saw the https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747/62 thread and assuming I'm assuming it's related.

What are steps new contributors can help with?

[epage]

Less mods and more Cargo team.

The biggest questions right now are around rustup. This will involve both understanding what rustup does and why, exploring options, and bouncing those options off of the two teams. I was planning to have that talk with them in-person at the All Hands in May