Use real running node instead of emulation

[SkymanOne]

I think the tool has value beyond emulating pallet-contracts and minimum substrate runtime.
It would be nice to be able to use the tool with an actually running substrate node, as it simplifies interaction with the contract from the CLI (e.g. instantiation, contract calls, etc). cargo-contract forces you to specify --suri and --contract flags with every call command

[pmikolajczyk41]

thanks for creating issue @SkymanOne! there are few directions that you touched:

1. regarding specifying --suri and --contract flags for every contract-related operation, we already have some support, called Session: https://github.com/Cardinal-Cryptography/drink/blob/main/drink/src/session.rs for sure it's not the final form, but we found it already helpful
   if we are talking about not specifying such flags in real tool, then drink-cli already uses Session, so the burden is mitigated there as well

2. "beyond emulating pallet-contracts" - generally, we could use the core approach (direct interaction with runtime embedded in TestExternalities) to test any runtime features as we want - e.g. running staking simulations; however, I cannot tell how useful it would be...

3. "minimum substrate runtime" - I introduced a trait Runtime, so that one can use drink with any custom runtime, that contains some very basic functionalities; unfortunately most of the current runtimes (like the one from contracts-node) is not being published to crates.io and thus cannot be put natively here in drink library (git dependencies prevent from publishing crate)

4. "use the tool with an actually running substrate node" - I'm lost here: the whole point was to not having a node anymore... did you mean that anyway we should create a possibility to get into runtime on a running node? if so, how should it be used?

[SkymanOne]

What I am saying is the fact that you can have a session in CLI with multiple contracts, selecting a specific contract in the menu and making a call to it is also useful when working with the running node.

did you mean that anyway we should create a possibility to get into runtime on a running node?

No, this is not what I meant. I understand that you can not manually advance blocks in running node, so I think you can limit functionality to just displaying the current block in this case.

Overall, my point here is that the TUI you have can be useful when testing contracts on the local testnet.

[deuszx]

What I am saying is the fact that you can have a session in CLI with multiple contracts, selecting a specific contract in the menu and making a call to it is also useful when working with the running node.

ContractsUI does it already with far better UX.

If we were to add that feature (i.e. support talking to an actual node) this little tool becomes much more involved as it'd require adding RPC client etc.

[SkymanOne]

Yes, but that’s an argument for every TUI

[SkymanOne]

I guess where I am getting at is that it would be cool to have Drink TUI as a TUI wrapper for the cargo-contract. I agree that it is too much work to change the drink's core API and implement RPC client, but cargo-contract already does all of that, so maybe the only thing that is missing is the notion of sessions.