search

UST-QuAntiL / qhana-plugin-registry

A plugin registry for QHAna plugins
https://qhana-plugin-registry.readthedocs.io/en/latest
Apache License 2.0
0 stars 0 forks source link

Inconsistent plugin ids #27

Closed infacc closed 11 months ago

infacc commented 1 year ago

When discovering plugins the qhana-plugin-registry assigns the plugin_name to the plugin_id:

https://github.com/UST-QuAntiL/qhana-plugin-registry/blob/a77126596bffd0118c44b99c0ba5c327f8bcf4d6/qhana_plugin_registry/db/util.py#L120

Shouldn't the RAMP.plugin_id be the same as the plugin identifier from the qhana-plugin-runner, i.e. <name>@<version>?

Currently, the plugin filter implementation assumes that RAMP.plugin_id is of the form <name>@<version>. If a user specifies an id filter (#26) including @<version> but the plugin_name doesn't contain the version, the filter won't find the corresponding plugin.

Regarding the Plugin Runner

While some plugins set the plugin name to the identifier (e.g. SVM), most plugins use the name (e.g. QKE). Which value is the intended one?

buehlefs commented 1 year ago

The full plugin id is composed {plugin_name}@{plugin_version} so as to uniquely identify a single plugin (with a specific version). At least, that was the intention. Since the plugin registry stores both, the name and the version, it makes sense to not store the full id, as it can be trivially computed. (unfortunately, consistent naming is hard and what is called plugin_id in the registry is the plugin name in the plugin runner). Maybe we could add a property to ramps that computes the "full_id" including the version.

In the plugin metadata, the plugin name should not contain the version. (the QKE plugin does it correct)

infacc commented 12 months ago

I added full_id as cached_property to the RAMP class in #26.

https://github.com/UST-QuAntiL/qhana-plugin-registry/blob/ca663109f8f527a45872564aa48358d12ffa6c1b/qhana_plugin_registry/db/models/plugins.py#L91-L93