Despite crates.io saying 0.2.1 of futures is the version to use (and the futures GitHub repo saying use 0.2.2), futures 0.2.1 has been removed from crates.io. I find this wrong on two fronts:
Dependencies should never be removed from crates.io. Ever. The Java community have been through all of this pain before and Maven Central, and JCentre, have a policy that dependencies can never be removed, and for good reason.
If you are going to remove a dependencies from crates.io for goodness sake get the crates.io system reporting the right versions and fix the project README file.
Doesnât âyankedâ only prevent upload of new/updated crates with a dependency on the yanked version? It still allows previously dependent crates to still work, no? Iâm not sure the situation is as you are characterizing it?
It works as long as they have a Cargo.lock with that version. If Cargo.toml only specifies it and there is no lock file then cargo will fail to find the dependency.
No, not really. Nothing can ever be âdeletedâ from crates.io. Yanked means, âThe authors of this crate have determined this version should not be used, but, if you have a cargo.lock file referencing this particular version in your project, it will be used; otherwise, we wonât let you use it (to protect you from whatever badness has been found with this version)â
This may work fine for some projects, but it breaks as soon as a project needs to track updates to some dependencies, but not others. âcargo updateâ updates all dependencies and this means you then loose access to yanked but still downloaded dependencies.
In the end though âyankingâ is still the wrong approach to problematic artefacts. And in this case there isnât actually a problem, futures has been yanked for no actual good reason: âno longer represents the latest and greatest we have to offerâ just isnât a good reason to remove an artefact from use.
The alternative would be to leave problematic crates on crates.io publicly available, which would risk damaging the reputation of Rustâs ecosystem in the short term and would definitely damage it in the long term. Just look at the mess that is the Node.JS ecosystem for some inspiration of how that could play out.
Having a dependency yanked is inconvenient, but itâs still the least-wrong thing to do in most cases as it prevents usage of code known to be seriously flawed. So Iâm left wondering: why are you so convinced that it is the wrong thing to do?
As an aside, I do agree that a cargo update should not purge the Cargo.lock data pointing to a yanked release if there is no alternative to upgrade to (automatic downgrades are not an option as far as Iâm concerned). That just breaks projects.
âwhy are you so convinced that it is the wrong thing to do?â
Well as you say: âThat just breaks projects.â
The current yanking system is entirely publisher-oriented and not user-oriented, the authoritarian stance is not allowing people to have builds that work in a large number of workflows. Clearly Maven Central, with no flags of any sort for broken artefacts is wrong the other way. Thus cargo.io needs a flag system to mark an artefact âbadâ. âcargo updateâ and âcargo buildâ should then highlight this as a warning,perhaps with a message saying why the warning is in place.
As far as I can tell futures 0.2.1 is not broken for many, many users. The published rationale for futures â futures-preview and yanking futures is that the publisher doesnât want futures 0.2.1 being used. This is not broken.
So to be constructive: the current yanking system is over-dictatorial, but is a nice base for something that would be good for both publisher and user. Marking an artefact âbadâ and giving a reason why and a way forward is entirely fine. Having cargo put this solidly into peopleâs faces as warnings would be great. Having crates.io search reflect the âbadnessâ properly rather than seemingly just ignoring the yanking would help. Crate publishers updating their project README files would help a lot.
I think this is a very reasonable stance to take. Yanking is fine as a mechanism for killing broken releases (those with major reliability or security issues), but it should not be used for trivial matters such as âthis is not our latest and greatest anymoreâ or âwe do not want people complaining when the API of a 0.x crate breaksâ .
Now, the question is, can this policy be implemented by a concrete mechanism ? Judging the validity of a yanking rationale is not something which I expect a computer program to be very good at.
I as well do not understand the rationale behind yanking futures v2.0, same goes for futures-preview crate split. If you want to promote development advancments, then why not use futures v0.3-preview-1 or something? And those who are interested in the latest futures version with potential breaking changes always can use git for specifying dependency. While currently I am not using futures, this situation still leaves a bad aftertaste.
I view the yank as informative; you need to take action. Unmaintained software is insecure software. Just because you donât want bad news does not mean you should be oblivious to it.
The only problem I see is there is brevity of just being yanked. This forum isnât the best way to inform why a yank was made without replacement. Typical search path would be looking on crates.io and going to Homepage or Repository. In the case of github if not in the readme there typically is changelog/commit history/issues.
I donât see an issue with the yanking process. Most crates who yank a version often release a newer âsafeâ version so this is an edge case when there is no version to bank on.
Yank reason is still not implemented. I think itâd be less confusing if cargo was able to notice the yank and display the reason, which would explain to user how to fix the issue.
Yanking of the crate was a bit too harsh IMHO, but OTOH itâs an experimental version of an experimental crate, so itâs hard to blame it for not being stable. This touches another problem where Rust ecosystem likes 0.x versions too much, and some crates with âunstableâ versions are de-facto stable, which sets wrong expectations/mixed signals.
Requirement of Cargo.lock to use a yanked version may be too strict. Careful Cargo.lock surgery is possible with cargo update -p, but itâs tedious. Lock file is less meaningful for libraries, but libraries still want to have stability. How about also allowing use of a yanked version if Cargo.toml requires it explicitly and thereâs no newer version?