Closed MarijnS95 closed 1 year ago
~I'm not sure that this is fully correct: what if not all crates set default-features = false
, but not all crates are included in a certain compilation: then the features don't get disabled at all.~
~That results in a different question: if any crate referencing the workspace dependency doesn't set default-features = false
, do the features get re-enabled (for that crate)?
If so we can simply do this by checking if any crate has it set to false, instead of checking if any crate has it (implicitly) set to true
.~
Fixed.
rebased the branch.
When packages are added to the workspace they seem to infer default features even if all workspace members disable default features: hence this flag must be propagated to the workspace dependencies list.
By default, if default-features isnt specified, the "default" feature is enabled. So if the workspace doesn't specify it, it implicitly does enable default features which is additive to all other crates in the workspace.
It should not be necessary to inherit feature flags from individual crates, as these are additive across the workspace (but it might be cleaner to strip all common feature flags?).
This I would make configurable. I think it's nice to have all common feature flags at once place as in a big workspace like at work, we often reuse the same feature flags which is just a lot of redundant duplication.
That results in a different question: if any crate referencing the workspace dependency doesn't set default-features = false, do the features get re-enabled
Guess its additive like you say? default-features = false in one crate, ["my_feature"] in another crate, will result in ["my_feature"]. At least seems sensible.
Dependencies automatically enable default features unless default-features = false is specified. This can make it difficult to ensure that the default features are not enabled, especially for a dependency that appears multiple times in the dependency graph. Every package must ensure that default-features = false is specified to avoid enabling them.
https://doc.rust-lang.org/cargo/reference/features.html#the-default-feature
Not a word yet on workspace case, but assume workspace would be 'just an other' crate.
When packages are added to the workspace they seem to infer default features even if all workspace members disable default features: hence this flag must be propagated to the workspace dependencies list.
By default, if default-features isnt specified, the "default" feature is enabled. So if the workspace doesn't specify it, it implicitly does enable default features which is additive to all other crates in the workspace.
The point in the paragraph you quoted is that default-features
is specified, and set to false
.
Guess its additive like you say? default-features = false in one crate, ["my_feature"] in another crate, will result in ["my_feature"]. At least seems sensible.
Correct, that's how it always worked for package members in a workspace.
but assume workspace would be 'just an other' crate.
Seems so, the mere presence of this dependency in the workspace seems to enable "default"
despite all references to said workspace dependency disabling it. Guess that makes sense given that you can configure features in the workspace dependencies table.
This I would make configurable. I think it's nice to have all common feature flags at once place as in a big workspace like at work, we often reuse the same feature flags which is just a lot of redundant duplication.
As mentioned I'd like to do this, at least for common flags - but separate PR :wink:
Depends on #8
When packages are added to the workspace they seem to infer default features even if all workspace members disable default features: hence this flag must be propagated to the workspace dependencies list.
It should not be necessary to inherit feature flags from individual crates though, as these are additive across the workspace (but it might be cleaner to strip all common feature flags?).