Define a Strategy for Implementing Modules

ryan commented

2024-11-22 21:28:05 +00:00

Owner

if we use ::<CommandFactory>::command() which is implied by Parser in clap --features derive we can add an automatable, per-coin test suite to check whether each command supports the transfer <amount> <to-address> --from-account [account] format that needs to be shared by all coins.

The builder is turning out to be a bit of a nightmare. For some reason, my value parsers aren't working, and the entire thing is a .unwrap() headache.

Plus, this means making things oneshot will be easier at the risk of the tiniest amount of DRY.

if we use `::<CommandFactory>::command()` which is implied by Parser in `clap --features derive` we can add an automatable, per-coin test suite to check whether each command supports the `transfer <amount> <to-address> --from-account [account]` format that needs to be shared by all coins. The builder is turning out to be a bit of a nightmare. For some reason, my value parsers aren't working, and the entire thing is a `.unwrap()` headache. Plus, this means making things oneshot will be easier at the risk of the tiniest amount of DRY.

ryan added this to the Custody Framework project 2024-11-22 21:28:18 +00:00

ryan commented

2024-11-24 23:14:39 +00:00

Author

Owner

Closing in favor of RPC format proposed in #9

ryan closed this issue

2024-11-24 23:14:40 +00:00

ryan changed title from ~~Move from Clap Builder to Clap Derive~~ to Define a Strategy for Implementing Modules

2024-11-24 23:29:47 +00:00

ryan commented

2024-11-24 23:30:37 +00:00

Author

Owner

Repurposing this issue for the module implementation strategy, since the overall goal was to be able to say "here's how we define a standard coin". Coins are implemented using the JSON RPC format being defined in #9.

ryan added this to the Icepick v0.1.0 milestone 2024-12-12 20:34:03 +00:00

Define a Strategy for Implementing Modules #8