Support the XDG Base Directory Specification.

[Earnestly]

This is a continuation from the previous (https://github.com/rust-lang/cargo/pull/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.

[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/ . :confused:

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

[Eh2406]

cc https://github.com/rust-lang/cargo/pull/5183 and https://github.com/rust-lang/rfcs/pull/1615

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

[ddevault]

Six years.

[luis-guimaraes-exoawk]

Please add support for XDG...

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