Adding features to a dependency's dependency

I add a crate A that re-exports another crate B, and to use B in my own application I go through A:

use A::B;

Sometimes I want to enable features to B that aren't enabled by A, but in order to do so I need to include it in my application's Cargo.toml, which means specifying a version -- but I would prefer to implicitly use the version specified in B.

Is there some way to do this?

XY: I'm wondering if it's possible to add features to a dependency's dependendency that is re-exported from the immediate dependency.

I don’t think that’s possible. Unless crate A itself offers some features to enable the features of B you’re interested in.

1 Like

New wish-list item:

something = { version = "1.0.0", features = ["database"] }
rusqlite = { version = "from:something", features = ["time"] }

Well… for that we’d first need a codification / explicit declaration of what are public dependencies vs. private dependencies. Then anything like this version = "from:something" can only be allowed of rusqlite is a public dependency of something (otherwise, private dependency upgrades would become breaking changes due to this version = "from:something" feature).

1 Like

When compiling code - cargo unifies features such that if some crate that implements features foo and bar used several times in your dependency tree with features foo and bar - it will compile that crate just once with both features enabled.

So all you need to do is to make that dependency's dependency your own dependency and enable all the features you want. You'll have to be careful about keeping versions in sync so adding tests for that would be a good idea.

This was the thing I was looking to avoid. :slight_smile:

I've used B = "*" before, which works as long as nothing is pulling in a newer version of B than what A is using iirc. Rather fragile, but has been acceptable for my purposes.

I think the best solution right now is to make a pull request/issue to A and hope they agree with it.

1 Like