Allow optional dev-dependencies

[bluss]

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

[alexcrichton]

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

[alexcrichton]

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?

[bluss]

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

[bluss]

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.

[alexcrichton]

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.

[sfackler]

I'd like this in the context of platform dependent features that have dev-dependencies.

[huonw]

I wonder if this would be better served by having dev-features, which aren't exposed downstream. The error case is then just a normal feature trying to activate a dev-feature.

(This raises the question: do we want build-features too?)

[alexcrichton]

@huonw, that's a good idea! I like the sound of dev-features to solve this along with static checking that the set of dev-features and regular features don't overlap (e.g. they don't reach into one another).

I don't think that we'd want build-features because this is specifically related to activation of dependencies, and a normal feature activating a fancy codegen option as part of the normal build seems fine to me. E.g. this is separating "when you build" vs "when you test".

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.

[erickt]

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 unstable feature, which also enabled a couple other things that are needed for libsyntax. Unfortunately, this caused serde-deprecated/aster#63 do to some breakage do to clippy.

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 dev-dependencies, but since there's no way to selectively enable optional crates that only build on nightly for extra special testing, I need to express them as regular dependencies.

[Nemo157]

👍 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):

Cargo supports features to allow expression of:

• [...] and possibly other packages (such as development-time mocking libraries, debugging tools, etc.)

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

[mitchmindtree]

I've run into a similar use case to erickt:

I've added an optional serde_serialization feature to some of the RustAudio crates. In order to be able to test their serialization without writing an entire serializer/deserializer pair in each crate, I'd like to be able to use the serde_json crate as a dev-dependency only when the serde_serialization feature is active.

[shepmaster]

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.

[alexcrichton]

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.

[TheNeikos]

What would need to be done for this? I'd be willing to try my hand at it.

[stale]

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:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

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!

[SimonSapin]

I believe this is still relevant.

[c410-f3r]

Any news?

[sffc]

My use case is a dev-dependency that has a dependency back to my crate:

1. main_crate:
   • Has feature "experimental"
   • Has dev-dependency to helper_crate
2. helper_crate:
   • Has feature "experimental"
   • Has dependency to main_crate
   • The "experimental" feature enables main_crate/experimental

I want to be able to run tests in main_crate with the experimental feature turned off and when turned on, which means that I need to be able to optionally enable a feature of a dev-dependency.

[epage]

One idea brought up in this thread is dev-features.

Some related proposals are

• stable/unstable/nightly-only features #10881. Most likely dev-features would want to be private. The downside is public features can depend on private features. Maybe thats still good enough?
• stable/unstable/nightly-only features #10881 . Dev dependencies are an implementation detail. Maybe it'd be good for them to be marked as unstable also to avoid dependents from relying on them (yes, I've broken people by removing a clippy feature from a project)

See also rust-lang/rfcs#3416

[kajacx]

Should Cargo silently ignore all activated dev-dependencies?

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.