Add subxt feature in subxt-signer crate to default features
#1193
Conversation
|
I wonder whether, to fix the feature flag compile issue, we should add no-default-features to the subxt dep in subxt-signer (it shouldn't care, after all, which subxt features are enabled). That might lead to other issues htough; needs some playing with! |
| @@ -15,7 +15,7 @@ description = "Sign extrinsics to be submitted by Subxt" | |||
| keywords = ["parity", "subxt", "extrinsic", "signer"] | |||
|
|
|||
| [features] | |||
| default = ["sr25519", "ecdsa"] | |||
| default = ["sr25519", "ecdsa", "subxt", "native"] | |||
There was a problem hiding this comment.
I don't really understand this change; it means that signer by default will be "native" and then to be web you need to disable default features and then select eg subxt,web?
I think it'd be better to be consistent with subxt and ask the dependee library to pick which one it wants explicitly. This way, libraries can (and should) defer the choice unless it's relevant to them, and with features being additive, picking one by default also increases the odds that both end up enabled in a tree, breaking compilation
There was a problem hiding this comment.
@jsdw My reasoning was that in 90% of cases people will just want to use it with native anyway. But you are right, I will change it to be similar to subxt in that an explicit choice has to be made.
There was a problem hiding this comment.
Yeah, I get that; my main issue is that feature flags are additive and so the choice to enable web or native should be made at the last possible moment; enabling it by default makes it more likely that something depending on subxt somewhere in the tree and not thinking about features will screw up somebody trying to compile instead to web or whatever :)
Fixes #1189 .
Small PR to simplify use of subxt-signer to avoid confusion.