fix: Complete snowbridge pezpallet rebrand and critical bug fixes
- snowbridge-pezpallet-* → pezsnowbridge-pezpallet-* (201 refs) - pallet/ directories → pezpallet/ (4 locations) - Fixed pezpallet.rs self-include recursion bug - Fixed sc-chain-spec hardcoded crate name in derive macro - Reverted .pezpallet_by_name() to .pallet_by_name() (subxt API) - Added BizinikiwiConfig type alias for zombienet tests - Deleted obsolete session state files Verified: pezsnowbridge-pezpallet-*, pezpallet-staking, pezpallet-staking-async, pezframe-benchmarking-cli all pass cargo check
This commit is contained in:
@@ -1,32 +1,32 @@
|
||||
//! # FRAME Pallet Coupling
|
||||
//! # FRAME Pezpallet Coupling
|
||||
//!
|
||||
//! This reference document explains how FRAME pallets can be combined to interact together.
|
||||
//!
|
||||
//! It is suggested to re-read [`crate::pezkuwi_sdk::frame_runtime`], notably the information
|
||||
//! around [`frame::pezpallet_macros::config`]. Recall that:
|
||||
//!
|
||||
//! > Configuration trait of a pallet: It allows a pallet to receive types at a later
|
||||
//! > point from the runtime that wishes to contain it. It allows the pallet to be parameterized
|
||||
//! > Configuration trait of a pezpallet: It allows a pezpallet to receive types at a later
|
||||
//! > point from the runtime that wishes to contain it. It allows the pezpallet to be parameterized
|
||||
//! > over both types and values.
|
||||
//!
|
||||
//! ## Context, Background
|
||||
//!
|
||||
//! FRAME pallets, as per described in [`crate::pezkuwi_sdk::frame_runtime`] are:
|
||||
//!
|
||||
//! > A pallet is a unit of encapsulated logic. It has a clearly defined responsibility and can be
|
||||
//! > A pezpallet is a unit of encapsulated logic. It has a clearly defined responsibility and can be
|
||||
//! linked to other pallets.
|
||||
//!
|
||||
//! That is to say:
|
||||
//!
|
||||
//! * *encapsulated*: Ideally, a FRAME pallet contains encapsulated logic which has clear
|
||||
//! boundaries. It is generally a bad idea to build a single monolithic pallet that does multiple
|
||||
//! * *encapsulated*: Ideally, a FRAME pezpallet contains encapsulated logic which has clear
|
||||
//! boundaries. It is generally a bad idea to build a single monolithic pezpallet that does multiple
|
||||
//! things, such as handling currencies, identities and staking all at the same time.
|
||||
//! * *linked to other pallets*: But, adhering extensively to the above also hinders the ability to
|
||||
//! write useful applications. Pallets often need to work with each other, communicate and use
|
||||
//! each other's functionalities.
|
||||
//!
|
||||
//! The broad principle that allows pallets to be linked together is the same way through which a
|
||||
//! pallet uses its `Config` trait to receive types and values from the runtime that contains it.
|
||||
//! pezpallet uses its `Config` trait to receive types and values from the runtime that contains it.
|
||||
//!
|
||||
//! There are generally two ways to achieve this:
|
||||
//!
|
||||
@@ -63,7 +63,7 @@
|
||||
//!
|
||||
//! ## Example
|
||||
//!
|
||||
//! Consider the following example, in which `pezpallet-foo` needs another pallet to provide the block
|
||||
//! Consider the following example, in which `pezpallet-foo` needs another pezpallet to provide the block
|
||||
//! author to it, and `pezpallet-author` which has access to this information.
|
||||
#![doc = docify::embed!("./src/reference_docs/frame_pallet_coupling.rs", pezpallet_foo)]
|
||||
#![doc = docify::embed!("./src/reference_docs/frame_pallet_coupling.rs", pezpallet_author)]
|
||||
@@ -71,16 +71,16 @@
|
||||
//! ### Tight Coupling Pallets
|
||||
//!
|
||||
//! To tightly couple `pezpallet-foo` and `pezpallet-author`, we use Rust's supertrait system. When a
|
||||
//! pallet makes its own `trait Config` be bounded by another pallet's `trait Config`, it is
|
||||
//! pezpallet makes its own `trait Config` be bounded by another pezpallet's `trait Config`, it is
|
||||
//! expressing two things:
|
||||
//!
|
||||
//! 1. That it can only exist in a runtime if the other pallet is also present.
|
||||
//! 2. That it can use the other pallet's functionality.
|
||||
//! 1. That it can only exist in a runtime if the other pezpallet is also present.
|
||||
//! 2. That it can use the other pezpallet's functionality.
|
||||
//!
|
||||
//! `pezpallet-foo`'s `Config` would then look like:
|
||||
#![doc = docify::embed!("./src/reference_docs/frame_pallet_coupling.rs", tight_config)]
|
||||
//!
|
||||
//! And `pezpallet-foo` can use the method exposed by `pezpallet_author::Pallet` directly:
|
||||
//! And `pezpallet-foo` can use the method exposed by `pezpallet_author::Pezpallet` directly:
|
||||
#![doc = docify::embed!("./src/reference_docs/frame_pallet_coupling.rs", tight_usage)]
|
||||
//!
|
||||
//!
|
||||
@@ -120,9 +120,9 @@
|
||||
//!
|
||||
//! ## Frame System
|
||||
//!
|
||||
//! With the above information in context, we can conclude that **`pezframe_system` is a special pallet
|
||||
//! that is tightly coupled with every other pallet**. This is because it provides the fundamental
|
||||
//! system functionality that every pallet needs, such as some types like
|
||||
//! With the above information in context, we can conclude that **`pezframe_system` is a special pezpallet
|
||||
//! that is tightly coupled with every other pezpallet**. This is because it provides the fundamental
|
||||
//! system functionality that every pezpallet needs, such as some types like
|
||||
//! [`frame::prelude::pezframe_system::Config::AccountId`],
|
||||
//! [`frame::prelude::pezframe_system::Config::Hash`], and some functionality such as block number,
|
||||
//! etc.
|
||||
@@ -132,18 +132,18 @@
|
||||
//! To recap, consider the following rules of thumb:
|
||||
//!
|
||||
//! * In all cases, try and break down big pallets apart with clear boundaries of responsibility. In
|
||||
//! general, it is easier to argue about multiple pallet if they only communicate together via a
|
||||
//! general, it is easier to argue about multiple pezpallet if they only communicate together via a
|
||||
//! known trait, rather than having access to all of each others public items, such as storage and
|
||||
//! dispatchables.
|
||||
//! * If a group of pallets is meant to work together, but is not foreseen to be generalized, or
|
||||
//! used by others, consider tightly coupling pallets, *if it simplifies the development*.
|
||||
//! * If a pallet needs a functionality provided by another pallet, but multiple implementations can
|
||||
//! * If a pezpallet needs a functionality provided by another pezpallet, but multiple implementations can
|
||||
//! be foreseen, consider loosely coupling pallets.
|
||||
//!
|
||||
//! For example, all pallets in `pezkuwi-sdk` that needed to work with currencies could have been
|
||||
//! tightly coupled with [`pezpallet_balances`]. But, `pezkuwi-sdk` also provides [`pezpallet_assets`]
|
||||
//! (and more implementations by the community), therefore all pallets use traits to loosely couple
|
||||
//! with balances or assets pallet. More on this in [`crate::reference_docs::frame_tokens`].
|
||||
//! with balances or assets pezpallet. More on this in [`crate::reference_docs::frame_tokens`].
|
||||
//!
|
||||
//! ## Further References
|
||||
//!
|
||||
@@ -158,17 +158,17 @@
|
||||
use frame::prelude::*;
|
||||
|
||||
#[docify::export]
|
||||
#[frame::pallet]
|
||||
#[frame::pezpallet]
|
||||
pub mod pezpallet_foo {
|
||||
use super::*;
|
||||
|
||||
#[pallet::config]
|
||||
#[pezpallet::config]
|
||||
pub trait Config: pezframe_system::Config {}
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
#[pezpallet::pezpallet]
|
||||
pub struct Pezpallet<T>(_);
|
||||
|
||||
impl<T: Config> Pallet<T> {
|
||||
impl<T: Config> Pezpallet<T> {
|
||||
fn do_stuff_with_author() {
|
||||
// needs block author here
|
||||
}
|
||||
@@ -176,41 +176,41 @@ pub mod pezpallet_foo {
|
||||
}
|
||||
|
||||
#[docify::export]
|
||||
#[frame::pallet]
|
||||
#[frame::pezpallet]
|
||||
pub mod pezpallet_author {
|
||||
use super::*;
|
||||
|
||||
#[pallet::config]
|
||||
#[pezpallet::config]
|
||||
pub trait Config: pezframe_system::Config {}
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
#[pezpallet::pezpallet]
|
||||
pub struct Pezpallet<T>(_);
|
||||
|
||||
impl<T: Config> Pallet<T> {
|
||||
impl<T: Config> Pezpallet<T> {
|
||||
pub fn author() -> T::AccountId {
|
||||
todo!("somehow has access to the block author and can return it here")
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
#[frame::pallet]
|
||||
#[frame::pezpallet]
|
||||
pub mod pezpallet_foo_tight {
|
||||
use super::*;
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
#[pezpallet::pezpallet]
|
||||
pub struct Pezpallet<T>(_);
|
||||
|
||||
#[docify::export(tight_config)]
|
||||
/// This pallet can only live in a runtime that has both `pezframe_system` and `pezpallet_author`.
|
||||
#[pallet::config]
|
||||
/// This pezpallet can only live in a runtime that has both `pezframe_system` and `pezpallet_author`.
|
||||
#[pezpallet::config]
|
||||
pub trait Config: pezframe_system::Config + pezpallet_author::Config {}
|
||||
|
||||
#[docify::export(tight_usage)]
|
||||
impl<T: Config> Pallet<T> {
|
||||
impl<T: Config> Pezpallet<T> {
|
||||
// anywhere in `pezpallet-foo`, we can call into `pezpallet-author` directly, namely because
|
||||
// `T: pezpallet_author::Config`
|
||||
fn do_stuff_with_author() {
|
||||
let _ = pezpallet_author::Pallet::<T>::author();
|
||||
let _ = pezpallet_author::Pezpallet::<T>::author();
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -221,23 +221,23 @@ pub trait AuthorProvider<AccountId> {
|
||||
fn author() -> AccountId;
|
||||
}
|
||||
|
||||
#[frame::pallet]
|
||||
#[frame::pezpallet]
|
||||
pub mod pezpallet_foo_loose {
|
||||
use super::*;
|
||||
|
||||
#[pallet::pallet]
|
||||
pub struct Pallet<T>(_);
|
||||
#[pezpallet::pezpallet]
|
||||
pub struct Pezpallet<T>(_);
|
||||
|
||||
#[docify::export(loose_config)]
|
||||
#[pallet::config]
|
||||
#[pezpallet::config]
|
||||
pub trait Config: pezframe_system::Config {
|
||||
/// This pallet relies on the existence of something that implements [`AuthorProvider`],
|
||||
/// This pezpallet relies on the existence of something that implements [`AuthorProvider`],
|
||||
/// which may or may not be `pezpallet-author`.
|
||||
type AuthorProvider: AuthorProvider<Self::AccountId>;
|
||||
}
|
||||
|
||||
#[docify::export(loose_usage)]
|
||||
impl<T: Config> Pallet<T> {
|
||||
impl<T: Config> Pezpallet<T> {
|
||||
fn do_stuff_with_author() {
|
||||
let _ = T::AuthorProvider::author();
|
||||
}
|
||||
@@ -245,9 +245,9 @@ pub mod pezpallet_foo_loose {
|
||||
}
|
||||
|
||||
#[docify::export(pezpallet_author_provider)]
|
||||
impl<T: pezpallet_author::Config> AuthorProvider<T::AccountId> for pezpallet_author::Pallet<T> {
|
||||
impl<T: pezpallet_author::Config> AuthorProvider<T::AccountId> for pezpallet_author::Pezpallet<T> {
|
||||
fn author() -> T::AccountId {
|
||||
pezpallet_author::Pallet::<T>::author()
|
||||
pezpallet_author::Pezpallet::<T>::author()
|
||||
}
|
||||
}
|
||||
|
||||
@@ -269,7 +269,7 @@ impl<AccountId> AuthorProvider<AccountId> for () {
|
||||
|
||||
pub mod runtime {
|
||||
use super::*;
|
||||
use pezcumulus_pezpallet_aura_ext::pallet;
|
||||
use pezcumulus_pezpallet_aura_ext::pezpallet;
|
||||
use frame::{runtime::prelude::*, testing_prelude::*};
|
||||
|
||||
construct_runtime!(
|
||||
@@ -289,7 +289,7 @@ pub mod runtime {
|
||||
|
||||
#[docify::export(runtime_author_provider)]
|
||||
impl pezpallet_foo_loose::Config for Runtime {
|
||||
type AuthorProvider = pezpallet_author::Pallet<Runtime>;
|
||||
type AuthorProvider = pezpallet_author::Pezpallet<Runtime>;
|
||||
// which is also equivalent to
|
||||
// type AuthorProvider = PalletAuthor;
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user