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.