error: Package does not have these features

[arcnmx]

This seems like a regression introduced recently... Specifying features through dependencies has worked for a long time, but is now broken:

$ cargo init testing &&
  cd testing &&
  echo -e 'byteorder = "*"' >> Cargo.toml &&
  cargo build --features byteorder/std
    Updating registry `https://github.com/rust-lang/crates.io-index`
error: Package `testing v0.1.0 (file:///tmp/testing/testing)` does not have these features: `byteorder/std`
$ cargo --version
cargo 0.13.0-nightly (d263690 2016-07-07)

The test case works as expected with cargo 0.12.0-nightly (50dad37 2016-06-21)

[alexcrichton]

This was likely due to #2821.

In retrospect I'm not sure whether this should actually be allowed or not. On one hand you know when you're building a crate what the dependencies are, so it's not leaking information like before. On the other hand though you're just kinda poking around...

Out of curiosity, what was the use case of this?

[alexcrichton]

cc @bennofs

[arcnmx]

The particular use case that triggered this was CI testing; ensuring that the package builds and tests against a dependency when certain features are enabled, even though that feature isn't explicitly a feature of the main crate.

Considering that dep/feature is valid in a Cargo.toml's [features] feature_name = ["dep/feature"], I think it makes sense that the same syntax be allowed on the CLI. Other crates in an upstream dependency chain may enable certain features on a crate that you depend on, so testing against that in CI can be useful in some cases.

[alexcrichton]

That makes sense to me, and I agree that this is something we should fix. Thanks for the report!

[alexcrichton]

@bennofs would you mind taking a look?

[bennofs]

I agree with this report, specifying additional features for dependencies on the command line should definitely be allowed. I'll look it into this.

[alexcrichton]

Thanks @bennofs!

[bennofs]

@alexcrichton Do we want to support arbitrarily deep feature specifications on the command line? For example, --features "foo/bar/qux"? And what about allowing specifying features of dependencies that are not direct dependencies of the current package, but appear deeper in the dep chain? Say, if the current package does not depend on bar directly, but does so though transitive dependencies, should --features "bar/some-feat" be allowed?

[alexcrichton]

@bennofs no I think we only want to allow foo/bar at most, and only when foo is a directly listed dependency of the current crate in Cargo.toml.

[tomaka]

The particular use case that triggered this was CI testing; ensuring that the package builds and tests against a dependency when certain features are enabled, even though that feature isn't explicitly a feature of the main crate.

Enabling a feature on a library must never break any crate that depends on it. Doing so should be considered as a bug.

Your argument is more or less "I want to add tests in my library that test whether my dependencies are buggy".

This is the most practical solution, but in my opinion it's the wrong way to fix the current situation.