Use the umbrella crate for the parachain template

[serban300]

Use the umbrella crate for the parachain template

This covers almost all the dependencies. There are just a few exceptions for which I created a separate issue: #5993

Also related to: #4782

[kianenigma]

You can decide to do this in a separate PR, but part of the issue requirement is also to move the runtime+pallet to polkadot-sdk-frame umbrella crate.

You can see the minimal template for how this works.

You might need to add more items to the preludes in polkadot-sdk-frame for this. See #4782

[serban300]

You can decide to do this in a separate PR, but part of the issue requirement is also to move the runtime+pallet to polkadot-sdk-frame umbrella crate.

You can see the minimal template for how this works.

You might need to add more items to the preludes in polkadot-sdk-frame for this. See #4782

@kianenigma I migrated also the runtime + pallet, but I had to keep a few of the old crates because of some limitations. I will create a follow-up issue for this.

This PR is ready for review. PTAL !

[kianenigma]

@kianenigma I migrated also the runtime + pallet, but I had to keep a few of the old crates because of some limitations. I will create a follow-up issue for this.

But you have not migrated them to polkadot-sdk-frame, have you? you have migrated them to polkadot-sdk, they are different :)

In fact, I see now that even in the original PR for the minimal template, we have not fully moved the runtime to the polkadot-sdk-frame.

In short, I think for our templates, we should build the pallet+runtime ONLY with polkadot-sdk-frame.

Pinging a few heads to agree with this: @ggwpez @franciscoaguirre @muharem @shawntabrizi and if agreed, I suggest not further deferring this goal.

I am fixing a lot of the little shortcomings in polkadot-sdk-frame #5995. But, we should also ack that we can never nail frame umbrella crate until we start using it. I suggest we proceed with making it the sole dependency of all 3 template runtime, and in the process we will learn all the little items that are left to do.

[serban300]

@kianenigma I migrated also the runtime + pallet, but I had to keep a few of the old crates because of some limitations. I will create a follow-up issue for this.

But you have not migrated them to polkadot-sdk-frame, have you? you have migrated them to polkadot-sdk, they are different :)

In fact, I see now that even in the original PR for the minimal template, we have not fully moved the runtime to the polkadot-sdk-frame.

In short, I think for our templates, we should build the pallet+runtime ONLY with polkadot-sdk-frame.

Pinging a few heads to agree with this: @ggwpez @franciscoaguirre @muharem @shawntabrizi and if agreed, I suggest not further deferring this goal.

I am fixing a lot of the little shortcomings in polkadot-sdk-frame #5995. But, we should also ack that we can never nail frame umbrella crate until we start using it. I suggest we proceed with making it the sole dependency of all 3 template runtime, and in the process we will learn all the little items that are left to do.

Oh sorry, I didn't know that. I thought I had to use polkadot-sdk everywhere.

But what's the difference ? Isn't it another way of referring to the same crates in the end ?

[kianenigma]

Oh sorry, I didn't know that. I thought I had to use polkadot-sdk everywhere.

But what's the difference ? Isn't it another way of referring to the same crates in the end ?

Similar, but the polkadot-sdk-frame is both a re-export of common crates (similar to polkadot-sdk), and it provides various preludes that clean up a lot of the need for various dependencies to be declared from different places.

Please see this commit d253bc5 and the docs for polkadot-sdk-frame in the PR I linked above.

[kianenigma]

We can still merge this PR as is, happy to take a step back and not be a blocker as it is a clear improvement :)

But my overall intention here is to standardize:

with this PR and #5995:

1. All pallets in our repo should be moved to use frame
2. All pallets in our templates should be built solely with frame
3. All template runtimes should also aim to be used only with frame+frame::runtime.
4. In all cases so far:

• option 1: we import frame as polkadot_sdk::polkadot_sdk_frame
• option 2: we import it standalone as frame only

5. All node side template code should be moved to use polkadot-sdk umbrella crate.

As for the decision tree above, I am personally in favor of using it just as frame, with a clear guideline/doc that says "if you need more crates, please import polkadot-sdk". This is because if polkadot-sdk is in scope, I think people still tend to fallback to use polkadot_sdk::sp_something::deep::path::Type versus adding it to frame::prelude::/frame::runtime::prelude which is already in scope. But both are acceptable IMO.

I would like to make a decision about the "umbrella crate strategy", and present it in Sub0, so please chime in, and be contrarion if you want to :)

[ggwpez]

In all cases so far:
option 1: we import frame as polkadot_sdk::polkadot_sdk_frame
option 2: we import it standalone as frame only

I think there is not much difference, as long as people are using the frame crate at all (no matter where they import it from).
The import location can be changed with one line, so the difficult part is to use it in the beginning i think.

[serban300]

@kianenigma @ggwpez

Implemented the suggestions. For the pallet I used only the frame dependency. Indeed it simplified things significantly. For the runtime we needed the polkadot-sdk dependency anyway, so I used only that. But imported polkadot_sdk::* as you suggested. PTAL !

[bkchr]

Why are we enabling a experimental feature in our templates? There is something fishy again..

[kianenigma]

I would soon remove this flag from the frame umbrella crate, rest assured.

[serban300]

Looks like it wasn't needed. Removed it.

[bkchr]

What about all the other Checked* traits and Zero?

[serban300]

Added them.