-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify feature-flag and use common types #62
Conversation
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit wary of having a common
module like this, because it's only really for types common between v14 and v15 (and over time I could see it becoming a bit of a mess of types that are in common between certain versions (and the feature flags would become more meaningless as more "common" types are always included, which might not matter).
My original thought was that the v15
module could just import and pub use
the types it wanted from v14
(and then eg v16 could do the same with v15, v17 with v16 and so on).
The feature flags complicate this though, and as we add more versions and have more common types shared between further-apart versions it'll get more annoying if we want to hdie and show the relevant types for a given set of feature flags, when they are shared.
I'm not quite sure what the utility of the feature flags really is either (aside from the "unstable-v15" one which is good becasue it hides an unstable part of the interface). @ascjones do you have more insight into what the feature flags are here for?
If we can ditch the feature flags (aside from any "unstable" ones while needed) it'd make life easy and we can just import from v14
any types we want to also expose as v15
types, and do the same when v16 lands etc.
If not, I'd probably tweak the common
module so that each type is feature flagged to make clear which versions it's common for (and generally honour the feature flags hiding unnecessary stuff). At least that way if it becomes messier it'll always be clear which types are used where.
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Have moved the feature flags on struct declaration and impls from the common file to unblock this. Looking forwards, it would be much better from a maintenance perspective to remove the version feature flags (v14, v15 etc). The new versions V14 and V15 bring with them the Considering that this is an edge-case that could be later mitigated by having one single |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm happy for the version feature flags to go, I can't remember the reasoning...I think it is historical artefact from when I hijacked this repository after it was forked from the in tree frame-metadata
crate.
Thanks for the feedback! Id propose in that case that we could have the following flags:
And then we can ditch the current feature flags and ditch this I guess all of this will be a breaking change anyway when we stabilise v15 in a couple of weeks so now is as good a time as any to break the features?! |
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
Signed-off-by: Alexandru Vasile <[email protected]>
The changes look great, and yeah feels simpler now too with the new feature flags. I guess I'm ok with us marking V15 as stable in this PR, which is the only contentious change here; it does mean we won't want to release this until we are happy to call V15 stable and done, but hopefully we're about there now! |
Signed-off-by: Alexandru Vasile <[email protected]>
frame-metadata/src/lib.rs
Outdated
pub mod v14; | ||
|
||
/// Metadata v15 | ||
#[cfg(feature = "v15-unstable")] | ||
#[cfg(all(feature = "unstable", feature = "current"))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should it be the other way round? ie if you enable the "unstable" feature you get v14 and v15 (since some types are shared). And if you enable "current" you just get v14 atm?
Currently this means you need to enable "current" and "unstable" to get unstable metadata.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh yea! It makes more sense to have the unstable
feature enable the current
than to need to specify them both, thanks! Have modified it
Signed-off-by: Alexandru Vasile <[email protected]>
Looks good to me :) |
This PR makes the following changes to the repo, in preparation for the V15 stabilization:
Feature Flags
The version feature flags are now removed and replaced by:
legacy
this feature flag enables only the versions prior to V14current
this feature flag enables the latest stabilized metadata versionsunstable
this feature flag enables the unstable metadata that is currently in work until stabilizationCommon Types
The V15 and V14 shared a few common types. With the introduction of the new feature flags, the V15 metadata directly uses the common types exposed by V14.
This saves some extra lines of code from maintenance and allows easier conversions between V14 and V15 (from subxt and substrate)
// @paritytech/subxt-team