Global plugin support

[tbruyelle]

Currently the plugins must be declared in the config.yml of a chain, which means that outside of a chain, it's not possible to use any plugins.

This is a constraint we have to tackle to make the plugin system usable outside of a chain. Typically useful if we consider moving the network command in a separate plugin.

Thus, semantically, there will be global plugins and chain plugins. Not sure yet if this needs to be specified in the manifest of the plugin, but that's definitively needs investigation.

One way to do this is to allow to declare plugins in a config file inside the .ignite folder. But for trusted plugins (like network command), we probably want to make this process more transparent, that means making the network command available regardless of the configuration.

Considering #3131, ignite plugin add command would need a --global flag telling that the plugin have to be installed globally (unless this global/chain plugin property is defined in the manifest of the plugin).

[fadeev]

It kind of reminds me of npm where you have libraries and programs defined in package.json installed locally and you also can install programs globally with npm install -g.

[joshLong145]

would it make sense to create a skeleton config.yaml in $HOME/.ignite which would hold plugin declarations. if done this way plugin interfaces won't have to change and it would be a an operation added to loadPlugins this would require a skeleton chain to be created from the root level config file which plugins could be loaded from. this could also just be a plugin config file at the root which can be loaded before scoped plugins are loaded.

[tbruyelle]

@joshLong145 we discussed internally and we are going to have separate files to declare the plugins. The current declaration of plugins inside the chain config.yml creates issues with how our config versioning system, and in addition having a chain config file in .ignite folder makes no sense. So it will end up with a plugins.yml file, both in .ignite and chain folder, which is more consistent.

[tbruyelle]

@aljo242 This just came to my mind: one complicated thing to handle with this dual plugin declaration is duplicates.

If the same plugin is declared globally and in-chain, but with a different version, I think the chain should prevails, but that also means we have to write the code responsible for checking that the plugin version is the expected one.

That's something important but can be done at the end or eventually in an other PR.

[aljo242]

@aljo242 This just came to my mind: one complicated thing to handle with this dual plugin declaration is duplicates.

If the same plugin is declared globally and in-chain, but with a different version, I think the chain should prevails, but that also means we have to write the code responsible for checking that the plugin version is the expected one.

That's something important but can be done at the end or eventually in an other PR.

Great point