Ensure branches tracked by plugins are kept up to date

[aljo242]

The plugin system should track branches if the plugin is installed to with that type of reference. For example, using:

github.com/ignite/cli-plugin-network@main

should mean that the plugin is always kept up to date to follow the main branch.

If we are using:

github.com/ignite/cli-plugin-network@v1.0.0

We should not update anything since we are using a fixed tag.

A solution for this could be to always get the latest version of the plugin whenever we make a call to it. For fixed tags or commit hashes, this will always result in no changes, since the code should not change.

[tbruyelle]

We should do that only for default plugins like network I think.

[joshLong145]

External plugins declared in chain / global configurations should only update if explicitly told to do so IMO. Perhaps new commands can be added

• plugin check <plugin-path> pulls the specified branch into a temp storage location and does a diff comparison of what's in the plugin folder and what's in the temp cache. will alert if there is a diff between the two source locations if present.
• plugin update <plugin-path> checks if a plugin source needs to be updated with the above implementation. if an update is deemed needed swaps what's in temp storage with what's in the plugin cache directory. this command could also build the new binary or leave it to be built the next time the plugin is loaded.

WDYT?

[aljo242]

WDYT?

Yeah, this is probably the best approach. But as @tbruyelle said, we will want to ensure the network plugin is up to date for users.

[joshLong145]

WDYT?

Yeah, this is probably the best approach. But as @tbruyelle said, we will want to ensure the network plugin is up to date for users.

Internal plugins are different. to my understanding the network plugin is wrapped by static commands. within those implementations the plugin check implementation can be leveraged to check for updates before calling on the actual plugin implementation.

[tbruyelle]

Internal plugins are different. to my understanding the network plugin is wrapped by static commands. within those implementations the plugin check implementation can be leveraged to check for updates before calling on the actual plugin implementation.

Not fan of this plugin check command, this adds too much complexity and I'm not convinced there's a real need for this. As a comparison, there's no similar go check command, you run go get -u and you update your dependency, w/o the ability to check the changes.

That's actually the reason why we want to restrict the auto-update to trusted plugins like network.

[joshLong145]

Internal plugins are different. to my understanding the network plugin is wrapped by static commands. within those implementations the plugin check implementation can be leveraged to check for updates before calling on the actual plugin implementation.

Not fan of this plugin check command, this adds too much complexity and I'm not convinced there's a real need for this. As a comparison, there's no similar go check command, you run go get -u and you update your dependency, w/o the ability to check the changes.

That's actually the reason why we want to restrict the auto-update to trusted plugins like network.

This is true Go's package manager has not such notion of checking the state of packages. However, npm has npm outdated which will tell you which packages are out of date in your package.json to a specified depth. I see plugin check as the equivalent. perhaps the name is changed from plugin check to plugin outdated to be clearer. This implementation could then be used internally for auto updating internal plugins.

[tbruyelle]

If you ask me to choose between go and npm dependency management, the choice will be fast :)

Anyway, if you want to implement a ignite plugin outdated command, we'll probably merge it. But let's stay simple, the command would just output the list of plugins that can be updated, no need to output diff or things like that. Things can be done without having to clone the repository again in a temporary dir. You just need to compare the commit hashes between the plugin clone directory and the plugin repository.