TimonPost / cargo-dependency-inheritor

Utility to inherit dependencies from workspace file if it occurs 'n' or more times throughout the project.
Apache License 2.0
30 stars 1 forks source link

Inherit `default-features = false` from packages #9

Closed MarijnS95 closed 1 year ago

MarijnS95 commented 1 year ago

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?).

MarijnS95 commented 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.

TimonPost commented 1 year ago

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.

TimonPost commented 1 year ago

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.

MarijnS95 commented 1 year ago

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: