Plugin registry: should InVEST change how it keeps track of plugin IDs?

[emilyanndavis]

Both core InVEST and the Workbench keep track of currently installed plugins. While InVEST relies mainly on the plugin's model_id (e.g., using sample_plugin as a key in models.model_id_to_pyname), the Workbench also maintains version info (e.g., using sample_plugin@0_0_1 as a key in settingsStore.plugins). Although this difference sometimes requires converting a plugin ID from one form to the other, it's not a problem in and of itself. However, in the context of designing and building the plugin registry, it might be worth rethinking whether the model_id is enough for core InVEST's needs. If not, what additional information (version, tag, etc.) is needed, and what's the best way to represent that info? Should core InVEST adopt the Workbench's approach, or something different—and, if something different, should the Workbench be updated to match?

[emlys]

For some additional context: because a plugin is a python package, and only one version of a python package can exist in an environment, natcap.invest can only use one version of a plugin at a time. So the package name is enough to uniquely identify a plugin to natcap.invest.

Because the workbench manages each plugin in a separate environment, it can handle multiple versions of a plugin, hence the need to identify plugins by both their name and version on the workbench side.

For usage logging at least, it seems like natcap.invest should be aware of the version of a plugin that it's running. And I think we can easily retrieve that metadata with importlib, while still relying on the package name as a unique identifier.