Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the XDG Base Directory Specification. #1734

Open
Earnestly opened this issue Jun 19, 2015 · 33 comments
Open

Support the XDG Base Directory Specification. #1734

Earnestly opened this issue Jun 19, 2015 · 33 comments
Labels
A-configuration Area: cargo config files and env vars C-feature-request Category:*Proposal* for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` E-hard Experience: Hard S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@Earnestly
Copy link

Earnestly commented Jun 19, 2015

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
Copy link

0X1A commented Jun 25, 2015

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
Copy link
Author

@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
Copy link

Yamakaky commented Sep 6, 2015

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

@0X1A
Copy link

0X1A commented Sep 6, 2015

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

@whitequark
Copy link
Member

You can use my xdg crate to implement this.

tbu- added a commit to tbu-/cargo that referenced this issue Nov 10, 2015
http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html

Strategy for backward-compatiblity:

When checking for the relevant cargo directories, check in the following
order of preference:

1) Use the environment variable `CARGO_HOME`.
2) Use the XDG directories if they exist.
3) Use the legacy location (~/.cargo) if it exists.
4) Fall back the XDG directories if everything else fails.

Fixes rust-lang#1734.
@nagisa
Copy link
Member

nagisa commented Dec 11, 2015

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

@whitequark
Copy link
Member

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

tbu- added a commit to tbu-/cargo that referenced this issue Jan 25, 2016
Strategy for backward-compatiblity:

When checking for the relevant Cargo directories, check in the following
order of preference:

1) Use the environment variable `CARGO_HOME`.
2) Use the platform-specific directories if they exist.
3) Use the legacy location (~/.cargo) if it exists.
4) Fall back to the platform-specific directories if everything else fails.

The new platform-specific directories are as follows:

On Windows, use `AppData\Local\Temp\Cargo` for cache files (obtained via
`GetTempPath`), `AppData\Roaming\Cargo` for the config files
(`FOLDERID_RoamingAppData`) and `AppData\Local\Programs\Cargo` for
installed binaries (`FOLDERID_UserProgramFiles`).

On Unixy systems, use the XDG spec: `~/.cache/cargo` for cache files,
`~/.config/cargo` for config, `~/.local/bin` for installed binaries.

http://standards.freedesktop.org/basedir-spec/basedir-spec-0.8.html
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html

On OS X, use `~/Library/Caches/Cargo` for cache files, `~/Library/Cargo`
for config files and `~/Library/Cargo/bin` for binary files.

Fixes rust-lang#1734. Fixes rust-lang#1976.
@Stebalien
Copy link
Contributor

@tbu- any progress?

@tbu-
Copy link
Contributor

tbu- commented Jul 31, 2016

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

@Abdillah
Copy link

Abdillah commented Oct 8, 2016

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-
Copy link
Contributor

tbu- commented Oct 8, 2016

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

@carols10cents carols10cents added A-configuration Area: cargo config files and env vars C-feature-request Category:*Proposal* for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` labels Sep 10, 2017
@sanmai-NL
Copy link

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
Copy link

@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
Copy link

sanmai-NL commented Feb 24, 2018

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
Copy link

Glandos commented Mar 10, 2018

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…

soc added a commit to soc/cargo that referenced this issue Apr 28, 2018
This change stops cargo from violating the operating system rules
regarding the placement of config, cache, ... directories on Linux,
macOS and Windows.

Existing directories and overrides are retained.

The precedence is as follows:

1) use the `CARGO_HOME` environment variable if it exists (legacy)
2) use `CARGO_CACHE_DIR`, `CARGO_CONFIG_DIR` etc. env vars if they exist
3) use the ~/.cargo directory if it exists (legacy)
4) follow operating system standards

A new cargo command, `dirs`,  is added, which can provide path
information to other command line tools.

Fixes:
  rust-lang#1734
  rust-lang#1976
  rust-lang/rust#12725

Addresses:
  rust-lang/rfcs#1615
  rust-lang#148,
  rust-lang#3981
@soredake
Copy link

Any progress on this?

@hasufell
Copy link

@whitequark

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

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

@piegamesde
Copy link

... 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
Copy link

eode commented Jul 29, 2020

@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
Copy link

fenollp commented Nov 3, 2020

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
Copy link

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
Copy link

eode commented Nov 13, 2020

@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
Copy link

eode commented Nov 23, 2020

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

@eode
Copy link

eode commented Dec 2, 2020

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
Copy link

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
Copy link

eode commented Dec 2, 2020

@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

This comment has been minimized.

@luis-guimaraes-exoawk

This comment was marked as off-topic.

@eode
Copy link

eode commented Jul 14, 2022

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.

@weihanglo weihanglo added E-hard Experience: Hard S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. labels May 14, 2023
@epage
Copy link
Contributor

epage commented May 23, 2023

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

@eirnym
Copy link

eirnym commented Jun 5, 2023

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
Copy link

eirnym commented Jun 5, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars C-feature-request Category:*Proposal* for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` E-hard Experience: Hard S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests