Reporting the version of a tool wrapped by a plugin

Developer Discussion
1

According to Developing a QIIME 2 plugin — QIIME 2 2023.9.2 documentation when writing a plugin, the version defined in plugin_setup.py exports the version to Qiime. We can query this at the command line:

$ qiime dada2  --version
QIIME 2 Plugin 'dada2' version 2022.8.0 (from package 'q2-dada2' version 2022.8.0)

(the repetition there is odd)

This example is from the discussion on getting version numbers for packages used in qiime2 plugins which concluded there is currently no way for a plugin author to express the versions of its dependencies, and suggested a workaround:

$ conda list | grep dada
bioconductor-dada2   1.22.0   r41h619a076_1   bioconda
q2-dada2             2022.8.0        py38_0   qiime2/label/r2022.8

The authors of the q2-dada2 plugin would know how to report the version of DADA2 determined at run time, but there doesn't seem to be a mechanism to do that and record it. I can imagine Qiime2 being extended to capture this, much like it captures citations, but that is a lot of work.

How would people feel about Qiime2 wrappers following the Galaxy wrapper versioning approach?

I'm considering setting the version returned in plugin_setup.py at run time to the underlying tool with the wrapper version as a suffix, giving something like this (or perhaps with a simple integer suffix like Galaxy recommends?):

$ qiime dada2  --version
QIIME 2 Plugin 'dada2' version 1.22.0+qiime2022.8.0 (from package 'q2-dada2' version 1.22.0+qiime2022.8.0)

(In my testing it seems the version via plugin_setup.py is assumed to be the package version, even when different from that in setup.py)

This wouldn't help with tracking secondary dependencies, but it feels like a step forward. I am of course biased coming at this with a Galaxy background :wink:

2

I mean so far we've not gone wrong by copying things that Galaxy has done (XML Tests -> Usage API, Collections -> Collections, version commands -> I suppose exactly the same?)

I think internally we've generally been of the opinion that we should be tracking conda packages in provenance in addition to the host-language's "view" (home site-dir packages and easypath packages commonly find their way into things at the worst moments).

Linking binaries to plugins does sounds nice though. Maybe both of these can happen to greater or lesser degrees?

We have a related issue of provenance wishlists items for the next time we need to bump our archive format:

1 Like
3

Gosh it's been forever since that distinction could have mattered! The first is the Plugin constructor's information, and the second is from pkg_resources to snoop on the installed python package.