ADR02: atomkraft init

[rnbguy]

Closes #11

Rendered version

[ivan-gavran]

This looks good to me. (And, importantly, sufficiently basic for our scope of an early prototype.)

[andrey-kuprianov]

I very much like the idea of treating Atomkraft as the tool that creates its own testing projects, and the init command that initializes those projects. This on the one hand feels very natural, and on the other should give us enough control over our environment to store the configuration and files, and have easy access to them from the tool in the exactly known locations.

What we need to do, is to design a "map", describing where and how everything is located in the project. Let's discuss this in a synchronous meeting.

[rnbguy]

Here is my idea of project structure

+- .atomkraft/
+- models/
+- traces/
+- reactors/
+- tests
|  +- test_authz.py
|  +- test_gov.py
+- reports/
+- testnet
|  +- config
|  |  +- app.toml
|  |  +- config.toml
|  |  +- genesis.json
|  +- run
|     +- validator-1/
|     +- validator-2/
|     +- validator-3/
+- pyproject.toml

[andrey-kuprianov]

When I type atomkraft run trace1.itf
Atomkraft has to pick up the reactor somewhere which to apply to run the trace.
For that, when the user was running the atomkraft reactor ... before, the name of that reactor should be saved in the Atomkraft config.

[ivan-gavran]

@rnbguy , once we finalize the project structure, it would be cool to modify the cosmwasm example to reflect the structure. I tried to do it, but struggled because of lack of understanding of how pytest work (so, separating reactors and tests resulted in pytest not being able to find some fixtures)

[rnbguy]

Yes, I expected this. The @step() decorated methods are fixtures that are supposed to go to a file called conftest.py.

With our current project structure, I probably have to modify pytest stack to make it work.

Or somehow keep @step() decorated methods as normal methods. I will think about it.