Quartz CLI: Implement dev

[thanethomson]

To facilitate a really great local development experience, we would like to offer Quartz app developers a simple interface to facilitate the availability of a running instance of their app.

For example, a Quartz app developer should be able to simply run:

quartz dev

This should:

• Build the enclave if necessary (mocking SGX functionality)
• Start the enclave
• Build the contract(s) if necessary
• Deploy the contract(s) to the relevant CosmWasm chain if they were rebuilt
• If either the enclave or the contract(s) were updated, facilitate the handshake

[dangush]

If either the enclave or the contract(s) were updated, facilitate the handshake

rebuilding contracts might be undesirable since it would mean the dev losing state their state. I guess an option flag for this?

[dangush]

https://github.com/watchexec/cargo-watch

Will likely use this library

watchexec/cargo-watch#75, here's a pattern that may be very useful: you're working on a server or app, but want it to keep running while you're writing a new feature or fixing a bug, potentially causing the code not to compile anymore in the meantime.

In this case, you can use this strategy: run a first cargo watch with check, build, test, or whatever you want, and append -s 'touch .trigger (or equivalent for your platform). Then, run a second cargo watch simultaneously that only watches that .trigger file. For example:

Dev runs the two cargo watch listeners.
First listener tests for successful builds upon changes on enclave (+ contract?), if success, performs the file trigger

• building upon changes needs to be done through the cli's own commands to ensure mock-sgx and other config are passed

Second listener runs enclave start; contract deploy; cargo contract.

• this chain of calls is either encapsulated in a new command (subcommand of dev?) to provide for message passing between via their responses,
• or they are made as separate cli calls performed in series by the same cargo watch script, with message passing between calls relying on a persistent state / config

Preferably dev should contain logic for chaining together the commands and then initializing the cargo watchers if they are not already initialized. Then the cargo watch scripts deployed by dev can call just dev again

[thanethomson]

rebuilding contracts might be undesirable since it would mean the dev losing state their state. I guess an option flag for this?

They may as well just be rebuilding the contract and enclave manually with the enclave build and contract build subcommands.

We could consider adding a quartz enclave watch subcommand at a later stage that just watches for changes to the enclave, builds and reruns it, and then kicks off the handshake. This would allow devs to separate the contract build/deploy/handshake cycle from the enclave's build/start/handshake cycle.

[dangush]

Ah dang, I thought "If either the enclave or the contract(s) were updated" meant the watch functionality was minimum expectation.