Hello,
The Qiime2 Library portal started a while ago is a great source for plugins outside the q2 core distribution. Since I am teaching biology classes in q2, I forward students to the library portal in order to install plugins.
However, it seems that there are a few issues there. Some plugins cannot be added to the most recent q2 core distribution and/or miniconda3 version (e.g. qurro: pandas issue) or are still recommended to be used with previous versions (e.g. Picrust2 with q2-2021.2).
One solution to the versions issue is to use the latest q2 distribution and to switch back to previous versions, if a particular step depends on it. E.g. to do all analyses in 2021.11 and to switch to 2021.2 if it comes to qurro or picrust2 analyses, and then to switch forward again. Do you see any probelms arising with this (e.g. incompatibilities of qza, qzv data), or could this be a workaround as long as the external plugins are not updated to be compatible with the most recent q2 version?
Great question, @ARW!
Generally speaking, yes. Your approach should work just fine, and toggling back and forth between two conda environments, while clunky, is unlikely to present problems with interoperability.
The long answer:
QIIME 2 attempts to prevent the issues you raise with its semantic type system. Rather than specifying, for example, the format of some data in memory, semantic types allow us to control whether some data is useable based on its meaning. A FeatureTable[PresenceAbsence] may not be appropriate for use with some diversity calculations that are totally OK for a FeatureTable[Frequency]. They both look like tables of integers, but they mean different things.
It should be possible to pass an object of some type into any QIIME 2 Action that accepts that type and get good results, even across different versions of QIIME 2. In your example, assuming that qurro and picrust2 are configured to work properly in a 2021.2 environment, and you give them data of a type that they understand, there should be no issues.
The QIIME 2 team works pretty hard to design and implement types that are meaningful and will retain meaning over time, but semantic types and their associated data formats can be defined by any plugin, so there's no guarantee of type stability. It's hypothetically possible that changes in how developers implement the meaning or structure of some data type over time could break this, but that would be a Pretty Big Deal - the kind of thing that would manifest in the changelog, library documentation, and big scary callout-boxes if it was a serious issue.
As always, bugs happen, so take the time to get to know the software you use, use software you trust, and don't be shy about providing feedback to the developers if something doesn't feel right.
- the kind of thing that would manifest in the changelog, library documentation, and big scary callout-boxes if it was a serious issue.