BUG: set up versioningit to see Github release tags

[ebolyen]

By default unannotated tags are not considered by versioningit.

[lizgehret]

this was discussed offline and can be closed bc versions are fixed once we do an official distro release that includes said plugin(s).

[ebolyen]

What about 3rd party devs? I didn't really think this change was for our lab, and it wouldn't change q2-boots or q2-kmerizer anyhow.

[lizgehret]

Maybe I'm missing something but my understanding was that this was opened bc of boots/kmerizer versions - and you and @gregcaporaso had decided we could close this since their versions will be fixed in the upcoming release:

[ebolyen]

Sorry for the confusion, I meant that there were 2 issues:

q2-boots and q2-kmerizer don't really need any action, hence leaving them as is (and closing the Draft issue on the project board Greg opened). But any 3rd party devs are going to run into the same issue as those plugins, except they won't be in a distro release, so their versions will always be weird if they use a Github release instead of a specifically formed tag. And since Library tries to highlight github releases, it would be weird if they have those, and a version of 0.0.1+300 etc

[lizgehret]

Ah, I see. I'll need to take a closer look at this then - my understanding is that Greg ran into an issue with the listed version when running qiime info. The versions listed on library (from GH releases) do work as expected though, and the conda/python versions are correct.

[ebolyen]

ok! I think if we make a fresh templated plugin and then do a GH release (and then make a library style env file) we should see the issue. And if we don't then I don't actually know what's going on anymore.

[lizgehret]

and same question here @gregcaporaso @ebolyen (xref issues #38 & #40)

[ebolyen]

I think this change is simple and strictly benefits anyone who does use the template (and github releases which will not make annotated tags). For the broader question of how much investment we need in the first place, I'm probably in the wait-and-see camp for anything larger/pending.

[gregcaporaso]

I agree with @ebolyen's take - let's fix this one b/c it is important that it works out of the box for 3rd party devs, but wait and see on #38 and #40 as using Copier to update might not be the approach that we recommend for updating plugins anymore.

[lizgehret]

Sounds good! I'll drop the other two and work on this one next week.

[lizgehret]

Currently testing this and adding a couple of notes for additional things that need to be fixed:

• Docs on uncommenting the 'pip install' segment of the provided env files - the release automation won't work without this, but needing to do this wasn't immediately clear to me (if I'm pretending I know nothing about the set up & process)
  • EDIT: addressed by MAINT: env file updates for rachis name change & clarifying release env creation rachis-org/developing-with-qiime2#175
• Env file templates need to be updated with rachis prefix (& amplicon replaced with qiime2)
  • EDIT: addressed by MAINT: env file & distro updates for rachis name change #43

[lizgehret]

ok tested and confirmed this is all working as expected!
sorry for all the back and forth on this for a one line change 😆

i'll merge this and then update the two related items above, and then we should be in a good place to leave the plugin template as-is for now.