GitHub source with versions named differently than conda

[djsutherland]

For example, for conda-forge/staged-recipes#5790 for LAMMPS, which uses tags like stable_16Mar2018, but of course we want 2018.03.16 for conda. I'd also expect that a lot of repos use e.g. a v1.5.3 tag for version 1.5.3.

It's easy to write some Jinja to convert in either direction, but it seems that the bot expects the source to return versions in the same format as the package/version key. There should be some kind of key to add to the meta.yaml to instruct the bot how to to convert git version tags to conda version numbers.

[CJ-Wright]

One approach for this could be to include it in the bot scripts in each feedstock (xref: #93), the idea being that the script would customize the regex replacement and modifications of the recipe during the PR step.

[isuruf]

Another approach is to replace the current version with the new version in the original text and then run through the Jinja parser to get the new source url.

[CJ-Wright]

@isuruf I think this is what we currently do: https://github.com/regro/cf-scripts/blob/master/03-auto_tick.xsh#L180

I think @dougalsutherland's point is that if the version formatting conda puts out doesn't match the version formatting that the upstream puts out then the bot will most likely replace the conda version with the upstream version, which may not match our formatting requirements.

This most likely requires a) the bot to be aware how to do the translation from upstream to conda version formats for every potential recipe, b) allow users to write code for the bot to execute which performs the translation or c) perform the translation via jinja2 templating magic (there may be more options that I'm missing).

Note that we do c) in some R recipes which have the _ syntax in their versions (not that the bot understands this properly yet, due to using the the python version parser).

We might also want to put out a standard/some advice as to if the version jinja variable should be what the upstream puts out or the conda version. This should help to standardize the jinja magic if we decide to go that route. I think life should be easier for the bot if the variable was the upstream version with magic turning it into the conda version as needed. (However, making life easy for the bot should be the least of our concerns compared with ease of use for maintainers(

[isuruf]

I think @dougalsutherland's point is that if the version formatting conda puts out doesn't match the version formatting that the upstream puts out then the bot will most likely replace the conda version with the upstream version, which may not match our formatting requirements.

Right. Github source would give the stable_ version. RawURL does give out the version conda format.

[CJ-Wright]

Now I understand your point @isuruf (sorry it took me a while). During 02 we can, after checking for a non conda format, launder the version from upstream (which could be in a rather nasty format) through the meta.yaml and read the upstream version from the newly rendered meta.yaml. This would allow us to take advantage of the format wrangling being done in the meta.yaml to have a properly formatted upstream version to compare against our current version.

Do we have something which says if a version string is in the needed conda format?