Support uninstalling plugins outside of KPM

[pierre]

If the operator rm -rf a plugin, the sha1 and identifiers files will still contain entries. They should be cleaned up instead.

[andrenpaes]

When should this clean up happen? When running kpm install again?

If so, there are a few scenarios that come to my mind:

• Deleted plugin is still declared in the kpm.yml file

  • In this case we want the plugin re-installed?
  • Right now, in this scenario, kpm raises an error

  I, [2016-03-21T17:48:53.283254 #5387]  INFO -- :   Skipping installation of org.kill-bill.billing:killbill-profiles-killbill:war:0.17.0.ha-20160203.045246-48 to killbill-profiles-killbill-0.17.0.ha-20160203.045246-48.war, file already exists
  I, [2016-03-21T17:48:56.706732 #5387]  INFO -- :   Skipping installation of org.kill-bill.billing.plugin.java:adyen-plugin:jar:0.3.1-20160302.014606-32 to plugins/java/adyen-plugin/0.3.1-20160302.014606-32/adyen-plugin-0.3.1-20160302.014606-32.jar, file already exists
  No such file or directory @ sys_fail2 - (plugins/java/adyen-plugin/0.3.1-20160302.014606-32, plugins/java/adyen-plugin/SET_DEFAULT)
  

• Deleted plugin has been removed from the kpm.yml file

  • This seems to be the case where the sha and plugin_identifiers.json file should be updated
  • Maybe related to Installation that skip entries should be made more resilient #16

• A derivation of both scenarios would be the plugin still exists in the fs, but is not declared in kpm.yml anymore

  • Should the artifact be deleted in this case? while also updating the sha1 and plugin_identifiers files?

[sbrossie]

I think originally the task was to provide a new KPM 'verb' (maybe kpm clean) to remove both the plugin code/binary and cleanup the static files plugin_identifiers.json and sha1.yml. There is a question though on what to use to specify the plugin: Should it use the plugin_name or the plugin_key or both?

Additionally, KPM should at least warn about some of those inconsistent states mentioned by Andre above when they are detected. The question remains on whether we should go one step further and do some cleanup in those scenario (but that seems dangerous to me as we don't know if we should remove the remaining pieces or on the contrary fix things).

@pierre thoughts?

[pierre]

Some thoughts:

Deleted plugin is still declared in the kpm.yml file

IMHO kpm install should be idempotent, hence cleanup and fix discrepancies (i.e. re-install the plugin, cleaning up identifiers files).

Deleted plugin has been removed from the kpm.yml file

Similarly, I would cleanup the local files.

The plugin still exists in the fs, but is not declared in kpm.yml anymore

I would disable the plugin in that case (i.e. uninstall), which won't touch the filesystem, so should be safe.

[sbrossie]

Modification for existing commands

• kpm install
  • The set of plugins in the kpm.yml should be installed on success. On error, should print what went wrong and return a non 0 status. No attempt to undo what was successfully installed
  • Should be idempotent and clean files (plugin_identifiers.json, sha1.yml ) as needed
  • If there were existing installed plugins (not in the kpm.yml they get uninstalled, that is they stay on the file system but with the disabled.txt link)
• kpm pull
  • Same things but just for this specific plugin

New commands

• kpm uninstall <plugin_name>|<plugin_key>
  • Set disabled.txt link (and does not touch plugin_identifiers.json, sha1.yml unless they are corrupted in which case it fixes them)
  • Additional option to the command to remove entry from file system and cleanup files plugin_identifiers.json, sha1.yml

[sbrossie]

Note that i recently implement a new verb inspect to display the current state:

The flow of operations would then be:

1. User can use kpm inspect to display current state (and visualize things that are broken if any)
2. User can decide to remove such broken plugin using the command listed above kpm uninstall <plugin_name>|<plugin_key>. However, to make it both simple and useful:
3. The new verb uninstall remove everything (cleanup plugin_identifiers.json, sha1.yml and remove binary from file system. No soft uninstall using disabled.txt.
4. uninstall should allow to remove all entries for a specific plugin or also target a specific plugin version