Allow optional dev-dependencies #1596
Comments
|
I was quite surprised that there was an explicit error when I tried this out to verify it, now I need to remember why I put that in there... |
|
Hm ok I think I remember now, and I believe my hesitation here was related to feature activation. For example it may be quite surprising to enable a feature which activates both dev and non-dev dependencies when a package is itself used as a dependency (e.g. no dev-deps are built). Should Cargo issue a warning/error in this case? Should Cargo silently ignore all activated dev-dependencies? |
|
Not sure. You're seeing the bigger picture much better than me, (thankfully!). I think I'll move to a mandatory dev dependency for now |
|
It could issue a warning if the feature only activates dev-dependencies. I'm already back from the "experiment" :-) I need it to be optional so that I can keep building tests on Rust 1.0, which doesn't have quickcheck_macros. How quickcheck works with testing functions (requires explicit cast to fn pointer for each tested predicate), the only sane way to use it is with macros. |
|
I think it'd be fine for now to ensure that a feature only activates only dependencies or the dev-dependencies, sending a hard error for now would allow us to possibly be more flexible in the future. |
|
I'd like this in the context of platform dependent features that have dev-dependencies. |
|
I wonder if this would be better served by having (This raises the question: do we want |
|
@huonw, that's a good idea! I like the sound of I don't think that we'd want Now all that being said, I also don't feel too bad about just silently not activating dev-dependencies if a feature includes it and it's not a direct dependency. That would at least cut down on the complexity of the manifest, which may be the best thing to optimize for here. |
|
Ran into another case where this would be handy. I added a dependency on clippy and compiletest to aster. Both only compile on nightly, so to keep things building on stable I had to make them optional. I enabled them with the While the fix was pretty simple (I just used another feature), really these dependencies are only necessary for testing my project, and have no use on any of my downstream users. This really does mean that they ought to be |
|
👍 I want this for a similar reason (including plugin based macros for doc tests on nightly). I also noticed that the manifest format documentation had this in it (emphasis mine):
It does say that dev dependencies can't be optional lower down, but if this isn't going to be implemented any time soon then it may be nice to get rid of that suggestion (or link it to this issue so people know it's a future feature). |
|
I've run into a similar use case to erickt: I've added an optional |
|
Add me to the pile. I have the same case as @bluss - wanting to have quickcheck tests. I also am replacing a crate that uses C code with pure Rust, so I'd like to have a dev-dependency on the replaced crate to run tests that ensure the behavior is the same between the two. Showing that I depend on the C crate would look really weird on crates.io though! I also have a dependency on competitor crates for the purposes of benchmarking. To solve all these in one fell swoop, I think I'm going to create a sub project that just uses my crate. This should work for me, but might not for everyone. |
|
Note that this is basically just blocked on getting the work done. I'd be most in favor of my previous comment, simply requiring that activating a feature can either enable a regular dependency or a dev-dependency, not both. |
|
What would need to be done for this? I'd be willing to try my hand at it. |
|
As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it. I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect? The team would be especially grateful if such a comment included details such as:
Thank you for contributing! (The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.) If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable! |
|
I believe this is still relevant. |
weihanglo
added
E-hard
Yes. Cargo already ignores all dev dependencies when it comes to the resulting built code. If some of them are activated by a feature should have no effect on that. |
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves test build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also actually runs the tests for the ‘handwritten’ bench implementation and fixes a test failure.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves test build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also actually runs the tests for the ‘handwritten’ bench implementation and fixes a test failure.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves test build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also actually runs the tests for the ‘handwritten’ bench implementation and fixes a test failure.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves test build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also actually runs the tests for the ‘handwritten’ bench implementation and fixes a test failure.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves test build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been failing but was not being run.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
Criterion is a slow and giant dependency that pulls in more giant dependencies. There is no particularly compelling reason to use it here over a more lightweight implementation, and removing it also improves cold dev build times by 25% (because all dev-dependencies are built in both bench and test modes and there is no way to control this; see rust-lang/cargo#1596). This also adds the ‘handwritten’ benchmark implementation test to the test runner and fixes one of its tests, which had been silently failing.
and others
Quickcheck test cases take a very long time to build (minutes) compared to the rest of my tests that take seconds.
For this reason, I use quickcheck as an optional regular dependency. It's not used in regular cargo build and cargo test.
Using an optional dev-dependency would be more correct (and info on crates.io would be more correct).
The text was updated successfully, but these errors were encountered: