The same crate with different features

[uuhan]

Problem

[package]
name = "test-features"
version = "0.1.0"
edition = "2021"

[dependencies]
casbin = "2.0.9"
rhai = "1.5.0"

casbin has rhai as it's dependency with features:

rhai = { version = "1.5.0", features = [
  "sync",
  "only_i32",
  "no_function",
  "no_float",
  "no_optimize",
  "no_module",
  "serde",
  "unchecked",
] }

So I can not use rhai without the feature no_module

Proposed Solution

[dependencies.rhai]
version = "1.5.0"
isolated = true # maybe have this flag to use the dependency as an isolated one, so it's features does not include `no_module`

[dependencies.casbin]
version = "2.0.9" # this crate have the dependency `rhai==1.5.0` with feature `no_module` enabled.

Notes

No response

[weihanglo]

I believe it's the behaviour of feature unification, unfortunately. Cargo will use the union of features of a dependency if it appears multiple times in the dependency graph. A rule of thumb is that define features as additive as possible. However, rhai also had a hard time transiting features to additive and here is the discussion.

The proposed solution seems straight-forward but the devil is in the details. Does isolated mean they are two separate dependency graph? Should cargo stop unifying their transitive dependencies as well? Personally I cannot foresee any reasonable design at the moment 🥲

As a workaround, maybe you can try to fork rhai and make it a different package or split the dependent into different crates, so that cargo probably won't merge them.

[uuhan]

I believe it's the behaviour of feature unification, unfortunately. Cargo will use the union of features of a dependency if it appears multiple times in the dependency graph. A rule of thumb is that define features as additive as possible. However, rhai also had a hard time transiting features to additive and here is the discussion.

The proposed solution seems straight-forward but the devil is in the details. Does isolated mean they are two separate dependency graph? Should cargo stop unifying their transitive dependencies as well? Personally I cannot foresee any reasonable design at the moment 🥲

As a workaround, maybe you can try to fork rhai and make it a different package or split the dependent into different crates, so that cargo probably won't merge them.

Currently, I just fork the rhai package and rename it to other name. It works, but, emmm, very unconfortable for the further update.

I wonder if the package feature could be extended to satisify this need, like this:

[dependency.my-rhai]
package = "rhai"
version = "1.5.0"
features = ["sync"]

If all the package info of rhai is bound to the new package name my-rhai, and can not be affected by casbin's dependency. But it seems currently the usage of package = "rhai" just alias the crate name, not keeps the features isolated.

[ehuss]

I'm going to close as this is expected behavior with how features are unified. Features should be additive, and it looks like there was some discussion in the linked issue about possibly fixing rhai's use of features. I think it is unlikely that cargo will gain the ability to build multiple copies with different features, or support "negative" features. I recommend working with the casbin or rhai maintainers to find a solution.