Let Cargo put data into platform-specific directories #1615

tbu- · 2016-05-14T16:58:59Z

tbu- · 2016-05-14T17:01:52Z

There's a stale pull request to do something like this: rust-lang/cargo#2127, I'll gladly update it if it is desired.

I figured that it might be big enough of a change to justify an RFC.

steveklabnik · 2016-05-14T17:38:33Z

text/1615-cargo-platform-standards.md

+
+* This increases the complexity of where to find the files Cargo uses. This can
+  be alleviated by providing library functions for Cargo related tools and a
+  command line to tell which paths are in use.


It's not just this though; it's also things like documentation, explaining how cargo works to the user, etc

Good point, added to the section.

plietar · 2016-05-16T00:24:04Z

text/1615-cargo-platform-standards.md

+
+```
+cache:    .cache/cargo
+config    .config/cargo


These should use the XDG_CONFIG_HOME and XDG_CACHE_HOME environment variables

They are, perhaps I should clarify that a little. We're following the XDG spec, and by default it's these directories.

+1 on clarification.

withoutboats · 2016-05-16T00:45:38Z

I personally think all CLI tools should adopt XDG on all *nix platforms as the only reasonable attempt at a standard that anyone's produced. There's no actual standard on any *nix platform as far as I know, and I don't see a way that storing the files in the way specified by XDG is worse than storing them in ~/.cargo and ~/.rustup.

I don't think that Rust tools should do something different on OS X from what they do on other *nixen, for the reasons cited in the issue.

tbu- · 2016-05-16T08:24:06Z

@withoutboats Indeed, and that's also what pip does. I've written this alternative down in the Alternatives section.

randomPoison · 2016-05-16T16:53:09Z

text/1615-cargo-platform-standards.md

+* Putting caches in designated cache directories allows backup tools to ignore
+  them.
+* Using a `.cargo` directory on Windows is not idiomatic at all, no programs
+  for Windows would such a directory.


Typo: "no programs for Windows would such a directory".

This swaps an alternative with the appropiate section in detailed design.

tbu- · 2016-05-16T17:17:05Z

@withoutboats I exchanged the plan for OS X with one of the alternatives. Now everything is the same across non-Windows platforms and only Windows differs.

fenhl · 2016-05-18T03:24:22Z

Another huge upside to this is that it removes clutter from ~.

liigo · 2016-05-20T01:19:00Z

so it interacts well with other tools on that platform

Could you elabrate? What tools will interacts well (better) with Cargo, and why?

Edit: cache or disk cleanup tools will benifit at least, as the motivation section said.

alexcrichton · 2016-05-24T18:01:28Z

One drawback that may want to be added to this is that there are a good number of other apps and such which don't follow the XDG spec on Linux, and likely for their own "good reasons". This in turn means that if one day the spec becomes widely adopted it will likely need to be changed in one form or another. Put another way, many other major projects aren't following this spec, and to follow the spec it's quite likely that it'll need some sort of breaking change in one way or another. It's seems like it may be risky to hitch ourselves to this bandwagon?

Also, are there any other apps which follow XDG on OSX? Is the spec even defined for OSX? I'd be quite hesitant to follow a Linux spec on OSX as it seems like we'd just be winding up in the same situation of OSX users thinking that we're not doing the "native thing"

sfackler · 2016-05-24T18:28:26Z

@alexcrichton On my MacBook, I have "configstore", "fish", "git', "gtk-2.0", "htop", and "nvim" directories in my ~/.config.

Ericson2314 · 2016-05-24T18:38:08Z

On Linux, my impression is that all per-app dotfiles/dotdirs either predate or are done in ignorance of the XDG spec. Separating configuration from caching is quite useful and I cannot envision any downsides.

reddraggone9 · 2016-05-24T18:41:52Z

On Linux, my impression is that all per-app dotfiles/dotdirs either predate or are done in ignorance of the XDG spec.

That's been my experience as well. @alexcrichton Are you aware of any projects that would follow the spec if some sort breaking change were implemented? Most cases I've seen where it was brought up and rejected were due to inertia.

codyps · 2016-05-24T19:02:44Z

@alexcrichton on linux:

% ls .config 
Trolltech.conf  d-feet   gconf     gtk-2.0  i3status      octave    radare2     xbuild
chromium        dconf    git       htop     menus         pianobar  systemd     xfce4
configstore     freerdp  gpicview  i3       monitors.xml  pulse
% ls .cache 
bower                                                                            fontconfig     mozilla
chromium                                                                         g-ir-scanner   msmtp.log
dconf                                                                            gitg           pacaur
dmenu_run                                                                        gstreamer-1.0  pip
event-sound-cache.tdb.4e8b8a8a9ece45529a7ea0bb66e3f2b7.x86_64-unknown-linux-gnu  guile          xsession-errors-:0.0
event-sound-cache.tdb.two.x86_64-unknown-linux-gnu                               jedi

Is there a specific program with issues with xdg that you're thinking of?

liigo · 2016-06-21T08:45:45Z

From the RFC text:

Benefits include:

[1] Using a standard directory for binary outputs can allow the user to execute Cargo-installed binaries without modifying their PATH variable. E.g. on Fedora this is apparantly already the case, in Debian there's a ticket to include it.

[2] Putting caches in designated cache directories allows backup tools to ignore them.

[3] Using a .cargo directory on Windows is not idiomatic at all, no programs for Windows would use such a directory.

[4] Platform specific clean-up tools such as the Disk Cleanup Wizard work with Cargo (it wouldn't be very useful to try to modify the Wizard instead of Cargo to make this work).

[1]: the installer can/already do this (one off job). not a benefit.
[2]: to make 3rd-party tools happy.
[3]: git uses .git, difficult to say it's wrong. not a benefit.
[4]: to make 3rd-party tools happy.

So, there is only one benefit: to make 3rd-party tools happy, to help them find/clean cargo's cache data.

And this is not a benefit for us, the users and developers of cargo. We get little benefit on this.

But it will make difficulty to our life: we must remember more dirs, if we want to find them; we must do more os-specific work to implement it and maintain it; we can't easily create a portable cargo that all in one directory.

One more thing: it's not clear what will be put into cache directory. (e.g. Will .cargo\registry in cache? Will some of target/debug/* in cache?)

(XDG spec is nice. But what's the benefit if we follow it?)

fenhl · 2016-06-21T09:00:58Z

@liigo It is not the only benefit. See my comment from earlier. This should also be added to the RFC text.

tbu- · 2016-06-21T09:21:39Z

@liigo

[1]: the installer can/already do this (one off job). not a benefit.
[2]: to make 3rd-party tools happy.
[3]: git uses .git, difficult to say it's wrong. not a benefit.
[4]: to make 3rd-party tools happy.

[1] is a benefit because that way, you don't end up with a path in $PATH for each package manager you have.
[3] Just because git does it wrong, doesn't mean that we can't do it right.
[2] and [4] is not to make 3rd party tools happy, but to make Cargo work with them.

I think it's pretty clear that all of these are benefits. Whether they're worth the trade-off is what the RFC discussion should be about, but claiming that they aren't benefits isn't really helping.

EDIT: Regarding making 3rd party tools happy vs interacting with them: I as a user would be happy if the backup tool would know to ignore the Cargo cache. This is not for the benefit of the 3rd party tool, but for the benefit of me, the user of Cargo.

withoutboats · 2016-06-21T18:59:45Z

@liigo as a cargo user who sometimes uses other tools also, making cargo interoperate with them better definitely makes my life better. :-)

alexcrichton · 2016-07-05T18:06:14Z

@reddraggone9

@alexcrichton Are you aware of any projects that would follow the spec if some sort breaking change were implemented?

To me it seems like everyone would want to implement the change but may not be able to. If no one actually implements it then no one's following the spec, which seems to defeat the purpose of having it in the first place?

It seems to me that if updates can't happen, then the spec is frozen as-is today. Then if it's frozen as-is there are major tools which have good reasons for not following it, and there's little hope for those reasons to get resolved?

@jmesmon

Is there a specific program with issues with xdg that you're thinking of?

Looking in my home folder, programs which don't follow xdg include:

ssh
rubygems
bundler
npm
git (maybe)
zsh/bash
pip
docker
cmake
ccache

Notably including many other languages' package managers.

I forget if this has been brought up before, but I've at least discussed it with others. The point about operating with third-party programs is also an interesting one. There are programs which don't follow XDG, so any robust third-party program would already have to handle non-conforming programs with some heuristics. In that sense you may not actually get any benefit at all if Cargo follows XDG because the heuristics are already correctly classifying Cargo. If Cargo isn't falling in the right bucket but could easily do so for some popular programs, that would also be a reasonable course of action I think.

tbu- · 2016-07-05T18:56:45Z

Both pip and git support XDG.

The point about operating with third-party programs is also an interesting one. There are programs which don't follow XDG, so any robust third-party program would already have to handle non-conforming programs with some heuristics.

I use rsnapshot for backups. The heuristic is the user adding exceptions on their own. It would be much nicer if Cargo didn't need an exception.

I mentioned advantages and disadvantages in the RFC. It seems that at least the advantages are real for some users. Maybe the discussion should focus on how to weigh these arguments against each other. Especially on Windows, there seems little resistance against using the Windows-specific directories.

reddraggone9 · 2016-07-05T19:12:40Z

@alexcrichton

To me it seems like everyone would want to implement the change but may not be able to.

Not everyone. For some programs which have been around longer than I've been alive, following the XDG spec as a fallback would be a change in functionality that has worked for decades. Inertia gets in the way there. "If it ain't broke, don't fix it." I'm not aware of any project that has been told about the spec and decided not to follow it but would have followed it if the spec had X changed where X wasn't just keep doing what already works.

If no one actually implements it then no one's following the spec, which seems to defeat the purpose of having it in the first place?

People do implement it:

$ ls .config
abrt                          goa-1.0        Pinta
anjuta                        google-chrome  ppsspp
autostart                     gtk-2.0        pulse
beets                         gtk-3.0        QtProject.conf
cef_user_data                 gvbam          ranger
Clementine                    hexchat        retroarch
CuteMarkEd Project            htop           Rygel
dconf                         ibus           rygel.conf
dleyna-renderer-service.conf  imsettings     sealert.conf
dleyna-server-service.conf    inkscape       sonata
easytag                       insta-site     syncthing
enchant                       jstest-gtk     systemd
eog                           keepnote       tilda
epiphany                      libreoffice    tomboy
evince                        libvirt        totem
evolution                     markdownlint   tracker
filezilla                     menus          Trolltech.conf
gambatte                      mimeapps.list  unity3d
gconf                         monitors.xml   user-dirs.dirs
gedit                         mono.addins    user-dirs.locale
gespeaker                     MonoGame       VirtualBox
git                           mopidy         vlc
gnome-boxes                   mpv            watch-later
gnome-builder                 mupen64plus    yelp
gnome-control-center          myapp          youtube-dl
gnome-initial-setup-done      nautilus       Zeal
gnome-session                 nvim
gnote                         PCSX2

Just not everyone:

$ ls -d .?*
..              .git-credential-cache  .lastpass        .rbtools-cookies
.adobe          .gitk                  .lesshst         .sdkman
.bash_aliases   .gnome                 .local           .serverauth.22085
.bash_history   .gnupg                 .m2              .serverauth.4384
.bash_logout    .gradle                .macromedia      .speech-dispatcher
.bashrc         .grails                .mozilla         .ssh
.cache          .grails_history        .multirust       .subversion
.cargo          .groovy                .netrc           .Xauthority
.config         .gstreamer-0.10        .npm             .xinitrc
.emacs.d        .ICEauthority          .nvimlog         .xsel.log
.esd_auth       .idlerc                .pki             .zshrc
.exercism.json  .inputrc               .profile
.gimp-2.8       .java                  .python_history

It seems to me that if updates can't happen, then the spec is frozen as-is today. Then if it's frozen as-is there are major tools which have good reasons for not following it, and there's little hope for those reasons to get resolved?

If you're going to make that argument, having at least one example would be nice. You have a point about most other languages' package managers though. You can add sdkman to the list.

codyps · 2016-07-05T20:37:29Z

@alexcrichton

I asked about programs that have issues with XDG, not ones simply that don't impliment it. I'm looking for a downside, a complication, that would cause a program to actively avoid XDG.

Right now one hasn't been presented.

there are major tools which have good reasons for not following it

I don't believe that is the case. At the least, no one has noted a reason (other than a program being old or inertia) that things don't impliment it. Please let us know if there is some reason you're aware of.

brson · 2016-07-12T20:38:57Z

My opinions on this subject (not commenting directly on the content of the RFC, which I've only skimmed - sorry).

I think we should change where .cargo is located on windows. With back-compat code to support old installs. We chose the wrong place to put this directory. It should keep the .cargo name for consistency across platforms.

It's important for consistency that users can find Rust tools in expected places. There is no universal agreement on Unixes about the future of the XDG spec, and we should not use it by default. For those that want XDG we should consider making it optional.

ehuss · 2021-10-08T19:17:25Z

I'm going to move to postpone this. We're acknowledging the reality that this isn't moving forward at this time. The Cargo team is interested in seeing better native platform layouts. However, it is evident that there are a lot of details to consider, and discussing them on a PR with over 300 comments probably isn't the best way forward. Unfortunately I don't have an easy answer at this time on how this can make progress, as the team currently doesn't have the capacity to help in depth.

Thank you everyone for the comments and time spent looking into this.

@rfcbot fcp postpone

rfcbot · 2021-10-08T19:17:26Z

joshtriplett · 2021-11-02T19:20:12Z

I do very much want to see this, but I agree that this doesn't seem to be making forward progress at this time.

@rfcbot reviewed

rfcbot · 2022-02-15T20:21:08Z

🔔 This is now entering its final comment period, as per the review above. 🔔

rfcbot · 2022-02-25T20:21:37Z

The final comment period, with a disposition to postpone, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This is now postponed.

japm48 · 2022-06-05T21:12:06Z

I would like to see this implemented. Rust toolchain (incl. rustup) is one of the last things I have polluting my $HOME that I have to consider when making config backups.

What is the policy on "Postponed" RFCs? When would it be feasible to reconsider this?

soc · 2022-06-16T16:43:37Z

This process is indeed not clear. I started working on it, then got reprimanded about daring to work on it so I stopped. And now it is postponed because nobody is working on it.

The core problem is that those who are interested in fixing this don't make the decisions, and those making decisions aren't interested.

tbu- · 2022-06-21T14:10:44Z

I would like to see this implemented. Rust toolchain (incl. rustup) is one of the last things I have polluting my $HOME that I have to consider when making config backups.

You can try submitting a new RFC. :)

soc · 2022-07-22T15:12:36Z

Can we get a clear response on what's wrong with the current RFC, so those issues can be addressed?

This is now the second time I receive a notification mail for a comment that has disappeared in the meantime.

I'm wondering who keeps deleting comments, and for which purpose.

eode · 2022-07-22T15:17:09Z

For future reference -- Ruby supports the XDG spec as of 2020: ruby/ruby#2174

aidanharris · 2022-07-22T15:25:33Z

Please be mindful of those that are only subscribed to this issue because they want to know when/if this will be implemented. To my knowledge there was nothing wrong with the RFC. The issue got closed because there was no clear plan for its implementation. If there's another RFC, I hope it won't suffer the same fate.

soc · 2022-07-22T15:31:59Z

To my knowledge there was nothing wrong with the RFC. The issue got closed because there was no clear plan for its implementation.

"I started working on it, then got reprimanded about daring to work on it so I stopped. And now it is postponed because nobody is working on it." – deleted comment

If there's another RFC, I hope it won't suffer the same fate.

Why would it go differently if nobody knows what needs to be done differently, compared to this effort?

aidanharris · 2022-07-22T15:45:58Z

@soc No clear plan [from the leadership]. Somebody working on the issue won't guarantee that it makes it into a release if nobody that makes the decisions is invested in it enough.

RokeJulianLockhart · 2022-07-25T18:16:00Z

@aidanharris, regarding "#1615 (comment)", subscribers to the issue via GitHub are able to customize their subscription to the issue so that they are solely notified of when it is closed or reopened:

PoignardAzur · 2023-05-23T11:25:24Z

Quick plug - I wrote an analysis on the subject of platform-compliance and why it's stalled:

https://poignardazur.github.io/2023/05/23/platform-compliance-in-cargo/

Refs. - https://rust-lang.github.io/rustup/environment-variables.html - https://doc.rust-lang.org/cargo/reference/environment-variables.html See also: - https://wiki.archlinux.org/title/XDG_Base_Directory#Partial - rust-lang/rustup#247 - rust-lang/cargo#1734 - rust-lang/rfcs#1615 - rust-lang/cargo#5183 - rust-lang/cargo#148

Let Cargo put data into platform-specific directories

5770cea

steveklabnik reviewed May 14, 2016
View reviewed changes

Mention how this can affect tutorials (thanks @steveklabnik)

c0e0a42

plietar reviewed May 16, 2016
View reviewed changes

randomPoison reviewed May 16, 2016
View reviewed changes

tbu- added 2 commits May 16, 2016 19:14

Fix a typo

170edb7

Use XDG on OS X as well

38f82c4

This swaps an alternative with the appropiate section in detailed design.

alexcrichton added the T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. label May 16, 2016

Clarify that we're following the XDG spec on non-Windows

6c05471

rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-postpone This RFC is in PFCP or FCP with a disposition to postpone it. labels Oct 8, 2021

rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Feb 15, 2022

rfcbot added finished-final-comment-period The final comment period is finished for this RFC. to-announce and removed final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. labels Feb 25, 2022

rfcbot added postponed RFCs that have been postponed and may be revisited at a later time. and removed disposition-postpone This RFC is in PFCP or FCP with a disposition to postpone it. labels Feb 25, 2022

rfcbot closed this Feb 25, 2022

brendanzab mentioned this pull request Aug 23, 2022

Issues with 'version `GLIBC_2.32' not found' when running clippy on CI oxalica/rust-overlay#54

Closed

rbtcollins mentioned this pull request Feb 25, 2023

Set environment variables in rust-toolchain.toml rust-lang/rustup#2883

Open

machupicchubeta mentioned this pull request Oct 29, 2023

Move apps config and/or data directory under XDG Base Directory machupicchubeta/dotfiles#451

Merged

LucasFA mentioned this pull request Feb 13, 2024

Use XDG specification environment variables aome510/spotify-player#357

Open

Let Cargo put data into platform-specific directories #1615

Let Cargo put data into platform-specific directories #1615

Conversation

tbu- commented May 14, 2016

tbu- commented May 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

withoutboats commented May 16, 2016

tbu- commented May 16, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tbu- commented May 16, 2016 • edited Loading

fenhl commented May 18, 2016

liigo commented May 20, 2016 • edited Loading

alexcrichton commented May 24, 2016

sfackler commented May 24, 2016

Ericson2314 commented May 24, 2016

reddraggone9 commented May 24, 2016

codyps commented May 24, 2016 • edited Loading

liigo commented Jun 21, 2016 • edited Loading

fenhl commented Jun 21, 2016

tbu- commented Jun 21, 2016 • edited Loading

withoutboats commented Jun 21, 2016

alexcrichton commented Jul 5, 2016

tbu- commented Jul 5, 2016

reddraggone9 commented Jul 5, 2016

codyps commented Jul 5, 2016

brson commented Jul 12, 2016

ehuss commented Oct 8, 2021

rfcbot commented Oct 8, 2021 • edited by Xanewok Loading

joshtriplett commented Nov 2, 2021

rfcbot commented Feb 15, 2022

rfcbot commented Feb 25, 2022

japm48 commented Jun 5, 2022

soc commented Jun 16, 2022

tbu- commented Jun 21, 2022

soc commented Jul 22, 2022 • edited Loading

eode commented Jul 22, 2022

aidanharris commented Jul 22, 2022 via email

soc commented Jul 22, 2022

aidanharris commented Jul 22, 2022 via email

RokeJulianLockhart commented Jul 25, 2022 • edited Loading

PoignardAzur commented May 23, 2023

tbu- commented May 16, 2016 •

edited

Loading

liigo commented May 20, 2016 •

edited

Loading

codyps commented May 24, 2016 •

edited

Loading

liigo commented Jun 21, 2016 •

edited

Loading

tbu- commented Jun 21, 2016 •

edited

Loading

rfcbot commented Oct 8, 2021 •

edited by Xanewok

Loading

soc commented Jul 22, 2022 •

edited

Loading

RokeJulianLockhart commented Jul 25, 2022 •

edited

Loading