I have a large workspace with multiple dependencies that in turn depend on rustls - which in turn by default depends on aws-lc-sys. (has worked fine earlier but have upgraded the dependencies which has bumped the rusttls version)
I have spent several days to try to get aws-lc-sys to build on my windows machine but it seems impossible.
Now, if I depend on rustls directly myself I can do:
rustls = { version = "0.23.12", default-features=false, features=["logging", "std", "tls12", "ring"]}
I.e. I can disable the dependency on aws-lc and use ring which works fine.
However, several of my dependencies depend directly on the default features on rusttls which includes aws-lc and build failures.
So to my question: Is it possible to (in e.g. the workspace Cargo.toml) "remove" the "aws-lc-rs" feature for all rusttls dependencies in my entire dependency chain? No matter what I do cargo seems to "merge" the features and this include aws-lc-rs again..**
I was affraid of that - that makes it a nightmare for things like this where features provide "alternatives" instead of "additions". In practice this would mean that I had to patch 20 + dependicies which is very much not a good solution.
(To me very strange that rustls has opted on a default dependency that requires a lot of additional tools to build - but that ship has sailed )
I see that point - but in this case it is the rustls crate that does it - an extremely widely used crate - that uses them to provide alternative implementation of the crypto primitives (and how would they else do that)?
I don't have an answer but I'm curious about this too, from an API design viewpoint. Should there be runtime selection in code of the crypto primitives (in code), and the feature flags would only make the selected primitives available for use? Is that the recommended approach?
The ideal, least-troublesome feature is one which adds items to the crate when enabled, and does nothing else whatsoever. Dependents of the crate just name whichever specific implementation type they want, after ensuring it exists by enabling the relevant feature. Run-time dispatch is only necessary when dependents want to select at run time, or when some code needs to be kept non-generic yet allow a choice of implementation.
(We can see feature conflicts as a “global state considered harmful” sort of problem, except that instead of the problem being mutating the state at run time, the problem is that two different crates want incompatible states at compile time. But the solution is the same: stop having global state that can conflict; let there be many of the thing instead of one.)
Yes, we agree. By run-time selection I meant calling a function, naming a type, specifying an enum variant, etc. As opposed to just enabling the feature.
File a bug with the crates that enable default features and don't need them. If it makes these crate unusable on windows when it worked before that's a regression that should be fixed.
Thanks for the reply (yours and the others). While I agree that the way the ecosystem is currently set-up a bug may be appropriate I think we are here chasing a problem that will always exist..
People will always be importing crates with default-features (it makes sens to do) - so I really thing the only possible long term solution for the community would be to either allow overriding this (in a negative / exclude way) by the end user/crate or have rustls (and others) not include one of two alternatives by default.
Anyway - I have the reply I need right now - there is no way to do it without me patching my dependencies.
)