Jinja not supported

[jakirkham]

It appears that it is not valid for a recipe to use Jinja according to this code. One of our conda-forge contributors, @ngoldbaum, pointed this out to us.

We find it very handy to use Jinja so that we can avoid copy-pasta with versions and the like. Thus we are able to set them in one place and use {{ version }} elsewhere. This keeps the maintenance burden on updates low. It also avoids silly mistakes like bumping the version number and using the same source. Further in light of changes to PyPI URLs, we have found ourselves needing the name to be used in Jinja templates so as to handle the current redirect URLs.

While we are using Jinja, it is hardly dynamic and a single pass of conda render can fill this out without needing to go to external source (though maybe the NumPy and/or Python versions may be needed).

Is there some reason to consider this usage unacceptable?

cc @pelson @ocefpaf @msarahan

[ilanschnell]

The usage of Jinja templates is perfectly fine. However, when we build packages for the Anaconda distribution, we use other internal tools to parse the recipes also, which do not understand Jinja templates.

[jakirkham]

I see. So, we are just misunderstanding the purpose of this tool.

To make sure I understood you correctly, this tool is intended to verify if a recipe can go through Continuum's internal build system as is. However, it is not meant as a general purpose recipe verification tool.

[ilanschnell]

Correct, the tool is there to verify if conda recipes can be used with out internal system.

The tool, or parts of it, could be used to create a conda-verify general purpose recipe verification tool (which could also be part of conda-build).

[jakirkham]

Thanks for clarifying.

Sure, I agree some parts of it like binary package verification are generally useful. I'll have to play with those parts a bit more to get a better sense of them.

[ilanschnell]

I agree. The binary package verification is actually more useful for the open source world than the recipe verification piece.

[ilanschnell]

In version 1.2.0, which I just released, a --pedantic option was added. Without this option (by default), having Jinja templates is fine.

[jakirkham]

Thanks for accommodating this use case and the extras use case. If we are moving in the direction of having this be a qualified linter that will work at conda-forge too, I think it would be worthwhile to start including this generally in our CI builds to ensure that recipes meet strict criteria and generating packages that are generally usable. We will have to play with it a bit to see if there is anything else that might cause us trouble (though I'm hoping these were the two big ones).