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
Comments
Have been stumped by this as well. Looked for Cargo's config in |
@0X1A If the respective |
Is someone working on this ? The more we wait, the more difficult it will be to change the default. |
@Yamakaky AFAIK there isn't anything being done about it |
You can use my xdg crate to implement this. |
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.
cargo install now installs into |
... and it really should use |
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.
@tbu- any progress? |
@Stebalien Waiting for rust-lang/rfcs#1615. |
It's the only thing I missed in rust ecosystem! Or to separate the patch into three platform so that it will be available on partial inclusion. |
I'll rebase the patch or the partial patch if this gets accepted. This won't be the problem. |
I don’t know where this came from, but on Linux I apparently have both
|
@sanmai-NL Where does your |
I have no idea, probably just some leftover from messing around when there was no Arch Linux package for Cargo yet. Note that my |
Another issue with not respecting XDG: backups. My current backup profiles knows that it should avoid |
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
Any progress on this? |
|
FWIW, there is |
@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: |
Another advantage of complying with XDG: when trying to get some space off of your disks you can often trash So I'm asking for cargo to put a project's |
If anyone would like to help, I'm going to try to have |
@christianbundy Lent my support as much as possible. However, of note is this: one way or the other, they will be documenting |
I've made a PR with Lennart's original patchset related to this issue (which stalled and languished after all-around approval). |
Ok! the PR was merged (issue, pr). The result is that the official location for user-specific executables is as follows:
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. |
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
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.) |
@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
Agreed. At this point, even if they decide to use an env var, it would default to |
This comment has been minimized.
This comment has been minimized.
This comment was marked as off-topic.
This comment was marked as off-topic.
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. |
https://poignardazur.github.io/2023/05/23/platform-compliance-in-cargo/ for a summary of this |
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 The placement of config.toml I propose is following (at the very end of the list):
|
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 |
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
The text was updated successfully, but these errors were encountered: