Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

error: Package does not have these features #2851

Closed
arcnmx opened this issue Jul 11, 2016 · 10 comments
Closed

error: Package does not have these features #2851

arcnmx opened this issue Jul 11, 2016 · 10 comments
Labels
C-bug Category: bug

Comments

@arcnmx
Copy link

arcnmx commented Jul 11, 2016

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
Copy link
Member

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
Copy link
Member

cc @bennofs

@arcnmx
Copy link
Author

arcnmx commented Jul 11, 2016

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
Copy link
Member

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

@alexcrichton alexcrichton added the C-bug Category: bug label Jul 12, 2016
@alexcrichton
Copy link
Member

@bennofs would you mind taking a look?

@bennofs
Copy link
Contributor

bennofs commented Jul 12, 2016

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
Copy link
Member

Thanks @bennofs!

@bennofs
Copy link
Contributor

bennofs commented Jul 13, 2016

@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
Copy link
Member

@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.

bors added a commit that referenced this issue Jul 14, 2016
allow enabling features for deps with --features

Fixes #2851
@tomaka
Copy link
Contributor

tomaka commented Sep 21, 2016

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.

foresterre added a commit to foresterre/sic that referenced this issue May 11, 2020
With:
   cargo run --features 'sic_image_engine/imageproc-ops' -- -i resources/1x1_a.png -o target/o.png
It now works though; even on stable! yay!

Seems that that is regarded as a feature:
- rust-lang/cargo#2851 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

4 participants