Support the XDG Base Directory Specification.

[Earnestly]

This is a continuation from the previous (#148) pull request which your bot apparently merged, but in effect did not.

As there is no open issue about this, I've decided to open one so it is publicly known.

Much has been said in the previous pull request so I won't repeat it here.

For reference, here is a non-exhaustive list of software with varying degrees of compliance.

See also #1976

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

[soredake]

Any progress on this?

[hasufell]

@whitequark

... and it really should use ~/.local/bin;

~/.local/bin is not specified by the XDG spec.

[piegamesde]

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

~/.local/bin is not specified by the XDG spec.

FWIW, there is XDG_BIN_HOME that sadly never got commited to the spec, lost due to bad maintainership. I'd still recommend to use this, because at least it has defined (and agreed on) semantics.

[eode]

@piegamesde Not that it matters too much, as we'll probably just put things in ~/.local/bin if there's no spec, but I've opened an issue with XDG re: $XDG_BIN_HOME.

[fenollp]

Another advantage of complying with XDG: when trying to get some space off of your disks you can often trash ~/.cache.

So I'm asking for cargo to put a project's target/ under ~/.cache/cargo/sha256(project path)/target.
This would replace tools such as https://github.com/mihai-dinculescu/cargo-wipe

[christianbundy]

If anyone would like to help, I'm going to try to have XDG_BIN_HOME or its equivalent merged: https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14#note_682259

[eode]

@christianbundy Lent my support as much as possible.

However, of note is this: one way or the other, they will be documenting ~/.local (with ~/.local/bin) as the official 'default' location. So at the very least, this is a reasonable default for rust.

[eode]

I've made a PR with Lennart's original patchset related to this issue (which stalled and languished after all-around approval).

[eode]

Ok! the PR was merged (issue, pr). The result is that the official location for user-specific executables is as follows:

There is a single base directory relative to which
user-specific executable files may be written.

User-specific executable files may be stored in
$HOME/.local/bin. Distributions should ensure
this directory shows up in the UNIX $PATH
environment variable, at an appropriate place.

Since $HOME</literal> might be shared between systems of different achitectures, installing compiled binaries to $HOME/.local/bincould cause problems when used on systems of differing architectures. This is often not a problem, but the fact that $HOME` becomes partially achitecture-specific
if compiled binaries are placed in it should be kept in mind.

This has been merged, but has not yet been released. I have no clue what the XDG release schedule is.

Edit of course, this was anticipated, as it's the reasonable default, but they opted not to have an env-var for the location. I.e., it is architecture-specific, and if the user is using their homedir across architectures, they can just go figure it out themselves.

[piegamesde]

but they opted not to have an env-var for the location

I am mildy confused about realizing this only now, there were way too many similar patches in discussion – this is the first directory location whose path is hardcoded in the spec :/

Anyway, this really isn't a show stopper. Cargo shouldn't place any binaries directly into the .local/bin folder, but rather some script wrappers that gracefully fail when on a non-native architecture.

This has been merged, but has not yet been released.

Given the circumstances, it is fair to assume no breaking changes will happen to the spec between now and an eventual release. (A release would still be great though.)

[eode]

@piegamesde I fully agree that it's a bad idea not to have an env var for this. I've added your point to the XDG conversation on closing that issue.

I don't even think that the XDG people were expecting dev tools to handle that -- I think it's more along the lines of "If the user/distro is going to try to support multiple architectures for a homedir, that should be detected and handled by links set in ~/.profile or equivalent". Asking every dev tool / local user software (once installed) to fail gracefully if the architecture changes is.. ..well.. ..too much. They'd never get multiple projects, systems, etc to go along with that, even though it might just be a matter of wrapping executables in a short script.

Given the circumstances, it is fair to assume no breaking changes will happen to the spec between now and an eventual release. (A release would still be great though.)

Agreed. At this point, even if they decide to use an env var, it would default to ~/.local/bin.

[eode]

I pinged the XDG spec in case they're willing to move on XDG_BIN_DIR (there has been some input from other projects in the mean time). I do think that supporting it if it exists without expecting it to exist might be a reasonable step. The only reason for anyone to create an XDG_BIN_DIR env var is for that specific purpose, anyways.

[epage]

https://poignardazur.github.io/2023/05/23/platform-compliance-in-cargo/ for a summary of this

[eirnym]

For backward compatibility it's about correct order of execution to guess placement and logic behind it.

I personally will be happy even if only config.toml could be placed to XDG_CONFIG folder first and only then slowly without rushing a thing other files and folders as per discussion. This is a relatively small change to make, and I guess that community will be happy to have at least this.

The placement of config.toml I propose is following (at the very end of the list):

1. If CARGO_HOME is defined, use it
2. If XDG_CONFIG is defined, use it
3. If ~/.config/cargo/config.toml exists, use it
4. If ~/.cargo/config.toml exists, use it.

[eirnym]

If any tool uses hard coded path, then this tool must be fixed to use correct order. I don't see a problem with it.

If cargo would have a way from command line to show whole actual configuration, other tools can use this as well without a requirement to hardcode any path