fix: Update README.md

[faddat]

Description

Closes: #12211

This changes readme.md to reflect that the cosmos-sdk doesn't have a canonical templating tool.

An alternative way to close #12211 is to upgrade ignite cli so that it no longer uses cosmoscmd but it is my understanding that their team views that as undesirable to their work.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[julienrbrt]

I tend to agree, but most of (all) our tutorials on https://tutorials.cosmos.network uses Ignite CLI. We mention it here too: https://github.com/cosmos/cosmos-sdk/blob/main/docs/README.md

If we remove it, I feel like we should at least have a link to the awesome repo (https://github.com/cosmos/awesome) so people know about the existing tooling (possibly replacing the v1.cosmos.network/tools link too)

[faddat]

I agree with you about awesome.

I wouldn’t mind making it “the” scaffolding tool again either— but at present there’s this— I am really tired of taking it out of chains or experiencing the cosmoscmd effect.

[fadeev]

Ignite CLI has been updated to support IBC v3:

https://github.com/ignite-hq/cli/releases/tag/v0.22.0

Here's what it takes to update an existing chain to IBC v3:

tendermint/spn@660c6dd

It doesn't require modifying the cosmoscmd package and if your complaint is that it's hard to make the changes above then it's more of a comment on how confusing the app wiring is (which we agree with).

We also have an issue to upgrade the template to v0.46.0-beta and a community member is working on it right now (we want to encourage external contributions):

ignite/cli#2156

I apologize to the community for this constant trolling. Instead of making issues in the repo, proposing changes, and talking constructively to project maintainers, some people decide to wage war against packages they don't like and try to prove their point by screaming louder than others. This is pathetic.

[lumtis]

Here's what it takes to update an existing chain to IBC v3:
tendermint/spn@660c6dd
It doesn't require modifying the cosmoscmd package and if your complaint is that it's hard to make the changes above then it's more of a comment on how confusing the app wiring is (which we agree with).

For tendermint/spn@660c6dd it was in fact more complex in this case because we had custom logic in the handshake where we were using the channel state in the store and from V3 the channel state is no longer set before the handshake.
If you don't have custom logic in the handshake, the changes are minimal.

Upgrading to IBC v3 actually doesn't require making changes in cosmoscmd. For your chain, you must follow the migration guide https://github.com/cosmos/ibc-go/blob/main/docs/migrations/v2-to-v3.md.

[fadeev]

@julienrbrt could you maybe expand on what you "agree with", so we can discuss this in detail?

The tutorials were updated to use Ignite CLI a long time ago and for good reasons:

• The tool has helped thousands of new developers get started with Cosmos SDK and start building their projects
• We have an active Discord where we help new devs with questions
• Ignite CLI has been an indispensable tool in all Cosmos hackathons
• We have been maintaining a library of tutorials that range from introductory to advanced since 2020. (we had only 2 tutorials before)

[julienrbrt]

@julienrbrt could you maybe expand on what you "agree with", so we can discuss this in detail?

The tutorials were updated to use Ignite CLI a long time ago and for good reasons:

• The tool has helped thousands of new developers get started with Cosmos SDK and start building their projects
• We have an active Discord where we help new devs with questions
• Ignite CLI has been an indispensable tool in all Cosmos hackathons
• We have been maintaining a library of tutorials that range from introductory to advanced since 2020. (we had only 2 tutorials before)

Don't get me wrong, I am not disagreeing with any of these points. I am not suggesting either that tutorials should not use it.
I was mentioning that our onboarding documentation is using it. When adding new onboarding tutorials, we are, as well, still using Ignite CLI.

Although my point is, if users have problems or concerns with it (see the issue), as it is still a third-party tool; I don't find it bad to remove it from the README, and have an excerpt about the Cosmos SDK tooling in general (linking https://github.com/cosmos/awesome).

[fadeev]

Although my point is, if users have problems or concerns with it (see the issue), as it is still a third-party tool; I don't find it bad to remove it from the README

Mkay, solid arguments.

[faddat]

Hi Denis, here's what I am seeing from the ignite cli, in particular because of cosmoscmd:

✅ The tool has helped thousands of new developers get started with Cosmos SDK and start building their projects
❌ the tool then makes maintaining them much more difficult, once they are up and running, and a disconnection from this repository and ibc go leads to slow updates of ignite cli. <-this one
✅ We have an active Discord where we help new devs with questions
✅ Ignite CLI has been an indispensable tool in all Cosmos hackathons
✅ We have been maintaining a library of tutorials that range from introductory to advanced since 2020. (we had only 2 tutorials before)
❌ users can't build against the tip of the sdk repo, and are forced into old versions
❌ there's no starport template in the sdk, and cosmoscmd is the reason, otherwise some fella (me) would make one
❌ ignite cli blocks configuration, like embedding seeds or genesis.json itself into the chain's binary, making it easier for operators

Denis, the ignite CLI helped me to build Juno and to learn development in cosmos. This isn't about hating on ignite cli or ignite or you. Much love all around. It is instead about the path we're being forced to take cause of cosmoscmd.

Round fall of 21, I began needing to tear it out of chain after chain, and it's really painful, not highly productive work. From where I stand, there isn't a clear reason to have cosmoscmd. If you maybe feel super insistent that some things need to be abstracted, perhaps abstract smaller things, that are easier to replace. For Juno, (but not the only example by any means) we've made a decision to:

• not fork the sdk
• not fork cw

therefore

• we don't want to fork ignite cli, or spm, or cosmoscmd

we'd like Juno to be as close to a reference implementation as possible.

We'd like juno to use the latest ecosystem libraries, all the time

We would like to control juno

Most of the commentary-- right now, surrounds Juno, but dig was built with ignite, and we took it out there, too, I'm taking it out of two other projects, too. I wrote the code to take it out of chihuahua, but that never was merged.

another item

I want a template in the SDK repository. I want it free of the cosmoscmdstuff. I want it versioned with the sdk. I actually don't care if we call it an ignite template or something else. What I want is that nice "upstream" feel, and what I don't want is that "constrained" feel.

The tool itself does not need to live here.

A template does need to live here.

That is so that people (like me) can work with the latest code in the sdk so that when they're shipping a chain that'll use new features (like craft) they can actually test that code before the final release (like v0.46.0) is cut.

Please don't mistake my motivations for this PR as political. I just do not think that absent greater modularity and maintainabiilty, the ignite cli fits with the patterns here. The closest thing this repo has to a template right now is simapp. It is not a good template I'd love to see a template here, that we put through the same processes as the sdk itself.

another another item

Let's please not ignore the ibc-go v2.2.0 release notes. That's been out for some time, and they tell users, "don't use v2.0.3, there's issues." But ignite cli didn't give a choice.

[fadeev]

❌ the tool then makes maintaining them much more difficult, once they are up and running, and a disconnection from this repository and ibc go leads to slow updates of ignite cli. <-this one

There is no "disconnection" between repositories. The template has been using an older version of IBC for a while, but we've updated it since and will try to keep it up-to-date in the future. It was and still is trivial to update the version of IBC manually. (the guide is linked above). Again, we're updating the CLI to SDK v0.46.0-beta and CLI v0.21.1 already works with SDK v0.46.0-alpha1.

[faddat]

Denis, I wish to be as diplomatic as possible and appreciate the ignite cli, you, and your work.

That is nice about the newer version support but I am sure it wasn't there 6 months ago when I started to work on craft and decided we wanted groups. Please realize that I am super super open to a cosmoscmd-free template that lives in this repo. I didn't just say "let's take ignite cli out of cosmos sdk repo readme" I provided alternative paths.

Also, and please, don't take this the wrong way-- but how many ignite cli chains are you maintaining yourself?

I am very certain of what I'm saying here unfortunately.

[fadeev]

Let's please not ignore the ibc-go v2.2.0 release notes. That's been out for some time, and they tell users, "don't use v2.0.3, there's issues." But ignite cli didn't give a choice.

How is Ignite CLI not giving a choice if you can upgrade the version manually?

[faddat]

Remember 34.16 -> 34.19?

I do.....

[faddat]

Note to gentle readers:

I have been laying out a path for greater inclusion of ignite cli here, but I wish to stop using some pieces of it because they've cost significant time & money and don't suit how I figure we should build chains.

And that's the trouble: it's being made into an all or nothing affair by a single way of doing things:

cosmoscmd

[tac0turtle]

mentioned in the issue, I will close this PR. lets work together on how to move forward. If we are unable to work together then a larger conversation can be had