`Dev-dependencies` are not linked when testing subpackages

[lifthrasiir]

$ cat Cargo.toml
[package]
name = "p"
version = "0.0.1"
authors = []

[dependencies.q]
path = "src/q"

$ cat src/lib.rs
extern crate q;

$ cat src/q/Cargo.toml
[package]
name = "q"
version = "0.0.1"
authors = []

[dev-dependencies.r]
path = "../r"

$ cat src/q/src/lib.rs
#[cfg(test)] extern crate r;
#[cfg(test)] #[test] fn foo() { assert_eq!(r::f(), 42); }

$ cat src/r/Cargo.toml
[package]
name = "r"
version = "0.0.1"
authors = []

[lib]
name = "r"
plugin = true

$ cat src/r/src/lib.rs
pub fn f() -> uint { 42 }

$ cargo test -p q
   Compiling q v0.0.1 (file:///path/to/p)
/path/to/p/src/q/src/lib.rs:1:14: 1:29 error: can't find crate for `r`
/path/to/p/src/q/src/lib.rs:1 #[cfg(test)] extern crate r;
[snip]

$ cd src/q && cargo test
     Running target/q-[hash]

running 1 test
test foo ... ok
[snip]

[alexcrichton]

This is something that we'll actually need to deny with a first-class error I believe. The lockfile doesn't list any dev-dependencies of upstream packages, so we won't actually know which copies to build if they're requested.

[luser]

When you say "deny" do you mean cargo test -p q should error in this situation?

Would this be fixable if we added an explicit test-dependencies section to the manifest?

[alexcrichton]

Heh well now being almost a year later, my opinions have changed on this issue a bit! Back then I did indeed intend that cargo test -p q would return an error, but I now today would like this to "Just Work" for most cases (but perhaps not all).

Unfortunately adding test-dependencies wouldn't solve the problem (that's what dev-dependencies are), it basically means that dev-deps need to be included as part of the normal resolution graph no matter what.

[SimonSapin]

FWIW my use case (#2620) is testing multiple crates in the same git repository. They are all reachable from the root Cargo.toml file through path dependencies. In that sense they’re not "upstream" creates, just parts of a large program split up into multiple compilations units to keep build times manageable.

[luser]

Given the existence of Cargo workspaces, could we make this work for that case? That is, if you have a workspace that has a crate member "foo", which has a [dev-dependencies] section, could cargo test -p foo from the root be made to work?

[alexcrichton]

@luser correct!

This was yet another motivation for workspaces, and I believe all the infrastructure is there for this to "just work".

[mbrubeck]

Now that workspaces are here, Cargo.lock contains the necessary information but cargo test -p foo doesn't yet use it. I submitted #3125 to fix this.

[kvark]

@mbrubeck
I don't understand why this issue is closed. Cargo workspaces are good, but this issue is not about them, and there are cases (gfx-rs/gfx#1258) where workspaces are not available, and we'd still like to be able to use cargo test -p something. As far as I'm concern, this is still not fixed.

[mbrubeck]

My patch to fix this for the non-workspace case was rejected in #2621, with the conclusion that this is officially not supported for crates outside of a workspace, mainly because it can't be done while preserving lockfile compatibility with older Cargo versions.