How to override features of dependency?

Let's say I have a crate that depends on sub_crate_1 and sub_crate_2.

Also, sub_crate_2 depends on sub_crate_1.

I want to override the features that my crate specifies for sub_crate_1 - but haven't been able to do this via patches (nor just as-is, I guess since sub_crate_2's listing for sub_crate_1 takes priority?)... seems patches expect me to change the location or version or something, but I just want to change the features.

Is there a way to do this?

Are you tying to make sub_crate_2 use specific features in sub_crate_1, or are you trying to make your crate use specific features in sub_crate_1?

Ultimately I'd expect sub_crate_1 to just be imported once and linked everywhere.

My target is wasm and I have this if it helps:

[lib]
crate-type = ["cdylib"]

There's no good way to do that generically, being that the same crate with two different feature sets are not the same crate. (For a trivial example, I could have a numerical computing crate that has a "decrement one from all results" feature that enables code to subtract one from the return value of all the methods)

If you are sure it's not a breaking change, you can use patches to do this, but you will have to make a copy of the source code and edit its Cargo.toml to use the feature set you want.

Is there a particular issue you are trying to address, such as code size?

Are you trying to duplicate the dependency with different sets of features in each case or what? By default they should use the same instance of the dependency assuming the version numbers match up..

Might be easier to talk this out with the real-world use case...

First there's shipyard
Then a crate that builds on this: shipyard-hierarchy
And there's a crate that builds on both of those: shipyard-scenegraph
Lastly, a "binary" (in the form of wasm). Currently in the examples/ folder of shipyard-scenegraph

shipyard has defaults that are optimal in most scenarios and so I think it makes sense for the other crates to just depend on it as-is. However, wasm isn't most scenarios, and so at that level I need to change features (such as disabling multithreading which isn't quite supported yet).

It sounds like, since you control all three crates, your best bet is to reexport the features from the layer beneath.

Like, have shipyard-hierarchy import shipyard with default-features = false and provide features in shipyard-hierarcy like so

[features]
default = ["shipyard/default"]
parallel = ["shipyard/parallel"]
proc = ["shipyard/proc"]

and so on and so forth.

1 Like

right on, thanks. marked it as the solution.. but curious, would there be a way to solve this if that weren't a realistic option?

Not without patching the dependencies, but at that point, you would be using the crates in ways their authors did not design for.

1 Like

thanks @thatonelutenist - FYI it worked :slight_smile: (and the wasm even builds properly with ci/cd, yay!)

In the end it's not so bad... the crates have a lot of the duplicated feature list, but then the application is just defining the features it needs, which was the ultimate goal.

Does feel like something here could be improved, but of course that's an easy thing to say without knowing the actual details of how it all fits together.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.