@mbrubeck & @dylan.dpc
Thank you both for the clarification. I was not aware of this, because my build just stopped working even though I had a Cargo.lock file already pointing to the old package. This led me to assume the package itself was also removed. I’m guessing something else happened in between which caused Cargo to clean the lock file and try to rebuild its dependency list (this happened to coincide with an outage in github and some of my deps were github dependencies…).
I think a warning about using yanked package is a great idea, but I think a command line switch, etc. to cargo to allow yanked packages to be considered in the dependency inspection would be helpful. I do still think default behavior should stay the same (exclude from dep search) for security and safety reasons, but it would be nice if we could force that package to be found so we could at least rebuild if we happened to clean out repo (for example, if we didn’t expect that the package was yanked), or someone else pulls our (private) code to collaborate, etc., just long enough to finish what we are doing and then find a path to upgrade the yanked package.
A hard stop in builds (due to Cargo not finding dependencies and being unable to reconstruct a Cargo.lock file on the fly) makes it difficult to even get to a stable point in my own code to even think about upgrading a random package I had no idea was going to suddenly be yanked, forcing an upgrade of code.
What are some downsides of adding a switch like this? Is it complicated to allow yanked packages to be included in the dep search? Or, are there worries that it can be abused/misused by people who don’t understand the full implications? Other concerns?
P.S. I also like the idea @mbrubeck suggested regarding this specific case of the
futures crate. I think that would have been a big help to communicate what was going on.