Dev Command

[harrysolovay]

Will effectively function as serve except that it will take care of downloading dev dumps + execute docker commands + wait for db connection. Having this be managed will be important as we introduce complexities related to an additional DB + migrations (see #58).

[piotr-iohk]

If I understand the intent correctly using dev command would allow to set up the development environment from scratch. However we already have deno task dev:init that serves exactly the purpose. Why having this duplicated as the user facing command also?

[harrysolovay]

The dev script requires that users clone the repo and use Deno (which not be a dependency for non-contributors). The happy path is cargo install mina_mesh followed by running mina-mesh dev.

[piotr-iohk]

The dev script requires that users clone the repo and use Deno (which not be a dependency for non-contributors).

Good point about the dependency scope, however isn't the dev env required mainly for contributors? Dev env is basically just a postgres database with some archive dump, but for the mesh to work properly we need a bit more than that, i.e. working archive node + db + mainnet/devnet node + graphql. I think that for setting up the dev env it is sensible to use some task/procedure that is not the part of the mesh tool (as we have it with deno), however having this as a separate command in the tool feels a bit less necessary.

The happy path is cargo install mina_mesh followed by running mina-mesh dev.

I think at some point we will need to package mina-mesh with all the dependencies that it needs, perhaps even adding rosetta there as well in the interim (until we achieve feature parity with rosetta). I think that docker image or a docker-compose would be strong choice for that since all the dependencies are already packages as docker images.

[harrysolovay]

You make a really good point @piotr-iohk –– closing now.