Apply osmosis style

[faddat]

hi, could you guys please have a go at:

• applying the osmosis app.go style & folder structure here
• putting an osmosis-style upgrade template folders -- let's say two of them, with commented out text and example code here
• loading this into tinyport as a template
• test the tinyport template - the first template is called 46-cw
• take cosmwasm out of 46-cw, but keep everything else, and call that 46
• update the current template in tinyport to the latest versions for sdk 0.45.*, and to the osmosis app / upgrade folder style
• make a template for 0.45.*
• submit tinyport to the cosmos-sdk, in the folder template -- if you can think of a better name all the better. Just keep the templating features, and maybe the serve feature.

So we'd end up with 5 work products:

• Tinyport (or whatever we call it but let's not call it a scaffolding tool that name is cursed)

• SDK 46, ibc v3, CW template

• sdk 46, ibc v3 template

• sdk 45, ibc v3 + CW template

• sdk 45, ibc v3 template

Why?

Well, the primary lesson I got from craft so far is that integration testing isn't really happening between libraries in cosmos. But it's cool I think it's been a really great way to learn the relationships between things. When we started using 46, that was speculative.

but I ran

craftd testnet start --enable-logging

and saw months being saved....

So then we:

• upgraded ibc-go to support sdk 46
• upgraded cosmwasm to support sdk46
• (khanh I'll giv eyou edit on this issue-- you did some integration work here and you should describe it)

what kind of integration testing is needed?

• cosmwasm + mainline sdk
• IBC-go + mainline sdk
• mainline sdk + cw + IBC-go

Basically we need to test against IBC-go even if it no longer lives in the cosmos-sdk repo, and same for cosmwasm.

what else will this do?

I loved starport. But then spm and cosmoscmd broke maintenance, and frankly it’s too many features.

SDK repo contains simapp, but that isn’t a template. This is a templating solution for the cosmos sdk that we can maintain for:

• the prior version
• the tip of the repo

this way, we can notice and understand breaking changes in ci before people try to build with the code.

[faddat]

This seems completed in spades. Thank you @vuong177