feat: `FRAME` umbrella crate.

[kianenigma]

This brings in a new crate that is a mere re-export of common FRAME APIs into a new crate, and re-exports them, with better documentation.

This is WIP experiment. My initial goal is to build https://github.com/paritytech/polkadot-sdk-docs/issues/3 using only this crate.

Whether it would be feasible to actually build things with it, I am not sure. Consider this an experiment for now. As a next step, I can re-build node-template/pallets using this crate.

An end-goal is something along the lines of:

• frame = { version = "X" } is the umbrella crate with which you should be a frame pallet
• frame = { version = "X", feature = "runtime" } is the umbrella crate to build a frame-based runtime.
• Of course, for certain deep functionality, you can tap into things like sp_io and sp_core directly.
• With that, your runtime's dependency would be:
  • a list of frame pallets, each built with a specific version of frame.
  • frame itself, with a matching version.
• substrate-node should be the umbrella crate for all things sc-* related.
• parachain-sdk or cumulus (name tbd) should be the umbrella crate for turning both of the above into a parachain PVF and Collator, as opposed to a normal runtime and node respectively.

You can see an example pallet built with this method here, and an example runtime here.

• [ ] blocker: https://github.com/paritytech/polkadot-sdk/issues/173
• [x] blocker: https://github.com/paritytech/substrate/issues/14145
• [ ] I am open to a different name, perhaps frame-api?

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/psa-parity-is-currently-working-on-merging-the-polkadot-stack-repositories-into-one-single-repository/2883/5

[gavofyork]

If we're going for lots of convenience, we might want to take another look at typical use usage in pallets and runtimes and augment prelude accordingly.

[JoshOrndorff]

This is a cool effort. I'm glad to see you trying this. I remember Ben dreaming of a similar re-export crate several years ago.

substrate-node should be the umbrella crate for all things sc-* related.

Maybe substrate-client because that is what the c stands for.

re-exports them, with better documentation.

When I read this, alarms go off in my head. Why two sets of docs? Why not make the existing docs better and use the good ones in both places (ideally without copy-pasting if possible). What if a design change is made to frame and the developer only updates the docs in one place. What if someone stumbles upon the not-as-good docs and decides to make them better? All just things to think about. Again I like this idea overall.

If you are so inclined you can look at the tuxedo-core crate (or its rustdocs). It contains everything a developer will need to develop a runtime with Tuxedo. Whether they are making a piece (like a pallet) or a complete runtime. This sounds similar to your goal for FRAME. Although in Tuxedo's case it is not re-exports. We really just have a single crate for the main runtime framework.

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/psa-parity-is-currently-working-on-merging-the-polkadot-stack-repositories-into-one-single-repository/2883/14

[kianenigma]

An existential fear that I have about this is to realize one day that cleaning up frame_support and perhaps re-naming it might have been an easier path forward.

Nonetheless:

1. The lessons we are learning along the way, and the tools we are creating are valuable.
2. A new crate will be a much smoother transition for everyone.

[sam0x17]

When I read this, alarms go off in my head. Why two sets of docs?

My understanding of it is it's not two sets of docs, it's that there right now is no proper "index" of FRAME. So the aim is to both clean up the existing docs and add some docs on this central frame crate that guide you to the right thing and provide some high level information that may be missing by virtue of there not being a central place in the rust docs right now that talks about frame

[gui1117]

An existential fear that I have about this is to realize one day that cleaning up frame_support and perhaps re-naming it might have been an easier path forward.

Nonetheless:

1. The lessons we are learning along the way, and the tools we are creating are valuable.

2. A new crate will be a much smoother transition for everyone.

what part are you thinking about?

Personnally when we remove decl_storage I would like to remove the storage::generator module. For the traits StorageValue, StorageMap, StorageDoubleMap, IterableStorageMap ...StoragePrefixedMap AFAICT people don't use them anymore and use the types only. When we want to abstract over storage like pallet balances AccountStore we use StoredMap trait. So maybe we can remove those traits, or refactor some stuff there.

when we remove decl_module we can refactor a bit the code, some type like CallableCallOf could be removed, some trait could be refactored.

But all I can see is some isolated refactor due to removing of old macros. Otherwise I don't see what should be changed/organized differently

[ggwpez]

Personnally when we remove decl_storage I would like to remove the storage::generator module.

Yea I had a look at that code when working with the pallet-paged-list. A lot of stuff can be cleaned up there once we remove the decl macros 🤞 https://github.com/paritytech/substrate/issues/14400

[kianenigma]

bot fmt

[command-bot[bot]]

@kianenigma https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3201202 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh". Check out https://gitlab.parity.io/parity/mirrors/substrate/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 8-1d6e48de-7091-47b7-a0d4-b738ea7950a5 to cancel this command or bot cancel to cancel all commands in this pull request.

[command-bot[bot]]

@kianenigma Command "$PIPELINE_SCRIPTS_DIR/commands/fmt/fmt.sh" has finished. Result: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3201202 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3201202/artifacts/download.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs. Job name: cargo-check-each-crate Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/3201148

[stale[bot]]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.