Conda-build: load_setup_py_data/custom variable acts strangely in conda build 3

[ebolyen]

Hello, I've been trying to debug this for a bit, but I'm afraid I've gotten stuck.

Some background:
We store our recipe in the repo we're trying to build and we use versioneer to version everything. We've got a notion of a "release train" where every package in our system is in lock-step. To make our lives easier we use load_setup_py_data in our template and just place that version (or a release) wherever it is needed.

However, with conda build 3 we're seeing the following on both linux and os-x:

Undefined Jinja2 variables remain (['get', 'get']).  Please enable source downloading and try again.

full log on our Concourse CI instance here

This happens during the test phase of the build. What is kind of irritating is that when you look at the built conda package, the rendered meta.yaml file looks fine, no Jinja2 variables are found anywhere and they've all been resolved to the correct strings.

When I remove the {{ version }} variable from the recipe and make it a static string, the test phase finishes correctly, but obviously this defeats the purpose.

Here is our conda recipe.

Is there a more correct way to handle this in conda build 3 or did we run into a regression of some sort?

Thanks!

[msarahan]

Wow, that's a really cool set of concourse pipelines you have there. I'm able to reproduce this locally, but I haven't isolated the cause yet. I'll look into it for the next bugfix release. Next day or two.

Side note: pinning python has never worked well:

https://github.com/qiime2/qiime2/blob/master/ci/recipe/meta.yaml#L20

If you remove the pinning there, but instead configure your CI system either by setting CONDA_PY=35 or using conda_build_config.yaml (documented at https://conda.io/docs/building/variants.html), I think you'll do better. I'll get back you on this get thing being unresolved.

[ebolyen]

Thanks @msarahan! We'll probably just pin our conda-build to 2 for the moment then.

Re: python pinning, we're looking into getting Python 3.6 support soon, and so conda build 3's variants look awesome for this. Excited to start using them!

[msarahan]

There were two issues here. The one with the Jinja2 was due to a bad regex, causing bad version specs, leading to test env creation failure, leading to a poorly handled exception, leading to a very confusing jinja2 error.

In debugging that, I also found that conda-build's constraint behavior was broken in the presence of pre-release software (such as on conda-forge).

Both of these issues should be fixed by #2183