Use OS-native config, cache home directories

[Earnestly]

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…

[weihanglo]

It would be much appreciated if people can take look at and share their user stories in the pre-RFC. That's one way out to address this long-standing issue.

[eode]

Good to know!

[eirnym]

@weihanglo thank you for a link

[Glandos]

In case someone isn't aware, you can set RUSTUP_HOME & CARGO_HOME.

This is not the same. XDG defines configuration in $HOME/.config/ and cache in $HOME/.cache (and other directories). As far as I know, you can't do that with CARGO_HOME.

[oxalica]

@utkarshgupta137

In case someone isn't aware, you can set RUSTUP_HOME & CARGO_HOME.

I'd say that mostly does not fulfill the need of people coming to this issue, who usually want to split managing caches, configs and data. It's also stated in the previous postponed RFC rust-lang/rfcs#1615.

• Putting caches in designated cache directories allows backup tools to ignore
  them. (Linux, Windows, macOS. Example: Time Machine ignores the cache
  directory on macOS.)
• It makes it easier for users to manage, share and version-control their
  configuraton files, as configuration files from different applications end up

As a NixOS user who manages immutable cargo config with Nix, I have to do dirty symlink tricks to split $CARGO_HOME/{registry,git,config.toml} to different targets, so that cargo will not try to write to ro-mounted /nix/store and fail. That's all no issue if the RFC is actually implemented since we can set XDG_*_PATH separately.

In this time, I strongly agree this comment from previous RFC

The core problem is that those who are interested in fixing this don't make the decisions, and those making decisions aren't interested.

This issue is bothering a lot for us as cargo users, who may or may not have cargo development skills, while many (maybe only little?) cargo developer more lean towards keeping the current non-ergonomic situation with the reason of "compatibility"¹ or "always has been". So the only way left for us users to do is ranting out and gaining attention to show that the current situation is not as good as they think.

Footnotes

1. 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. ↩

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