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 paritytech/polkadot-sdk-docs#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: Allow frame-macros to work without needing frame-support, frame-system and such being in scope.  polkadot-sdk#173
• blocker: impl_runtime_apis does not work if sp-api is not in scope #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

[liamaharon]

I really like this idea.

w.r.t. the concern that we'll have too many 'minor' versions: is there a reason that we'd need to roll a new release/version every commit? what if instead, once or twice a week we took the current master and rolled a release from that, allowing us to pack multiple breaking changes into a single bump. the intermediary commits could optionally be released under a beta/rc version.

[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.

[kianenigma]

bot fmt

[command-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]

@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

[ggwpez]

Just thinking if there should be actual substrate::client and/or substrate::primitives namespaces?
Re-exporting everything from the substrate crate could work, but not sure if its a good or horrible idea 😆

[stale]

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.