Running cargo build checks the dev-dependencies

[seanmonstar]

sean@grunt:~/code/hyper (master) $ rm Cargo.lock
sean@grunt:~/code/hyper (master) $ cargo build --release
    Updating git repository `https://github.com/chris-morgan/mucell`
    Updating git repository `https://github.com/rust-lang/time`
    Updating git repository `https://github.com/reem/rust-unsafe-any`
    Updating git repository `https://github.com/hyperium/mime.rs`
    Updating git repository `https://github.com/sfackler/rust-openssl`
    Updating git repository `https://github.com/alexcrichton/cookie-rs`
    Updating git repository `https://github.com/carllerche/curl-rust`
    Updating git repository `https://github.com/servo/rust-url`
    Updating git repository `https://github.com/chris-morgan/rust-http`
    Updating git repository `https://github.com/alexcrichton/gcc-rs`
    Updating registry `https://github.com/rust-lang/crates.io-index`

And then it errors because curl-rust depends on the crates.io version of openssl. curl-rust and rust-http are both dev-dependencies, so I wouldn't expect them to matter when doing a build.

[alexcrichton]

Cargo downloads all dependencies when generating a lockfile to perform full resolution. Otherwise your Cargo.lock would change whenever you ran cargo test vs cargo build. Cargo also prepares the build for all dependencies, filtering out the dev-dependencies later on. The bug of duplicate openssl dependencies would have been a real problem for cargo test, and showing you earlier is ensuring that the problem can be dealt with.

For now though, this is working as intended, so closing.

[mssun]

@alexcrichton, could you please reconsider this issue? I found an inconsistency of the [dev-dependencies] tag.

Firstly, if I build a crate (e.g., abstract-ns), it will first resolve all dependencies including dev-dependencies and then compile. However, if the abstract-ns crate is include as a dependency in other crate. When you cargo build, cargo will not resolve and install dev-dependencies.

According to http://doc.crates.io/specifying-dependencies.html,

Dev-dependencies are not used when compiling a package for building, but are used for compiling tests, examples, and benchmarks.

Therefore, dev-dependencies should not be considered in cargo build both in debug and release.

This is an issue since I found that some crates like abstract-ns will exclude some (local) dev-dependencies in uploading to crates. When I download crates from crates's registry, it failed to compile with cargo since there are (local) dev-dependencies missing.

[mssun]

For example:

$ ls ~/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/abstract-ns-0.3.4/
Cargo.toml  examples  LICENSE-APACHE  LICENSE-MIT  README.rst  src  vagga.yaml

$ cat ~/.cargo/registry/src/gh.neting.cc-1ecc6299db9ec823/abstract-ns-0.3.4/Cargo.toml
[package]
name = "abstract-ns"
description = """
    Abstract name service traits for use with futures (and tokio)
"""
license = "MIT/Apache-2.0"
readme = "README.rst"
keywords = ["dns", "tokio", "name", "service", "discovery"]
categories = ["asynchronous", "network-programming"]
homepage = "http://github.com/tailhook/abstract-ns"
documentation = "http://tailhook.github.io/abstract-ns"
version = "0.3.4"
authors = ["paul@colomiets.name"]

[dependencies]
futures = "0.1.2"
quick-error = "1.1.0"
rand = "0.3.14"

[dev-dependencies]
futures-cpupool = "0.1.2"
argparse = "0.2.1"
ns-std-threaded = { path = "ns-std-threaded", version = "0.2.0" }         # <<<<<----------
ns-dns-tokio = { path = "ns-dns-tokio", version = "0.3.0" }               # <<<<<----------
domain = "0.2.0"
tokio-core = "0.1.6"

[lib]
name = "abstract_ns"

[workspace]
members = ["ns-std-threaded", "ns-dns-tokio"]

Note that there is no ns-std-threaded directory in the crates registry. Therefore, you cannot build the crate directly.

IMO, [dev-dependencies] should be only resolved when building tests, examples and benches.

This will ensure the consistency of the cargo's behaviors and documentation.

[alexcrichton]

@mssun hm this is a quite old (3 years!) issue that's I think pretty unrelated to the failure you're seeing. It looks like you're trying to run cargo test inside a downloaded crate from crates.io? That's been solved via other mechanisms for now.

[mssun]

@alexcrichton yes, it's quite old.

What I'm trying to do is to run cargo build inside a downloaded crate from crates.io.

I wrote a script to build some downloaded crates for research purpose. However cargo build will fail because of these kind of packages.

[alexcrichton]

That use case I believe is addressed by #4030 for all crates published with a Cargo that has that support, but there's still old crates on crates.io for sure.

[mssun]

Thanks Alex. This is indeed the root cause of my issue. So crates packaged with new cargo should be fine.