Build foo's dev-dependencies when running cargo test -p foo

[mbrubeck]

Fixes #860. Transitive dev dependencies are now always resolved and included in the lock file, but are built only when testing a crate that dev-depends directly on them.

This still needs a regression test for #860, but I wanted feedback on the patch before I write the test.

[rust-highfive]

r? @wycats

(rust_highfive has picked a reviewer for you, use r? to override)

[alexcrichton]

Unfortunately this may not be so simple to fix right now. The fundamental problem currently is that dev-dependencies are not listed in lock files, so every time you run cargo test -p foo it'll try to update the source of the package (e.g. the git repo or the registry) and may select different versions to test with.

[mbrubeck]

@alexcrichton:

The fundamental problem currently is that dev-dependencies are not listed in lock files

That is fixed by this PR.

[mbrubeck]

"Everything" now includes dev-dependencies. This affects lock file generation.

[alexcrichton]

Aha! That unfortunately goes against one of the main ideas behind Cargo, which is that the Cargo.lock does not oscillate but is rather pretty stable (unless you change Cargo.toml)

[mbrubeck]

Aha! That unfortunately goes against one of the main ideas behind Cargo, which is that the Cargo.lock does not oscillate but is rather pretty stable (unless you change Cargo.toml)

As mentioned in the commit message, this doesn't make the lock file oscillate. All dev dependencies are always included in the lock file.

[alexcrichton]

All dev dependencies are always included in the lock file.

Yeah there's two reasons that this is a bit sketchy unfortunately:

1. This is a breaking change from today's lock files (any change at all is a breaking change). This means that if contributors aren't all using the same version of Cargo, everyone's gonna generate a different Cargo.lock. We have mitigations for this in place, but it's somewhat difficult to apply to this issue at hand.
2. Are you sure this actually happens? Your condition is "previous wanted dev_deps and I'm listed in the dev_deps_packages list. That list is always empty, however, unless -p is passed it looks like?

Fundamentally, however, fixing this bug will break lock files, which is something we've avoided doing up to this point. That's partly why I wanted to accelerate workspaces as it'll fix this bug nicely.

[mbrubeck]

This means that if contributors aren't all using the same version of Cargo, everyone's gonna generate a different Cargo.lock.

Ah, yes, this is true.

Are you sure this actually happens? Your condition is "previous wanted dev_deps and I'm listed in the dev_deps_packages list."

Yes. Lock file generation uses Method::Everything, which bypasses those conditions and includes transitive dev-dependencies unconditionally. (I have tested this.)

Fundamentally, however, fixing this bug will break lock files, which is something we've avoided doing up to this point. That's partly why I wanted to accelerate workspaces as it'll fix this bug nicely.

Got it. Feel free to close this PR. Maybe after workspaces are implemented, cargo test -p foo should be restricted to packages in the current workspace (or warn for packages that aren't?) since it isn't guaranteed to work (or to keep working) for anything else.

[alexcrichton]

Ok, in that case I'm gonna close this for now (as it's slated to be fixed with workspaces), but thanks regardless! I do think it's a good idea to reject cargo test -p foo unless the package is in the workspace (or perhaps unless it has 0 dev-dependencies).

[mbrubeck]

#3125 is an updated version of this patch, which takes advantage of workspaces.