Where has futures 0.2.1 gone?

#1

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:

  1. 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.

  2. 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.

Clearly there is Futures 0.2 has been moved to futures-preview but this is not good enough. @slomo is entirely correct that this removal of dependencies is simply wrong.

#2

It hasn’t been removed from crates.io, just yanked.

#3

What is the difference? it is no longer available as a Cargo dependency despite being the version crates.io Web index says is the one to use.

#4

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?

#5

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.

#6

I had futures 0.2.1 in the Cargo cache area but Cargo build was still using 0.1.21.

I have now deleted the entire Cargo cache all as it seems the only way of removing not being used so I cannot perform further experiments.

It seems “yanked” and “deleted” are the same.

In order to progress I have had to switch the dependency to futures-preview, but I am still angry about this whole episode because the GitHub repository README and the crates.io Web index give the data that futures 0.2.2 or 0.2.1 are the correct dependencies. Inconsistencies like this make for anger. Not to mention the dĂ©jĂ  vu from the Java dependency wars from a decade and a half ago. It seems Rust dependency management hasn’t learned the lessons from that episode.

#7

As @slomo stated, you should only need a Cargo.lock with the 0.1.21 version and then it should work.

#8

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)”

#9

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.

#10

Not really in this case, switching to futures-preview 0.2.2 is the way forward.

That there is a way forward does not stop this “yanking” being bad DevOps.

#11

That the crates.io index always links to the latest version, even if yanked, is simply a bug that can be fixed there.

Edit: added futures case here.

#12

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.

#13

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.

#14

‘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.

More carrot, less stick.

#15

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.

#16

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.

#17

FWIW, I agree that yanking here appears to have been misguided.

In my own code, I’m sticking to futures 0.1 and tokio_core until this entire landscape settles down.

#18

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.

#19

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.

#20

  • 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?