Move ignite network commands to a plugin

[aljo242]

Moving ignite network commands to a plugin will simplify the baked dependencies of CLI by effectively removing the dep on spn in the main repo. This will then remove the dependencies on:

• spn
• tendermint/fundraising
• ignite/modules

We should still include this functionality into ignite by default, perhaps adding it into the default plugins of all scaffolded chains in the config.yml.

[aljo242]

@tbruyelle do you think this is feasible?

[tbruyelle]

This is totally doable, but we need to think about 2 major issues related to the current status of the plugin system :

1. network command won't be available any more, you will need to declare its path in the config.yaml of a chain to use it (that also means outside of a chain, the command won't be available at all).

2. update of ignite won't automatically update the network plugin any more.

We need to think about how to fix/mitigate those issues.

For 1), we need to work on #3132, which implies to declare plugins in something like .ignite/plugins.yml . With that, the command can be available outside of a chain.

But we can go further since it's a trusted ignite plugin. My idea is to keep the ignite network command available at any time, even if the plugin is not declared anywhere. The first time the user runs ignite network, the plugin is fetched, compiled and executed. The workflow in the code will be a bit different than untrusted plugins, but this will definitively mitigate 1).

With this kind of setup, we can also mitigate 2) by writing in the code the version of the network plugin that must be fetched.

The other benefit is it doesn't break the user habits, network command stays available, even if it became a plugin.

WDYT?

[aljo242]

Yes, this makes sense to me. What is the status of #3132? I can start on it

[tbruyelle]

Yes, this makes sense to me. What is the status of #3132? I can start on it

Status TODO, you can work on it :)

[tbruyelle]

After discussion, we decided to make the network command always available in the CLI (even if the plugin is not declared). When invoked, user is prompted if he wants to dl the plugin. The plugin is then registered in the .ignite/plugins.yml.

[lumtis]

After discussion, we decided to make the network command always available in the CLI (even if the plugin is not declared). When invoked, user is prompted if he wants to dl the plugin. The plugin is then registered in the .ignite/plugins.yml.

We could have the same prompt for every plugin defined in https://github.com/ignite/awesome

[tbruyelle]

We could have the same prompt for every plugin defined in https://github.com/ignite/awesome

Interesting, the repo acts as a trusted plugin list. What I'm unsure is having to request this list each time we run ignite, we may have to restrict it to some cases.

[tbruyelle]

I'm currently facing an issue with the network dependency we have in scaffolded chains due to the appd start-with-tunneling command. The related method is network.StartProxyForTunneledPeers

By moving the network code into a plugin, we need to update/change that dependency as well :

1. update dependency from cli/ignite/services/network to cli-plugin-network/network, easiest but ugliest solution
2. ???

The main issue is that StartProxyForTunneledPeers depends on networkchain.GetSPNConfig so it makes not a lot of sense to move it to a separate repo because the dependency with the network code will persist.