cli
cli copied to clipboard
ignite
consider removing cosmoscmd
The circular dependency caused by chains importing ignite-cli (for cosmoscmd) and ignite-cli importing spn is the main trouble point with this upgrade to newer SDK versions with lots of API-breaking changes. To solve this currently, I have a small repo that only contains the cosmoscmd code that I can use as a temporary fix to break this import loop.
Real solutions going forward would be:
- Maintaining our own separate repo
- Generating this code directly into newly scaffolded chain projects
- Finding another existing, well-maintained module that provides similar functionality. I do not know of anywhere where this exists. Most chains that do not have the
cosmoscmddependency just include the functionality in their code itself.
- Generating this code directly into newly scaffolded chain projects
This is the old behavior and this is what we had in mind
I agree that the process of upgrading chains is needlessly difficult when we have dependencies on Ignite and SPN in the chain's source code. That being said, dumping 600 lines of code that is almost identical between chains seems like a huge step back.
I think most of those 600 lines of code should be abstracted into a package that is used in main.go. This package, however, should live in Cosmos SDK repo, so it's kept up-to-date with the framework.
I would love for this to be the first topic in our resumed community calls.
I agree that the process of upgrading chains is needlessly difficult when we have dependencies on Ignite and SPN in the chain's source code. That being said, dumping 600 lines of code that is almost identical between chains seems like a huge step back.
I think most of those 600 lines of code should be abstracted into a package that is used in
main.go. This package, however, should live in Cosmos SDK repo, so it's kept up-to-date with the framework.I would love for this to be the first topic in our resumed community calls.
Yes, there is some room for abstraction I think.
Only the add-genesis-account command takes lot of lines of code and most of the time is not customized (some exceptions like evmos) this is the perfect example of something we could provide but the developer can easily replace
@lubtd also, the query cmd namespace.
func queryCommand() *cobra.Command {
cmd := &cobra.Command{
Use: "query",
Aliases: []string{"q"},
Short: "Querying subcommands",
DisableFlagParsing: true,
SuggestionsMinimumDistance: 2,
RunE: client.ValidateCmd,
}
cmd.AddCommand(
authcmd.GetAccountCmd(),
rpc.ValidatorCommand(),
rpc.BlockCommand(),
authcmd.QueryTxsByEventsCmd(),
authcmd.QueryTxCmd(),
)
app.ModuleBasics.AddQueryCommands(cmd)
cmd.PersistentFlags().String(flags.FlagChainID, "", "The network chain ID")
return cmd
}
The only dependency it has on the custom chain is app.ModuleBasics.AddQueryCommands(cmd). If you pass app as an argument, the whole namespace can be wrapped into a single line, for example.
After we have an open discussion about this, maybe we can first remove cosmoscmd, then try to add a package to Cosmos SDK repo that could abstract the hairy bits of cmd while still giving devs an option to overwrite the commands.
As a side node, in cosmoscmd we have a custom logic that optionally enables HTTP tunneling on Gitpod to allow connections to Tendermint RPC when you start your chain with appd start.
I suggest we wrap and move this functionality to another package to be placed under pkg/ and use it in our templates.
As a side node, in cosmoscmd we have a custom logic that optionally enables HTTP tunneling on Gitpod to allow connections to Tendermint RPC when you start your chain with
appd start.I suggest we wrap and move this functionality to another package to be placed under
pkg/and use it in our templates.
I would add this is required to make a standalone cosmoscmd because this part has many dependencies to ignite/cli/pkg.
What a binary essentially has is a top-level list of commands. Most of these commands are exactly the same between chains, however, leaving an option for a developer to overwrite commands is a must.
add-genesis-account Add a genesis account to genesis.json
collect-gentxs Collect genesis txs and output a genesis.json file
config Create or query an application CLI configuration file
debug Tool for helping with debugging your application
export Export state to JSON
gentx Generate a genesis tx carrying a self delegation
help Help about any command
init Initialize private validator, p2p, genesis, and application configuration files
keys Manage your application's keys
query Querying subcommands
rollback rollback cosmos-sdk and tendermint state by one height
start Run the full node
...
I see no reason why main couldn't look something like this (pseudo-code):
func main() {
rootCmd := &cobra.Command{
Use: version.AppName,
Short: "My chain",
// ...
}
rootCmd.AddCommand(
addGenesisAccountCmd(),
collectGentxsCmd(),
configCmd(),
debugCmd(),
// ...
)
svrcmd.Execute(rootCmd, app.DefaultNodeHome)
}
All these whateverCmd() commands will be in the Cosmos SDK repo and in sync with the latest version. It's trivial to replace commands, we can have appd ignite-start imported from ignite/cli and mounted alongside appd start.