Inconsistent dependency versions from weird cargo behaviours

[ijackson]

Hi.

I found this strange issue while working on derive-deftly, which uses multiple crates in the workspace, with various cargo features; and also has quite relaxed dependency specifications.

In https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/jobs/507457 it appears that cargo concluded it didn't need to download toml 0.5.11 for the proposed test run:

     Running `/builds/Diziet/rust-derive-deftly/target/debug/deps/trybuild-27b1d08daa9c16ae`
running 1 test
error: failed to download `toml v0.5.11`
Caused by:
  attempting to make an HTTP request, but --offline was specified
test run_pass_expand ... FAILED
failures:
---- run_pass_expand stdout ----
thread 'run_pass_expand' panicked at /usr/local/cargo/registry/src/index.crates.io-6f17d22bba15001f/trybuild-1.0.90/src/run.rs:61:13:

Looking at the dependencies there, cargo is (as far as it could tell) correct: the requested test run does not enable the features that pull in macrotest and it's macrotest that wants toml 0.5.11. The lockfile says to use toml 0.8.2 for derive-deftly-tests, which is the crate containing the trybuild calls.

But when cargo tries to build trybuild's test crate derive-deftly-tests-tests, cargo chooses to use toml 0.5.11 to satisfy the dependency. (I have observed this locally by looking in target/tests/trybuild/derive-deftly-tests/Cargo.lock.) This may be because macrotest demands 0.5 and nothing else in that crate tree demands 0.8, so cargo thinks it can save on duplication this way. (I think because the synthetic crate isn't part of the workspace, the other crates in the workspace that would bring in 0.8 aren't there.)

As a result, that build needs toml 0.5.11 which hasn't been downloaded. I'm working around this for now with an additional call to cargo fetch. That fetches toml 0.5.11 so the test passes.

But that's not really right: what we want is for the syntehtic test crate to use the same versions as the crate containing the trybuild calls. I haven't tested it, but:

I think a big part of the reason this is happening is that cargo is forced to make up a whole new lockfile entry for the synthetic crate. So I suggest the following strategy: after copying the workspace Cargo.lock, add an additional [[package]] entry for the synthetic crate, which is simply a copy of the invoking crate's entry (with changed name and version). Maybe if we did that cargo would leave it alone.

I think we would still need cargo fetch.

Another option might be to try to avoid this situation where the synthetic crate isn't part of the workspace. If the other workspace members were present to influence dependency selection, we could hope that cargo would do the same for the synthetic crate as for the invoking crate, and then everything would be fine. I think?

[ijackson]

(Workaround MR in derive-deftly is https://gitlab.torproject.org/Diziet/rust-derive-deftly/-/merge_requests/269)