Open kvark opened 3 years ago
Hm, this is a bit tricky. The underlying issue is that selectors
is not a workspace member. I think (at least for myself), I've not really considered the possibility of having local packages that aren't workspace members. Non-workspace members are usually registry dependencies, and cargo test -p foo
of a registry dependency isn't a usual operation.
I think addressing this would start around here. The issue is that the "not a workspace member" fallback only triggers if you don't also include a workspace member. Somehow this needs to ensure that at least every spec is covered. Unfortunately including a non-member means you won't be able to specify any features.
As a workaround, I might suggest adding all local packages as workspace members.
Thank you for investigation! We have figured out the way to proceed, so this isn't blocking. But having no indication of what's going on was really annoying and time consuming. So fixing the error message in cargo to be clear would be ideal.
Problem
In a modified Gecko project, doing
cargo test -p foo -p bar
fails to resolve one of the packages: At the same time, doingcargo test -p foo
andcargo test -p bar
independently sees either package just fine.Steps
git clone https://github.com/mozilla/gecko-dev
resolver = "2"
to the rootCargo.toml
cargo test -p qcms -p selectors
Possible Solution(s) I don't know why it fails to locate packages
Notes
Output of
cargo version
:cargo 1.53.0 (4369396ce 2021-04-27)
What I find especially sad here is the lack of any output. Even with "-vv" option and
RUST_LOG=trace
,cargo
prints nothing before declaring that a package isn't found. It's just annoying/hard to debug this as a user.