ignite
feat: remove ignite/cli from chain dependencies list
Refers to #2658
After I opened this PR, some discussions raised about the different ways to achieve that goal, and after a tight vote [0], I chose to output the cosmoscmd code inside the chain templates, and same for openapiconsole package.
As a result, now a new chain has no dependencies to ignite/cli :partying_face:
I got some weird side effect at first, the go get command (there's a couple of them ran by ignite chain serve) automatically downgrades the sdk to v0.44. But by declaring those binaries in a new tools.go file and by using go install only (requires go>=1.7), I was able to avoid that behavior.
Remaining question: should we deprecate the pkg/cosmoscmd package ?
[0]
Deprecated PR body (before the vote)
This allows client to import only cosmoscmd and not the whole CLI codebase. The openapiconsole is also moved for the same reason.
TODO
- Merge PR in ignite/modules that adds cosmoscmd and openapiconsole
- Remove
replacedirective and use correct ignite/modules version - call
proxy.StartProxyForTunneledPeerssomewhere else (has been removed from cosmoscmd). This part is not easy because this methods relies on many packages, especiallynetworkchain. This is where a plugin system would be helpful : add hook to specific command w/o adding the dependency.
@lubtd With the circular dependency removed (spn no longer depends on CLI), I'm wondering if there's still an issue actually.
From what I know, the origin of this was the difficulty of upgrading the cosmos-sdk version in a chain with the CLI dependency. Since CLI depends on spn, and spn depends(ed) on an older CLI, the go command had some difficulties to select the correct cosmos-sdk version.
If the goal here is to allow a chain to upgrade its sdk version only by changing one line in its go.mod, I'm affraid it won't be possible, even if we move cosmoscmd in a different repository. Indeed cosmoscmd depends also on the sdk, so to upgrade the sdk properly, the chain maintainer will also have to upgrade cosmoscmd.
If we keep everything in CLI, like today, the upgrade may only consist of changing the sdk and the CLI version in the chain's go.mod.
Maybe I'm wrong but I try to not add complexity if the problem is already solved.
Sorry for thinking aloud, but maybe what we should avoid is indirect dependency that depends on the sdk, because in that case we may reproduce the problem we had with the circular dependency.
Typically, the spn dependency should not be present in the chain's go.mod. That may still worth the effort to remove that.
The main reason for separating into modules is because all scaffolded chains are currently importing the entire cli repo, but only use a small amount of the code. It can take us a while to release major updates to cli, so chains can still have problems upgrading (like we found with v0.46.x). If we support these smaller pkg modules, we will be able to update them at a faster cadence and allow downstream users to upgrade their SDK quicker.
We updated the cosmoscmd package over 2 weeks ago to give it SDK v0.46.0 compliance, but have still not released a new cli version
I've just discovered that a dependency to ignite/cli is added when you scaffold an ibc module, work in progress!
cosmosibckeeper removed here https://github.com/ignite/cli/pull/2803/commits/2d8b639b574ad52ebfd64928d0f3d5520976135d
We might also want to deprecate that package.
There's still a problem with one integration test, during the TestIBCOrable test, a go get github.com/bandprotocol/[email protected] is done and as before that triggers a downgrade of the sdk to 0.44. I really need to figure this out.
There's still a problem with one integration test, during the
TestIBCOrabletest, ago get github.com/bandprotocol/[email protected]is done and as before that triggers a downgrade of the sdk to 0.44. I really need to figure this out.
Solved by 6662e05