richardpringle
commented
7 months ago Before we start working on this issue, there are a couple of things to discuss.
Should the simulator be ephemeral, or should it be long-lived? Depending on how difficult it is to spin up a local Hyper(Chain|VM), I prefer that the simulator be ephemeral.
Ideally, the simulator would have a single API, meaning the CLI should use the same GRPC interface. That means that the simulator code used by the wasmlanche-sdk can spin up and tear down the GRPC server, AND the cli-client lives in the same crate (migrating the interface to Rust). IMO, this is the easiest way to maintain the simulator. When the protos are updated, the test-client has to be updated along with the cli; features will never land in one place before the other.
That brings me to another question: do we even need a CLI for the simulator? <- we will have to see, I think it's too early to tell at this point.
github-actions[bot]
Currently, the Rust simulator client uses the simulator as a command line tool and parses JSON from the simulator's stdout. This isn't ideal if we want to log anything other than JSON output from the simulator while debugging and extending it. I'm open to ideas other than GRPC, but I think that would be the most convenient way to interop between a Go tool and the Rust tooling. The types for communication can simply be defined once with protobufs and the Go and Rust code can be generated from there. Right now, the interface (JSON) is all duplicated in both Rust and Go.
Further, the ideal way to use the simulator is actually to write your tests in Rust directly alongside your program. Would it make more sense to just wrap the simulator code into a Rust library such that a separate binary doesn't need to be executed? One should just be able to run
cargo testand get everything they need.