Forwarding features / package hierarchy
Background
At the time of writing, it's hard to select the crypto backend workspace-wide. We can select the backend for the openpgp
crate directy but it's more involved for other packages that depend on it. One example where it proved to be cumbersome is when trying to build the openpgp-ffi
crate with Windows CNG backend.
Currently, the workspace manifest specifies both [package]
and [workspace]
entries - this means that it acts both as a single package and as a workspace. While clever and historically this has allowed to roll out the Cargo workspace feature in a back-compat way, it leads to surprising interactions.
For example, calling cargo build -p XYZ
specifies the -p XYZ
for the workspace but also takes the [package]
-relevant dependencies into account, even if these are not directly related to the XYZ
workspace member package. Another example is that passing --no-default-features
or --features
in cargo -p XYZ ...
works for the [package]
and not the -p XYZ
package specified.
Solutions
[package]
Remove One idea is to get rid of the [package]
entirely and only use the [workspace]
, optionally coupled with [workspace.default-members]
. This still doesn't enable us to use --features
or --no-default-features
but removes an element of surprise. With it, Cargo can now warn us that passing these has no effect when running against pure virtual manifest (containing only [workspace]
).
This would require that every member package that uses the openpgp
package exposes its own crypto-XYZ
feature set and forwards it to the openpgp
. This means a bit more boilerplate but may be useful when directly using these from crates.io and not in the local workspace setting.
If we would still like to keep the umbrella package for whatever reason, we could have it defined as a workspace member package that would re-export select dependencies, such as openpgp
or net
, with [workspace.default-members]
pointing to it.
[package]
select features across the workspace
Let We could change every dependency on openpgp
to default-features = false
and only expose the forwarding features on the root [package]
.
This would mean that running cargo check -p XYZ --feature crypto-cng
would work as "expected", in the sense that the root package would affect the feature resolver and select the crypto backend, even if the root package would not participate in the build (e.g. only a member package such as sequoia-net
would be built).
On the flip side, if we expect the packages to work in the crates.io setting and want the users to explicitly depend on other packages here that depend on openpgp
, there's no way around exposing the crypto features on each package and forwarding it to the openpgp
, as suggested in the solution before.
cc @teythoon