Add a warning when packaging crates with wildcard dependencies

[sfackler]

r? @alexcrichton

Any ideas on how to make a reliable test for this? Making a test with multiple dependencies on stuff off of crates.io seems to make output pretty nondeterministic wrt download and compilation ordering.

[achanda]

Shouldn't we let the end user know as soon as possible (i.e. on a cargo build)?

[sfackler]

I'd lean towards no. Just like the checks that already exist for missing descriptions, licenses, documentation links, etc, these limitations only really matter when you're about to publish, and they're easy to fix at that point.

[alexcrichton]

This actually explicitly doesn't want to warn on a cargo build because only crates.io will be rejecting * dependencies, not Cargo itself. This means that applications and such are free to use * still, it's just libraries on crates.io that won't be allowed to use it.

There should be existing instances in tests/test_cargo_registry.rs about how to make a fake registry which doesn't do anything on the network, so perhaps one of those could be re-used to add a test?

[sfackler]

Cool. Will take a look tonight.

[sfackler]

Updated with test.

[alexcrichton]

@bors: r+ 28126c1

Thanks!

[bors]

⌛️ Testing commit 28126c1 with merge ec9398e...

[bors]

💔 Test failed - cargo-linux-32

[alexcrichton]

Fascinating! That's the first time I've ever seen that failure outside of rust-lang/rust's bots...

@bors: retry

[bors]

⚡️ Previous build results for cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 are reusable. Rebuilding only cargo-linux-32...

[bors]

☀️ Test successful - cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64