-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Use platform-defined directories for cargo state #9178
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
This commit changes the cargo data directories from $HOME/.cargo to using the XDG spec directories. It also adds the directories crate as a dependency. Currently, only `XGD_DATA_HOME` (on Linux this is `$HOME/.local/share` by default) and `XDG_CACHE_HOME` (on Linux this is `$HOME/.cache` by default) are used. The priority of paths cargo will check is as follows: 1. Use `$CARGO_HOME`, if it is set 2. Use `$CARGO_CACHE_DIR`, `$CARGO_CONFIG_DIR`, etc, if they are set 3. If no environment variables are set, and `$HOME/.cargo` is present, use that 4. Finally, use the platform-default directory paths
89a9848
to
57b1d16
Compare
To ensure I understand the current state of things, this -- #8063 (comment) -- is still the status here I think? That is, I think the RFC feedback still needs synthesis/digestion and perhaps a follow-up RFC is in order? |
Sure thing! I will have a look at the existing RFC and some of the feedback and post the work in progress I come up with here. Somewhat unrelated, but is it possible to turn an PR back into a draft PR? |
Okay I read the OG RFC and most of the comments (which largely don't add any relevant rationale), and started a PR on my own RFC repo here: spacekookie/rfcs#1 to have discussions on (and keep this thread free for the technical implementation) |
☔ The latest upstream changes (presumably #9175) made this pull request unmergeable. Please resolve the merge conflicts. |
How could an existing There are also some third-party tools that store stuff in Maybe another environment variable could be set for 3rd party subcommands, giving a path where its okay to put stuff? That way they dont need to re-implement cargo logic |
We can write the migration guide in cargo reference and produce a warning with the URL . Most users should only handle
Third-party tools are individual programs. They should have their own data or cache directory instead of |
Is using |
I'm gonna close this due to inactivity, and per the followup discussion on the RFC linked above. Thanks! |
Continuation of PR #8063.
This PR changes the cargo config system to use the XDG spec directories, instead of using
$HOME/.cargo
.Currently it only uses
XDG_DATA_HOME
andXDG_CACHE_HOME
. There was some discussion in #1734 about also using the newXDG_BIN_HOME
directory, but this is not yet implemented.The priority of paths cargo will check is as follows:
$CARGO_HOME
, if it is set$CARGO_CACHE_DIR
,$CARGO_CONFIG_DIR
, etc, if they are set$HOME/.cargo
is present,use that