That is the specific line of reasoning that I am explicitly rebuking in my arguments here. The first responsibility is to be a good neighbor and a good citizen of the software ecosystem. The second responsibility is to make a good product that does what your users want.
Whether it's as simple as the XDG basedirs spec or as complex as being a vector for DDoS amplification attacks, bugs that affect people other than your core audience ought to be an urgent priority.
Oh I understand that it's not simple. Nothing ever is! I mainly just wanted to voice that it's not just "people outside of Rust" that run into these papercuts. Thank you for your work on things ^^
You know, if Cargo can't muster anyone to give a shit about littering garbage in everyone's home directory
This framing would be correct if rust were a non-compiled language like js/ts/python where you need to have a runtime & probably a full-blown package manager to run the software. But for compiled languages like go/rust, it is up to the creator of any CLI/tool to ensure that the application files are going to the right directory & not in rust. If you're having to deal with rustup/cargo, then you're not an average user. You should be using binaries & if you (or your OS) insists on compiling, then it shouldn't be a big ask to set 1 or 2 environment variables to deal with this. I'm not saying this is an ideal solution. I've personally added XDG support to various Rust tools myself & I'm also frustrated that cargo doesn't respect XDG or other conventional locations. But as a Rust user, this would be far from my top priority.
I'm not a golang user, I use a lot of golang software & I've never had any of them use the default ~/.go location. But I recently had to run a golang script & had to install golang to be able to use it & I was also annoyed about it defaulting to ~/.go. What did I do? I subscribed to the golang XDG issue & setup GOPATH & that was that. It is mind-boggling that tools in 2025 still don't use XDG (even not on Linux, let alone on macOS), but it is not a big deal.
A better analogy than "littering garbage in everyone's home directory" is you going to IKEA & then bringing home an assemble yourself table (compiling rust tool from source) & then complaining that the assembly process left a lot of garbage in your home. You could've gone to a furniture store & got an assembled table (pre-built binaries), but you chose the assemble yourself approach.
P.S. There will be some rust tools out there that don't come with binaries. It would be more productive for one to add binary outputs to CI/CD or finding another tool that does that task.
A better analogy than "littering garbage in everyone's home directory" is you going to IKEA & then bringing home an assemble yourself table (compiling rust tool from source) & then complaining that the assembly process left a lot of garbage in your home. You could've gone to a furniture store & got an assembled table (pre-built binaries), but you chose the assemble yourself approach.
A better analogy is if the instruction manual told you to take all of the cardboard trash and dump it on the street instead of into the recycling bin on the corner.
This is contrary to one of the most basic principles of free software, namely that end-users should be empowered to modify the software they use to their own ends. Everything that Rust can do to facilitate that, it should; and no one should be going around telling anyone not to build things from source, no matter what their reasons are (on either side).
I don't particularly care about cargo insisting on using $HOME/.cargo, because I learned Unix in the days when it was expected that each piece of software would drop its configuration and state in dot-files or a single dot-directory in $HOME, named after itself. I actually miss that, because it was globally consistent, unlike what we have now. I appreciate that there are advantages to the XDG directory structure, such as consolidating all (well, most of) the stuff that doesn't need to be backed up into $HOME/.cache, but I'm honestly not sure it was worth either the churn or the loss of overall consistency.
However.
I completely agree with @ddevault that Rust-the-project has grown to the point where project management needs to be explicitly paying attention to the needs of people outside of Rust-the-language's direct constituency. And I also agree with him that in some cases the needs of people outside the direct constituency will be more important than the needs of people within. This is a thing that naturally happens to all organizations as they get big, and it shouldn't be a controversial thing for @ddevault to be saying. Pick up any project management textbook you like and you'll find an equivalent statement somewhere in there.
(Because it's not important to me and I haven't done any research on who's affected by it and how, I am specifically expressing no opinion here about whether the $HOME/.cargo to XDG migration is one of these cases.)
I want to note that this solution would be a breaking change, and the fact it should hypothetically hit only few users does not change that.
Perfectionism is wanted by those that have to design and implement this migration, because it will likely be painful and break some tools, so they want to make it so that they hopefully won't have to repeat the process in some years due to issues that were not addressed.
Meanwhile on the other sided many people complaining about .cargo will likely not care about this, because their interest in Rust will most likely end when they no longer see a .cargo directory in their home directory.
Also, what is wrong with the CARGO_HOME and RUSTUP_HOME environment variables? You seem to know about them since you mention them, and while I realize they are not ideal you also don't seem to seek a perfect solution, so they should work fine, no?
If you are not using it, how is it affecting you at all? I don't understand.
Yes, the message at the top of this thread really ought to have gone to more effort to make that clear.
The nearest thing I can see to an answer in the github issue is the following:
I spend an (as I see it) unreasonable amount of time to coerce cargo in every scenario where I indirectly used it (such as through distrobox, dev containers, nix, asdf, ...) to write its stuff into XDG directories. And yet, I found another ~/.cargo instance from two months ago.
So I think it's mostly about people who want to compile things they're going to run from source (and I agree with Zack that we should consider that a normal thing to want to do).
But I've also seen plenty of Rust software that tells people that the most convenient way to use it is to run cargo install, so I suppose the issue also affects people who don't explicitly care about using the source code.
Not just rustup and cargo, cargo-deny and cargo-audit have also used CARGO_HOME as their config+cache-dir for some reason. There’s almost certainly other thirdparty subcommands too.
I believe that will be on them to migrate as needed.
The most impactful unfortunate side effect is from cargo-dist which made the choice to install binaries to CARGO_HOME/bin which applications picked up that policy without questioning it, like the entire Astral suite of Python tools, see Uninstalling `rustup` deletes `cargo-dist` installed packages · Issue #1353 · axodotdev/cargo-dist · GitHub
You committed three fallacies in a single sentence here.
This is the argument from fallacy, which itself is a form of fallacy.
Are you seriously claiming that the only alternative to the current status quo is "thoughtlessly shipping a breaking change"? ... You implied that the only way to fix this issue in a timely manner would also be irresponsible.
People's definition of "timely" is subjective. I think promising to fix something in a "timely" fashion would be an empty promise. "Timely" to one person could be within 5 years from now, and to another it could be within 5 days. So if your definition of "timely" is the latter... or anything else that is approximately "right fucking now"? Then yes, it is.
I feel it would be incorrect to falsely presume a consensus on how soon this issue should be fixed on the part of complainants. Both "we waited 10 years, we can wait another 10, I suppose" and "we waited 10 years, so FIX IT NOW ALREADY!" seem like natural sentiments to me. People are certainly acting and speaking in a way from which I would infer something closer to the latter to be more common.
You're forgetting the fact that this issue also affects Windows users. Cargo/Rustup also use improper directories there as well.
I have to completely disagree, if rust project doesn't put rust users like me as the top priority and release good products for me to use, why should I keep using it? Why should I keep supporting it?
You are asking rust project to destroy its own user base and itself for the sake of that, that's way too much.
What's preventing the xdg fs layout from being implemented as an opt-in hidden behind a configuration option or environment variable?
I wonder, have those of you screaming at Cargo to fix this problem NOW tried putting yourself in the developers' shoes?
The Cargo team is eight people. Many of them are also on other Rust teams or work on other projects related to Rust. Resources are spread thin; Microsoft donating $1M to Rust Foundation sounds like a big number until you realize that's nothing if you spread it over two years. In Rust as a whole, there's always fires to put out quick (and don't you dare tell me your code doesn't have bugs) and there's always features important projects like RfL or Wasm need. Many of these issues require agonizingly slow communication with LLVM teams to resolve, and I can assure you that if ~/.cargo existing for 10 years is depressing to you, tons of I-unsound issues existing because of LLVM or because trying to solve them without a PhD is futile is just as depressing to the developer team.
Have you worked in such conditions? Do you realize how embarrassing it is that editions are run by volunteers? Rust is infamous for moving stuff out of std to foreign crates; have you considered that core crates have to be maintained by external developers because there simply isn't enough manpower to bring the working conditions back to normal? (dtolnay, for example, maintains 165 crates and is on T-libs)
Everyone working on anything even remotely related to Rust gets a huge "thanks" from me. I'm constantly amazed by how well things work despite these troubles. I can't imagine this (and then threads like this one) not taking a huge mental toll on anyone, and the sheer endurance of these people is very motivating. I wish more people said they appreciated the developers' work--it's so easy to ignore, after all--and I hope things change for the better in the future.
If you're asking for leadership to step up and make sure this problem is solved ASAP, please reconsider. That's not going to happen, because this is not Microsoft or Apple, that's not how things work here. In the grand scheme of things, Rust is a lot closer to the Dependency xkcd than a typical commercial top-down structure. And we aren't talking about bugs that make people lose money, this is all about a damn directory; for the love of God, please touch some grass.
If you actually want this to move forward, make it easier for people who matter to make progress. Contribute to Cargo, or rustc, or whatever. You don't even have to make changes relevant to XDG in particular--reducing devs' workload by helping out in other ways helps a lot. You can fix simple bugs or triage issues. You can donate either directly or to the Rust Foundation. Idk, pay for their therapist. At the very least, stop with this entitlement. We know things are fucked; that's not our fault.
That's already supported. You can define RUSTUP_HOME and CARGO_HOME to whatever directories you want rustup and cargo to use.
that's not the same as xdg directory layout, which requires cache, state and configuration to be separate
I could've probably stated it better, but I feel like you're deliberately missing the point. Here is what I said:
I'm a full-time software developer, yet I consider myself an average user of a lot of software like linux, git, neovim, rust-lang. I use these softwares daily (as binaries) & use them to compile & contribute to various FOSS projects. In fact, I specifically go out of my way to prefer using rust software because I know that I am free to modify them if I have any problems. I'm not saying that you shouldn't be compiling or modifying software for yourself. I'm saying that if you've decided to compile or modify any rust tool for any reason, then it isn't a big deal to set 2 environment variables while the cargo team is trying to address this issue in a way that satisfies everyone & also has to balance a lot of other priorities (like upcoming edition release).
Perhaps another way to put is that (afaik) cargo hasn't been actively designed and promoted as a package manager for end users. E.g. cargo has no notion of "install the security updates for all the binaries that I cargo installed", doesn't handle manpages or any of the other system integration stuff you'd expect from a package manager.
That it can kinda, sorta fulfill that role is great for the people who are ok with its limitations. If someone promotes it as a way to just manage software with zero caveats then they're overselling cargo or there's an intended/actual audience mismatch somewhere.
This issue has been very important to me and something I've received notification issues from GitHub about for about seven years now, across multiple tracking issues. It's important to me for most of the various reasons listed above as a Rust developer and as a Linux user, but this applies to all operating systems. (Windows has the same platform specific directories split up across different AppData/etc. folders, with almost the same logical split as Linux.)
It feels like the same dismissal I've seen in those years of notifications is on display in this thread, as people patiently explain why they've wanted Rust to respect their operating system's spec and get told that this isn't affecting them at all and there's no consensus Rust should change anything. (Despite the silliness of putting .cargo in Windows, an OS with no concept of dotfiles, and I'm not even a Windows user.)
I would really love for the Rust project to finally change their approach to this issue. Even if the current pre-RFC were finalized as a real RFC tomorrow, I would barely consider it a step forward, as it is about starting to consider an opt-in change which only satisfies half of what's being requested (i.e., it does not split up config, cache, and state files). For some reason there is heavy institutional resistance to the idea of changing anything about .cargo, and I really do not think such a change is as high-friction as people are claiming it would be (since other programming languages have made such changes quite literally orders of magnitude more quickly than Rust.) But maybe it genuinely is, and in that case I would rather have the issues closed and be told directly that nothing will change on this; since that seems to be the most realistic outcome.