Check in a lockfile to continue building through yanked dependencies

[shepmaster]

We only generate and commit a Cargo.toml file, but as the crate graph gets larger, we are more and more likely to fail for a crate being yanked.

[SamB]

... And that wouldn't imply something was seriously wrong with said crate? (I actually don't know, I'm kind of new to rust.)

[ Wanders off to look at the documentation … ]

The cargo-yank docs don't say anything about what circumstances would warrant yanking: that page isn't even 100% clear on what ends up happening, though I guess the Publishing and Dependency Resolution sections clarify that it just affects the versions cargo will choose to put in your Cargo.lock for you, not whether you can go behind its back and edit Cargo.lock to mention them anyway.

The Publishing section also actually describes intended use cases for yank: "(syntax error, forgot to include a file, etc.)", and those sound like pretty good reasons for the playground not to want that version of a crate, don't they?

[shepmaster]

(syntax error, forgot to include a file, etc.)", and those sound like pretty good reasons for the playground not to want that version of a crate, don't they?

Those wouldn't be cases I'd worry about. Our CI builds the crates we use, so syntax errors would be trivially caught then. The problem occurs after that, when we've been using a version for a while and then the author yanked it (https://github.com/integer32llc/rust-playground/pull/217; https://github.com/integer32llc/rust-playground/pull/568; https://github.com/integer32llc/rust-playground/pull/534). Many times it's been yanked for some memory-security related reason and the author of the crate is being vigilant. That type of issue shouldn't matter that much for the playground.