Using the same dependency twice but with different features.

[sebcrozet]

It would be useful to be able to depend on the same package twice, but using different features, that is, being able to write something like:

[dependencies.some_library]
git = "fixme"
features = [ "feature1" ]

[dependencies.some_library]
git = "fixme"
features = [ "feature2" ]

However, this will cause some naming problems as the two libraries will have the same name. To prevent this, we could add a name entry to the depencency to rename it:

[dependencies.some_library]
git = "fixme"
name = "some_library_1"
features = [ "feature1" ]

[dependencies.some_library]
git = "fixme"
name = "some_library_2"
features = [ "feature2" ]

Or perhaps we could let the user specify the features when he does an extern crate:

extern crate "some_library" with feature1 as some_library_1
extern crate "some_library" with feature2 as some_library_2

and the dependency on cargo would not specify any feature as they will be inferred by the extern crate:

[dependencies.some_library]
git = "fixme"

My use-case for this is to allow the user to use the 3df32 feature of ncollide (for 3d collision detection) together with the 2df32 feature (for 2d collision detection) in the same application.

[alexcrichton]

I talked with @wycats today about features and we came up with a possible solution to this, could you read that over and see if it would solve this problem for you?

[jflatow]

I don't think this issue was ever solved -- if you want to re-use the same crate with a different set of features this doesn't seem to be possible. The resolver automatically takes the union of features, and if you try to separate these into distinct dependencies using a different name for each you get 'depends on crate multiple times with different names'. Why shouldn't/couldn't these different names be treated as distinct dependencies?

[PonasKovas]

I don't see any technical reasons not to let users depend on the same crate twice, if that's what they need. A warning when doing that is logical, but an error is too much.

I know that in theory all crate features should be additive and you shouldn't ever need to depend on the same crate twice with different features, but in the real world that's not always the case, and cargo blocking the only solution to it for no reason doesn't seem logical to me.

[PonasKovas]

@alexcrichton Could this issue be re-opened? It seems that it was closed by accident because of the linked PR, which did not in fact solve this issue.

[addisoncrump]

@alexcrichton Bumping this; this would be very useful for differential fuzzing in cases where different features are used (e.g. no-std vs. std environment).

[alexcrichton]

This is an 8 year old issue, please open a new one with more up-to-date information.

[dzmitry-lahoda]

I have similar question. Current solution people use in my case is macro. But having crate imported 2 times with different features would work. Basically sometimes I want TypeScript in Rust. This could solve it for certain use cases.

[gabemeola]

parking_lot is a good example of exclusive features. Here is an error when importing dependencies which both use different parking_lot features.

[the `send_guard` and `deadlock_detection` features cannot be used together](error: the `send_guard` and `deadlock_detection` features cannot be used together)

Related: #5954

[epage]

#2980 is the issue to see for mutually exclusive features