Where in this thread are you seeing dismissal of the issue itself? There's a difference between "this is not an issue" and "we don't have the capacity to handle this among our other priorities". The outcome may be the same, but there's a crucial difference: If someone were to offer the resources to implement it it would be done sooner, if an issue were rejected then even offering resources wouldn't help.
8 Likes
I feel like this could be interesting. Which languages and chances are you referring to? How was the migration handled? How similar was the problem (e.g. were there other tools that relied on the directory structure, how were they handled, etc etc)?
Just complaining won't bring much change, but actual data about similar changes will likely help make decisions and hence speed up the process.
6 Likes
It does split config and cache. (What state should be used for in the case of cargo/rustup is unclear.) Given the pre-RFC, opting in would essentially be just setting CARGO_CONFIG_HOME and CARGO_CACHE_HOME to the XDG directories.
But that's not at all what the XDG specification is asking for. It isn't "the application can be configured to use directory X", but rather "the application looks at the environment variable $XDG_DATA_HOME (and a number of others) for the directories to use". (As well as some clauses on precedence and such, but the specification is still surprisingly short; about 20% the length of this thread up until here.)
I'm really no expert on this, but it seems like just implementing the desired behaviour behind an opt-in toggle is both a necessary step towards the goal, and shouldn't be blocked on the concerns of ecosystem migration.
Yes, it doesn't make us fully compliant with XDG, but not using it by default isn't compliant anyways. My point is that there's little practical difference between setting one CARGO_USE_XDG env var and setting each of the CARGO_*_HOME env vars to opt in.
IMO, "compliant, if you set some configuration option" is essentially compliant. Doing that configuration just becomes part of the installation process. For example, see Haskell#Stack in XDG Base Directory - ArchWiki. Some of the other entries have notes like "if the legacy path exists, it takes precedence".
On the other hand, a workaround like export CARGO_HOME="$XDG_DATA_HOME"/cargo
does not make cargo any more compliant, since it still doesn't care about XDG_DATA_HOME, you've just configured it to use the base path that was in XDG_DATA_HOME. I would consider a wrapper around cargo to be compliant if it sets those variables based on the XDG vars, but it should be simpler overall to do that within cargo.
So, I'd like to rephrase @poscat0x04's question: Are there any reasons to not implement opt-in XDG-compliant behaviour in cargo? Or, if someone did the work, would the PR (have a chance to) be accepted?
2 Likes
You could say the exact same thing about setting the CARGO_*_HOME vars on installation.
I don't consider there to be a practical difference between the two. Either way it's not the default.
If someone just made a PR adding this functionality, even if it were opt-in and unstable, it would still probably need an RFC to be accepted first.
Is there something I could set CARGO_HOME to so that XDG_DATA_HOME=/foo cargo and XDG_DATA_HOME=/bar cargo would look in /foo and /bar respectively? I'm just trying to demonstrate how "cargo can be configured to use any directory you want" is not the same as "cargo can be configured to use the directory set in XDG_DATA_HOME", which you seem to be missing.
This is still a breaking change. There are users with these variables defined today where cargo does not use them.
3 Likes
You haven't answered the question though. You mentioned there were programming languages that made similar changes to those that Cargo requires much faster, but you didn't provide examples, neither in the original post nor in the one in response to my question.
This makes me doubt both the truth of your statement (not trying to imply it is false, but if you researched it I would expect you to be much more willing to show the examples) and your will to contribute to the issue (since that's something that can help determining how impactful certain breaking changes can be; it doesn't even require specific cargo/rust knowledge, which was previously cited as an obstacle to contributing).
At least 84 versions of rustc, cargo and rustup do. Several third party tools probably do as well, though they are all expected to follow CARGO_HOME.
This assumes you only care about compatibility with the newer versions of those tools and disregards the one with the 84 existing versions of rustc and cargo, which newer rustup versions must still be able to work with. This is important because there are many people actively using older rustc/cargo versions to test and ensure their crates still compile fine there.
It also doesn't help that it's not just a matter of changing a default (e.g. CARGO_HOME), but also that you need to split it into cache and config. This means rustup can't just automatically set CARGO_HOME when invoking older versions of cargo or third-party tools.
These issues are probably possible to solve, but it's not the simple case of just changing a couple of hardcoded paths as you're trying to imply should be done.
5 Likes
Know, I have already named two of them that I have had to add hacks to workaround in my script to force cargo to follow XDG. And epage followed up with some that actually break because of their usage of CARGO_HOME.
2 Likes
Sorry my bad, I was thinking you were the original poster to which I posed the question.
And the answer would be yes, because if done naively older releases would break.
You can easily see a bunch of them if you look at the dependents of the home crate. Some are probably duplicated though.
I'm not claiming that, but it's similar.
Ssh can't change because there are so many tools that hardcode .ssh that, and even if all of them were contacted the chances that some of them can't or won't be updated is high, so you have to keep backward compatibility.
Rust is already promising the ability to use rustup with all the existing 84 versions, so it also wants to keep backward compatibility. It has the advantage of knowing what those existing versions look for, so there is a chance of mitigating the issue, but it's far from trivial.
Maybe this isn't completly clear to someone new to Rust, but rustup lets you install old and new rustc/cargo versions at the same time, and they all share the same .cargo directory. It is expected that this will be the case for newer rustc/cargo versions, meaning you can have versions of rustc/cargo before and after the implementation of the xdg directory structure and they have to work together.
It's not that impressive of a number since they all handle ~/.cargo pretty much the same way, unless you plan to release patch versions for all of them to make them work with the newer folder structure, then 84 versions to patch become quite a lot (and you still assume someone will update to those patches, which might not be the case).
I have yet to see actual suggestions for how to fix the biggest issues though, like the backward compatibility when multiple versions of cargo are installed.
2 Likes
Your reply doesn't make any sense in response to what you quoted. I fully support making cargo XDG compliant. We all understand why it's important, even if not everyone agrees that it deserves priority treatment or that not being fixed yet is morally wrong.
I was only saying that it won't be compliant until it uses XDG by default, and that setting the CARGO_*_HOME env vars to the respective XDG vars is practically the same as an opt-in configuration (so the vars in the pre-RFC are sufficient for most people, even if they don't make it fully compliant).
1 Like
Rust is not your boss. Rust Foundation does not pay your bills. Your life is in no way dependent on Cargo resolving this bug. You are drawing a non-existing parallel.
2 Likes
This assumes two things:
- third party tools are the only/biggest issue
- there will be a breaking change (most likely this will not happen)
There is already something like that, even for third party crates. It is not general enough to implement XDG compliance, and that's an issue. Adapting it in a way that keeps backward compatibility is the issue, and you have provided zero suggestions for how to do that.
I mentioned some concrete issues to implementing this in a backward compatibility way in the very post you're replying to.
It seems clear to me at this point that you're just wasting time arguing for a breaking change that will most likely not happen. I can see why you don't care, because you would not be impacted, but those that might be impacted and those that will have to handle the conseguences do.
3 Likes
I'm trying to put myself into your position to understand this one.
You state you want Cargo to solve it, but close it as unresolved because it's not fast enough for your tastes?
Cargo isn't going to break its backwards compatibility guarantees to appease an arbitrary time restrictions some user demands. If this feature were truly backwards incompatible, it would be closed already.
That still won't work. I've worked on coordinating cross-team changes in microservices that are backwards compatible, on well-funded, well staffed teams that all agreed on the necessity of changes. Even in near ideal conditions, it can take years. You can't turn ships on a dime.
Maintaining backwards compatibility adds a lot of development inertia. If you don't have backwards compatibility, no one will use your tools.
First, you can't move fast and break things. Second, you have to keep old behavior and data, while allowing new one. Third, there are a billion things that can go wrong and need to be considered, and a billionth and one thing that nobody thought about.
RFC is a way to figure out a way that people can't find any problem with working. It's not perfect and probably won't catch all problems, but it's a way for everyone to try to see if the solution is theoretically sound.
2 Likes
This discussion is starting to go in circles; on one hand it seems we are re-iterating variants of the same main discussion points again and again without gaining much depth[1]; on the other hand I keep stumbling over unnecessarily unkind or dramatic ways of phrasing things.
But first, and more importantly, I would like to say thank you in particular to those people who did express themselves as kind and understanding as possible, while adding important context or questions of clarification to the thread, and resisting the urge to comment on everything at length, in order to keep the forum thread productive. Iām convinced that other readers of this thread appreciate this as well.
Iām also very happy reading the opinions or comments shared[2] by here some new, or rarely active forum members. Thank you for coming here, and it would be great to read even more peopleās experiences, if they find their way here.
I would like to focus the scope of this thread to these remaining point:
- this thread is being linked to from the issue, and it can keep being a good place ā especially also for peripheral or indirect users of Rust tooling ā to share their thoughts and experiences around this issue and its implications
- especially of youāre one of the ānon-Rust-usersā that are affected by getting a
.cargodirectory that you donāt want. Feel free to share specifics of the circumstances in which you are ending up usingcargowithout actually invokingcargomanually[3]
- especially of youāre one of the ānon-Rust-usersā that are affected by getting a
- replies to previous posts should aim to bring something new to the discussion, and avoid all forms of unnecessary unkindness
In order to protect our most valuable community members, the people who often spend great amount of their personal free time in order to make Rust better every day, we canāt keep hosting the style of interaction present in recent parts of this thread. In order to learn more about our rules, check out the Rust Code of Conduct, as well as the Discourse FAQ of this forum.
We can give other people a better chance to catch up with the thread by giving the discussion a break. Make sure to check your replies posted during the (temporary) slow mode before sending them, as it also disables the option to edit posts.
which is okay because this was deliberately set out as a meta-discussion; here wouldnāt be the best place for mixing in too much technical discussion about the topic itself wouldnāt be the best place ā©ļø
respectfully and concise ā©ļø
other forum members canāt simply guess your context, and Iām fairly certain that many forum members here have a much better picture of all the relevant specifics and challenges in the context of manual usage of cargo installed via rustup, but donāt have any list of āall the other software&tools that make indirect use of
cargofor youā readily available ā©ļø
9 Likes
No. Here, let me demonstrate:
You have two teams,where number of people is unknown, where how long they work on project daily is unknown, where they may leave and join at any point, requiring time to get up to speed. They need to make synchronized change that must be tested on millions of setups, and if it fails the teams need to try the sync again. Of course assume other work is happening in the background, whicn might delay the sync. And of course assume there are unknown unknowns you will probably discover during testing. Or not.
How long could this take?
Answer
It's done when it's done.
Apples to Oranges. Yes. They are FOSS, yes they are programming languages. But Zig doesn't have to maintain backwards compatibility.
When Rust was in 0.x the change rate was amazing. Code churn was amazing too. Rust went from GC language to borrow checker in span of a year or two. Code written on Monday wouldn't be compiled by Friday. Granted before stabilization it was a much more predictable language.
It's dead easy to make changes if you don't care about backwards compatibility.
5 Likes
This is true when the customers will stop funding in this case. But when such an issue, no matter how annoying, isn't blocking value-add of the product, āindefinite futureā timelines can and do happen.
If the most effected crowd is the non-Rust developer, and the least is Rust developers, then the customer base which is funding development of Cargo and Rustup (e.g. by volunteer developer time) isn't hurt by this issue in deriving value from the tools.
A slightly better comparison would be treating this not as an issue in one product, but that Cargo and Rustup are both developed by mostly independent entities (and both subcontract out most of the work on top of that). It's not coordination in one team or even cross department, it's closer to cooperation between sister companies with almost entirely different management, just a shared parent company.
That's why progress is so sporadically bursty, why timeline estimation is so difficult, and why it's taking so long to address. Especially as the signal/noise ratio deteriorates, it's very easy for both sides to end up thinking they're waiting on the other for a decent while.
Add on top of that unpredictable developer time and a relatively lower priority with relatively higher overhead to bringing all the relative information back into cache, and it should be fairly easy to see how you get a languishing timeline.
Add in the pressure for Rust tooling to behave consistently cross-platform and not privilege one tier-1 platform over others too much, and suddenly you're waiting on someone intimately familiar with Linux, Mac, and Windows to interpret three different sets of inconsistent conventions to determine an overall transition plan.
That's a bit perfect-as-the-enemy-of-good for sure, but it's sort of the reality of the thing.
As a suggestion which I think matches the implied sentiment, saying that the communication as being perceived makes you feel like people are withholding information or treating you as if you wouldn't understand a more complete picture should generally be fine. It's when this tips the line into accusing others of doing so deliberately[1] where it becomes potentially problematic.
If you feel like communication is breaking down, please message the moderation team; that's what they're there for. (This goes equally for participants on all sides of a discussion.) Ideally, moderation is supposed to prevent āflame war[2]ā scenarios from breaking out, not just deal with the aftermath when it does happen.
I can often be problematically helpful to a fault, and keep engaging a discussion where I and someone else are talking past each other, thinking that surely this time I can find and resolve the misunderstanding and communicate my point more clearly. This fails at least as often as it helps, despite me knowing this already.
So I'm speaking from experience here. And yet at the same time, potentially making the same mistake yet again.
4 Likes
It will be time for Rust to define its project goals for 2025 soon. I hope to see XDG support among them.