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.

[Stebalien]

@tbu- any progress?

[tbu-]

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

[Abdillah]

It's the only thing I missed in rust ecosystem!
Maybe we can rebase the patch to keep it synced with current development.

Or to separate the patch into three platform so that it will be available on partial inclusion.

[tbu-]

I'll rebase the patch or the partial patch if this gets accepted. This won't be the problem.

[sanmai-NL]

I don’t know where this came from, but on Linux I apparently have both

• CARGO_HOME being ~/.cargo/bin/ as well as
• CARGO_HOME2 being ~/.cargo/bin/bin/ . 😕

[genodeftest]

@sanmai-NL Where does your CARGO_HOME2 come from? I only have CARGO_HOME, which I set to "$XDG_DATA_HOME"/cargo in my ~/.bashrc.

[sanmai-NL]

I have no idea, probably just some leftover from messing around when there was no Arch Linux package for Cargo yet. Note that my CARGO_HOME was also wrong, the bin path component should only be appended to CARGO_HOME within the PATH env var instead.

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

[epage]

I'm unlocking this and hiding the most of the recent posts.

I would ask that people be respectful to others and that includes not assigning intent to others I think a general assumption we can make is that we all want what is best for the users of cargo.

A summary of the conversation from some of the hidden posts:

• A use case raised is "non-rust users", whether as a side effect of system or other language package managers building from source. As Rust is adopted in more places, this will grow to become a bigger problem. This affects more than this issue but also issues like Tracking Issue for garbage collection #12633.
• Concern was raised over the wider ecosystem drag Cargo is adding to the effort for adopting XDG in the wider ecosystem
• CARGO_HOME can be used to move ~/.cargo but this won't get the full benefit if you have config in that location or depending on how strict you are about the different paths
• You could symlink the different locations. This could likely be improved (cargo auto-detecting certain symlink targets don't exist and creating them).

[totikom]

I think, that I know a hacky solution for locating build directory (target) in the XDG-compliant way.

target is actually a default value for $CARGO_TARGET_DIR, so you can add:

alias cargo = 'CARGO_TARGET_DIR=$XDG_CACHE_DIR/rust-builds/$(cargo metadata --no-deps --offline | extract_name_magic) cargo'

Where extract_name_magic is a combination of grep and sed which will extract the package name.

By using this alias, you'll get all the cargo commands working as expected with separate XDG-compliant build directories for each project.

Tomorrow I'll implement extract_name_magic for completeness.

[epage]

FYI this is about everything in the home directory today. There is a separate issue (and an open RFC!) about centralizing target dirs. On mobile or I'd get you the linksd

[weihanglo]

FYI this is about everything in the home directory today. There is a separate issue (and an open RFC!) about centralizing target dirs. On mobile or I'd get you the linksd

See rust-lang/rfcs#3371 and #11156 (if I got it correctly).

[asasine]

In one of several relevant issues (sorry I cannot find it immediately), I saw someone treat cargo-audit storing their database inside $CARGO_HOME as compatibility concerns. That's blowing my mind that a "security tool" is writing random private stuff into cargo dedicated path without consent, which is taken as a positive example. I'd treat that operation itself as security issue, and hope they won't modify $CARGO_HOME/config.toml next time. Thankfully I'm using Nix so the config file is ro-mounted. ↩

@oxalica

I believe this was from the Pre RFC thread https://internals.rust-lang.org/t/pre-rfc-split-cargo-home/19747/26

[poscat0x04]

FWIW cabal (The haskell counterpart of cargo) migrated to XDG directories on version 3.10. The behavior is that if CABAL_DIR (equivalent to CARGO_HOME, present before 3.10) is set, cabal will fall back to the old behavior, i.e., storing everything in CABAL_DIR, otherwise cabal will follow the XDG spec.

[LunarLambda]

I would at absolute minimum like to see ability to use $XDG_CONFIG_HOME/cargo/config.toml.

I keep CARGO_HOME in ~/.local/share/cargo (and RUSTUP_HOME similarly). Generally anything in ~/.local/share should be things I don't need to backup or track and can simply re-download/reinstall if needed. Whereas my config directory is fully tracked, and right now i need to take extra steps with symlinks.

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

[mutech]

@epage Thank you for commenting. I see how meta discussions like this don't necessarily contribute to solve this, I would much rather have a private word with you. My intention is not to be rough, hurt or harm you and most of all I really don't want to be create trouble. English is not my native language. It's also not my culture. I'm German, and we have our reputation for a reason (the one about rudeness, the other one even more so). My intention is not to be rude, but to be understood.

Look at it from my side. You're stepping on my toes. I don't believe you do that to hurt or annoy me, but it hurts, even if only a little. Every time I come here commenting, it's because I spend between 10-30m of - as I see it - clean up after you.

I think it would actually be better if you would close this issue refusing to implement it. That would not prevent you from eventually doing something about it. It would not provoke me or others to try to accelerate the process. But keeping a ticket open for 10 years is really offensive. Not to you, but to me and people like me.

@oli-obk You make a good point. I feel a bit guilty making myself part of the problem. At the same time, I think this particular issue is a special case, because of it's age.

I feel strongly about ethics. This is a complicated case, because I'm not a paying customer, you have no obligations to me in regard of what you do in this project. For the most part. But you are not completely free from responsibility to people whom your decisions impact. The extreme example would be if you added virus to your product. You don't, but you could and if you did, that would be trouble. This case is a grey area, where you clearly have no malicious intend, but you create an impact that is felt by some as damaging. I keep having to spend time to clean up after you, even though I'm not even directly using your software.

If I interpret epage correctly, he saw that argument as a valid point or at least one deserving of some consideration. If it's a valid point, it deserves a consequence, and "be patient" on a ticket that's up for 10 years is not really something that makes me feel any better while I'm cleaning up.

We all live in an era that is defined by divisions and unnecessary conflicts. I am old enough to remember a time when there was a whole lot more of respect and cooperation. Even at that time, people were rough. But that didn't necessarily mean disrespect, Sometimes people are angry for a reason and it's not always the only option to call "language", sometimes considering a dissonant contribution might be valuable.

I miss the time when controversy triggered a desire to start a discussion and work towards a common understanding. If we can only talk if we first agree, what's the purpose of talking?

I reread this post before sending. Nothing I wrote here is intended to inflame conflict or even be rough. I actually respect you. I am just plainly writing exactly what I'm thinking. If this is rough, then I should better be banned from github, because I just can't be smoother than this without pretending to be something I'm not.