Support for Crate-Specific Features via Umbrella Dependency

[SailorSnoW]

Is there an existing issue?

• I have searched the existing issues

Experiencing problems? Have you tried our Stack Exchange first?

• This is not a support question.

Motivation

While managing our dependencies through the Umbrella, we quickly encountered an issue where it seems we are unable to use internal features of the Umbrella's crates. (For instance, insecure_zero_edfrom pallet-balances, historical from pallet-session, etc.)

Request

Enable the use of specific crate features through the Umbrella.

Solution

Have any design choices been considered for this case?
For example, we could import these features via the Umbrella by combining the crate name with the feature name, like so:

pallet-balances-insecure-zero-ed = [
    "pallet-balances?/insecure_zero_ed"
]

Are you willing to help with this request?

Maybe (please elaborate above)

[ggwpez]

Maybe as workaround you can try to enable the feature on the crate directly, since rust feature unification should then merge those. Just make sure to use resolver = 2 in your workspace.

pallet-balances = { version = "*", features = ["insecure_zero_ed"], default-features = false }

Not sure if the * will make cargo pick the same version as the umbrella, or if you have to specify it manually...

For more long term solution guess we could do the concatenation with the features? But it can also turn quite ugly. WDYT @kianenigma ?

[SailorSnoW]

Well, maybe we could simply do the same as the experimental feature and use only the feature name which will enable all crates having this feature name

polkadot-sdk/umbrella/Cargo.toml

Lines 525 to 530 in dada6ce

	experimental = [
	"frame-support-procedural?/experimental",
	"frame-support?/experimental",
	"frame-system?/experimental",
	"polkadot-sdk-frame?/experimental",
	]

[ggwpez]

Depends on what features exactly. I assume that some of them would clash names, but for the big ones it should work.
What features do you need? insecure_zero_ed i guess, what else?
They can be added here and then in the zepter config:

polkadot-sdk/scripts/generate-umbrella.py

Line 113 in d73c56d

"tuples-96": [],

[kianenigma]

hmm this seems like an issue indeed.

Combining names seems like a time bomb, I would not try this.

For the ones that we have, we should indeed treat them like experimental and just expose them at the top level umbrella. It seems to be the best we can do atm.

Long term, I hope we can reduce the number of custom feature flag we have. They are not meant to be a gate for "experimental" stuff. So the feature "insecure_zero_ed" would overall go away.

[SailorSnoW]

Here is some features that seems important to us to use Umbrella for our runtimes which is currently missing:

• historical from pallet-session
• metadata-hash from substrate-wasm-builder

[kianenigma]

@ggwpez can you see through with this please? It can probably be documented and contributed by someone else.

[ggwpez]

Not sure i get the outcome of this discussion.
So we do add features like this:

"pallet-session+historical" = ["pallet-session/historical"]

To the umbrella crate, yea? This would then allow downstream to enable features of crates without listing them again in the toml file.

[kianenigma]

Is what @bkchr suggested here a good workaround for this?

#6987 (comment)

1. pull umbrella and let that dictate your version.
2. Use some-crate = { version = "*", feature = ["more", "stuff"] }.

[ggwpez]

I think that does actually not work for crates that you want to publish. But will double-check.
If we could align ALL sdk crate versions then it would also be easy to select the matching ones.

[huntbounty]

I may not fully grasp all the implications here. To address this, for each exported crate crate-a and each of its features feat-b, feat-c.. (perhaps excluding std etc), there should be a corresponding feature in polkadot-sdk, so that it's possible for users to pinpoint the dependency features to enable via the umbrella crate. Does that sound right to you? 👼 @ggwpez @kianenigma

If there isn't a naming convention for the feature names in this case yet, we may consider

[features]
# ...
crate-a-feat-b = ["crate-a?/feature-b"]
crate-a+feat-b = ["crate-a?/feature-b"]
"crate-a+feat-b" = ["crate-a?/feature-b"]
crate-a_feat-b = ["crate-a?/feature-b"]
crate-a_feat-c = ["crate-a?/feature-c"]
# ...

• with -, easiest to type, but lacking the visual cue separating the crate name and the feature name
• with +, the feature name has to be quoted and what a+b means may not be intuitive at first glance (I'd think it enables both a and b features).

I'd vote for crate-a-feat-b (if the visual cue isn't critical) or crate-a_feat-b. What do you think? 😊

[ggwpez]

Yes I think you got it right. You can exclude shared features like runtime-benchmarks, try-runtime and std. Just take a look at the umbrella Cargo.toml.

We can also go with the crate_feature with underscore, I dont really mind. It is probably easy to switch in the script in the end if we want to change it. But I did not realize that + would cause it to be quoted, does look a bit odd, yea.