[E2E alternative backend]: Backend choice #1864
Conversation
pmikolajczyk41
requested review from
cmichi,
ascjones and
SkymanOne
as code owners
…macro # Conflicts: # CHANGELOG.md
…macro # Conflicts: # CHANGELOG.md # crates/e2e/Cargo.toml # crates/e2e/macro/src/codegen.rs # crates/e2e/src/lib.rs # crates/e2e/src/subxt_client.rs
| /// Identifier type for an actor. | ||
| type ActorId; | ||
| /// Account type. | ||
| type AccountId; |
There was a problem hiding this comment.
Doesn't it make sense to add Clone + Send + Sync trait bounds to this associated type since it looks like you impose them later in drink_client anyway?
There was a problem hiding this comment.
requiring bounds on the associated type here would be a bit implementation-based, so I'm not convinced if it is the correct move
but anyway, even if I put these bounds here, I would have to keep them in the impl<AccountId, *> *Backend for *, so nothing to 'gain' here
| @@ -22,6 +22,7 @@ ink_primitives = { workspace = true, default-features = true } | |||
|
|
|||
| cargo_metadata = { workspace = true } | |||
| contract-build = { workspace = true } | |||
| drink = { workspace = true } | |||
There was a problem hiding this comment.
Should we consider having a feature flag for this, since it is bringing in a few heavy substrate dependencies and (at the moment) is not the default backend.
There was a problem hiding this comment.
fair point, I'll hide it tomorrow
There was a problem hiding this comment.
~70 new dependencies, some of which are substrate crates (for state-machines, externalities, few pallets etc)
Finally we provide implementation of
E2EBackendtrait for a drink-based client. Also, we add a new argument fore2e-testmacro, enabling user to specify target backend architecture.Since
drinklibrary is pretty immature yet, we are lacking some functionalities like dry-running or events. Relevant places in code are marked with the corresponding issues in drink repository. We'll fix them in the near future.Notes:
flipperthat uses new backendwasm-instrumentwithsign_extfeature because of compilation error:non-exhaustive patterns:&Instruction::SignExt(_)not coveredforcargo 1.70ActorandActorIdassociated types from backend traits: since we have to support all backends for a single test code, we always have to operate withKeypairandE::AccountIdtypesclient_utils(), I will adaptDrinkBackendto the mainErrorsoon (required some changes to drink as well)