EmbarkStudios
Bug: panic `unable to locate testing for crate`
Describe the bug
Cargo panics on a remote git dependency when I run it. The dependency is a git sha in a branch on a public repo (a fork of the original project):
thread '<unnamed>' panicked at /Users/sam/.cargo/registry/src/index.crates.io-6f17d22bba15001f/krates-0.16.10/src/builder.rs:719:25:
internal error: entered unreachable code: unable to locate testing for crate git+https://github.com/get-convex/qdrant?rev=465cdcb7b1604d057e057edc23e36e951b75c189#[email protected] features([])
stack backtrace:
0: _rust_begin_unwind
1: core::panicking::panic_fmt
2: krates::builder::Builder::build_with_metadata
3: cargo_deny::common::KrateContext::gather_krates
4: std::panicking::try
5: <rayon_core::job::HeapJob<BODY> as rayon_core::job::Job>::execute
6: rayon_core::registry::WorkerThread::wait_until_cold
7: rayon_core::registry::ThreadBuilder::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
To reproduce
cargo deny check licenses
I'm sure there's some part of our cargo.toml or deny config that's useful here, happy to try to extract it if so.
cargo-deny version
cargo-deny 0.14.21
What OS were you running cargo-deny on?
MacOS
Additional context
Here's the relevant portion of the Cargo.toml. I'm updating rust (nightly-2024-02-24) and I've updated these dependencies and added a new one on common when doing so. The segment dependency is not new and was working with cargo deny on our previous version of rust
qdrant_segment = { git = "https://github.com/get-convex/qdrant", rev = "465cdcb7b1604d057e057edc23e36e951b75c189", package = "segment" }
qdrant_common = { git = "https://github.com/get-convex/qdrant", rev = "465cdcb7b1604d057e057edc23e36e951b75c189", package = "common" }
Ok I'm pretty sure this is due to overlapping module names.
The new module in qdrant is named common. We also have a module named common in our crates list. If I rename one module or the other, then the cargo deny error goes away and everything works.
Can you provide a link to a full cargo.toml/workspace that repros this behavior, I'm missing too much context though I know what needs to be fixed.
