MAINT: update dependencies

[misialq]

No description provided.

[ebolyen]

Probably related to this issue:

Our CI system is breaking on integrating q2-assembly into a distribution as it is recognizing it as a "pypi" package. This is actually an error in conda, but it is produced by a rather subtle situation. The current recipe is actually redistributing quast but it isn't a part of the conda-package per-se.

So when conda goes looking back through it notices that there are multiple "python anchor files" (pretty sure that's just a convenient term for egg-info/dist-info/metadata). In this case, it picks up quast first:

DEBUG conda.core.prefix_data:_load_single_record(172): loading prefix record /home/evan/.conda/envs/q2-assembly/conda-meta/q2-assembly-2022.4.0.dev0+3.gd88013e.dirty-0.json
INFO conda.core.prefix_data:get_conda_anchor_files_and_records(367): Package qiime2/2022.4/staged/community/linux-64::q2-assembly-2022.4.0.dev0+3.gd88013e.dirty-0 has multiple python anchor files.
  Using lib/python3.8/site-packages/quast-5.1.0rc1.dist-info/RECORD

And deduces that must be from pypi (it isn't really... but pypi is the fallback for any situation conda doesn't recognize) and since that is the first "anchor file" (because "qu" < "q2") it must be the representative anchor for q2-assembly.

The final result being when we create an environment from the metapackage, this same logic occurs and then attempts to install from a non-existent channel.

Looks like there's been a recent release of quast so this is potentially solved by that, although it sounds like there may be some changes to the alignment results.

[misialq]

Hey @ebolyen, thanks again for looking into that! A follow-up question: does this mean that this situation can basically happen whenever we have any pip dependency included during the conda build, so for example here: https://github.com/bokulich-lab/q2-moshpit/blob/e2b8e67c4d680c342ce4f31c214b8e64624d3aa6/Makefile#L18-L21 ? Or is there something more that I'm missing?