Decide about putting `claim` in its own repo

tendermint / spn

A blockchain to launch blockchains.

Other

112 stars 41 forks source link

Decide about putting `claim` in its own repo #899

Closed lumtis closed 2 years ago

lumtis commented 2 years ago

claim module is aimed to be imported by other projects. It may make sense to move the module to its own repo with its own docs to emphasize its independency.

Solutions:

Keep under spn
- Drawback: doesn't emphasize module independency
Minimal repository:
- Only the module repository with proto definition with no environment (no app, no simulation tests)
- Drawback: no simulation tests integrated
Chain with module imported
- Regular chain with app dir, simulation test, etc...
- Drawback: may need to reimplement testutils etc...
Repository for all independent modules we may have
- Repo named like modules that integrates modules aimed to be imported by other projects as well
- Might be the case with mint: https://github.com/tendermint/spn/issues/895
- Drawback: emphasize less on the module independency

lumtis commented 2 years ago

Let's wait upgrading everything to 0.46 before doing claim migration https://github.com/tendermint/spn/pull/906

lumtis commented 2 years ago

As we will work in several different independent modules. The idea would be to have ignite/modules with a test application inside for CI and test purposes

tbruyelle commented 2 years ago

The idea would be to have ignite/modules with a test application inside for CI and test purposes

Actually I was wondering if we can avoid integration test with custom modules. Indeed we can mock all their interactions with other modules thanks to the interfaces declared in expected_keepers.go, the other interaction I'm aware of is the KVStore, but I don't know if we can mock it.

lumtis commented 2 years ago

Maybe related to your point? https://github.com/tendermint/spn/issues/807

We use for now a package testutils/keeper for all tests where all keepers are initialized, but the idea in the future is to define mocks for every module so that tests for a single module can be isolated.

I think there is some room to define a generic test framework for SDK modules that could be located in ignite/modules and spn would use this framework

For the initial point, ignite/modules will also need a sample app to perform simulation tests with the modules