Investigate `cargo-generate` and other tools/patterns to improve DevEx experience for newcomers

[neysofu]

Is your feature request related to a problem? Please describe. Our DevEx paradigm is mostly centered around cloning this repository, reading through the READMEs, running demo-rollup, and then making modifications as necessary. This works, but it doesn't necessarily reflect how end users expect to interact with Rust crates and SDKs.

Here's some symptoms and smells which contribute to this issue:

• No established and mature release engineering practices. This includes GitHub releases, tags, and regular publishing to crates.io. I'd argue some of these are not yet necessary prior to 1.0, but it's good to have them as end goals.
• Over-reliance on READMEs instead of rustdoc for SDK discoverability. Both are important, respectively for tutorials and for reference documentation.
• Unclear intended usage of the SDK: should users import crates from crates.io, or clone the repository? Should they import some and locally source others which they might plan on modifying? We could also use cargo-generate and similar templating tools to facilitate hacking on demo-rollup and new modules, as proposed already by others.

Describe the solution you'd like Work on most of these items is currently underway; the codebase is becoming increasingly production-ready over time and we've somewhat agreed on release cadences and processes. This issue is intended to track these efforts and discuss new strategies if necessary.

[citizen-stig]

I think is important issue!

[LiveDuo]

We been experimenting with https://github.com/Sovereign-Labs/sovereign-sdk over the last few days and I thought sharing our experience as it touches exactly on this issue.

In short:

1. The tutorial in Celestia summit ie. Sovereign SDK workshop was a great way to get us started over the codebase and how different components fit together.
2. There's a problem with the size of the codebase. At least it was initially, before we look into the specifics, our concern was that we might get lost (eventually it was a more pleasant experience than Cosmos SDK but at first it felt intimidating). Having a starter project either through cargo-generate or a fresh git project will surely help.
3. We found two parts of the experience non-optimal: relying on docker and calling sov-cli. The issue with docker is that it's resource heavy and especially in combination to rust analyzer compiling sov_modules_api. We look forward to https://github.com/Sovereign-Labs/sovereign-sdk/issues/585 or similar solving the issue. The sov-cli package had no simple method to submit transactions. Might be better to have something like cargo run --bin demo-cli submit-transaction keys/token_deployer_key.json DemoModule "{ \"UpdateName\": { \"name\": \"gm\" } }" 0 http://127.0.0.1:12345. Eventually we implemented this ourselves but it could help anyone learning the SDK to have such command in place.

PS: Here's our starter project sovereign-sdk-starter.

[bkolad]

@LiveDuo, thank you for providing us with the feedback. We will take it into account in our planning. The #585 will be available in the next few days, so the docker won't be needed.

[LiveDuo]

@bkolad Glad! Looking forward to https://github.com/Sovereign-Labs/sovereign-sdk/issues/585.