Is your feature request related to a problem? Please describe.
The following proposal would help improve the developer experience and lower the entry barrier to using devmode as a quick and handy tool for building on aeternity.
As the primary way to configure devmode will remain a config file plus some clunky CLI commands automatically derived from the schema, a wrapper would be useful that makes spawning a devmode instance fast an easy (both programatically and CLI)
Describe the solution you'd like
In the Ethereum universe, the pendant of our devmode counterpart has around 7 years of learnings implemented. For having a good developer experience with reach features, this is a good starting point.
In both CLI and programmatic usage, basic inputs should spawn a chain with the requested parameters. In both cases, launching devmode should give you all you need to know to get going, here is what the terminal output looks like for the ganache cli, the same information is available somehow in programmatic usage, too, afaik:
All available configuration options can be passed as flags in ganache. In our case, the automatically generated flag options look like DEVMODE__PREFUNDED__GEN__QUANTITY=10 , which is not convenient to type. The wrapper of aeproject would wrap the cumbersome settings' names of the config file and provide a simple input like Ganache does, for example:
aeproject devmode -a 10 -b 1000000 -w '/foo/bar' -d
to quickly create 10 accounts with a balance of 1000000 and have devmode put the DB for this one into foo/bar and have it run detached.
Describe alternatives you've considered
The alternative would be using devmode with manually configured config files, which does not practically work for docker scenarios. Then you are left with cumbersome configuration flags which you need to copy-paste and adjust accordingly, leaving much room for errors.
Additional context
I am not very opinionated about the programatic implementation of all this, which should of course be as simple and easy to use as the CLI approach I've described before.
Is your feature request related to a problem? Please describe. The following proposal would help improve the developer experience and lower the entry barrier to using
devmode
as a quick and handy tool for building on aeternity.As the primary way to configure
devmode
will remain a config file plus some clunky CLI commands automatically derived from the schema, a wrapper would be useful that makes spawning a devmode instance fast an easy (both programatically and CLI)Describe the solution you'd like In the Ethereum universe, the pendant of our
devmode
counterpart has around 7 years of learnings implemented. For having a good developer experience with reach features, this is a good starting point.In both CLI and programmatic usage, basic inputs should spawn a chain with the requested parameters. In both cases, launching
devmode
should give you all you need to know to get going, here is what the terminal output looks like for theganache
cli, the same information is available somehow in programmatic usage, too, afaik:All available configuration options can be passed as flags in ganache. In our case, the automatically generated flag options look like
DEVMODE__PREFUNDED__GEN__QUANTITY=10
, which is not convenient to type. The wrapper of aeproject would wrap the cumbersome settings' names of the config file and provide a simple input likeGanache
does, for example:aeproject devmode -a 10 -b 1000000 -w '/foo/bar' -d
to quickly create 10 accounts with a balance of 1000000 and have devmode put the DB for this one into
foo/bar
and have it run detached.Describe alternatives you've considered The alternative would be using devmode with manually configured config files, which does not practically work for docker scenarios. Then you are left with cumbersome configuration flags which you need to copy-paste and adjust accordingly, leaving much room for errors.
Additional context I am not very opinionated about the programatic implementation of all this, which should of course be as simple and easy to use as the CLI approach I've described before.