Closed pgherveou closed 8 months ago
can you please elaborate on why the previous API was inconvenient? the difference is quite subtle
With the current API we expect that our (frame) runtime also implement drink::Runtime
. We can do that because we create the runtime with the macro, so it's local to the crate where we use it.
If instead we try to bring in a (frame) Runtime that is declared in another crate. Then because of the orphan rule we won't be able to implement the foreign trait (drink::Runtime) on our (foreign frame) runtime.
To make this use case work, this change compose drink::Runtime inside a new Config
trait, instead of using trait inheritance
For reference this is how I am using this PR in ink!
/// Exposes preset sandbox configurations to be used in tests.
pub mod preset {
use drink::impl_sandbox_config;
use pallet_contracts_mock_network::{
parachain::Runtime as ParachainRuntime,
ALICE, INITIAL_BALANCE
};
drink::impl_sandbox_config!(
#[doc = "A Sandbox configuration for the parachain runtime of pallet-contracts-mock-network."]
pub struct ParachainConfig {
runtime: ParachainRuntime;
default_balance: INITIAL_BALANCE;
default_actor: ALICE;
}
);
}
This PR update how the API is structured:
the
Runtime
trait is gone. The way it was structured,made it impossible to bring in an existing Runtime and pass it to a drink or ink! test. This PR moves these APIs to aSandboxConfig
trait, and make theSandbox
generic over that trait.This let us write tests like this
this
create_minimal_runtime
macro is still there, it just now call the newimpl_sandbox_config
macro internally to implement theSandboxConfig
trait.I have an upcoming PR to ink! that will leverage these new API to call e2e tests against a custom runtime. Specifically it will be used with the
pallet-contracts-mock-network
crate to test XCM host functions