main: If user supplies --python, auto-set CONDA_PY environment variable.

[stuarteberg]

To build with a specific python version, the user can try two things:

1. The CONDA_PY environment variable, e.g. CONDA_PY=27 conda build my-package

   OR

2. The --python option on the command-line, e.g. conda build --python=2.7 my-package

Internally, both mechanisms set CONDA_PY within conda_build.config. Additionally, os.environ["CONDA_PY"] can also be used, but only if the user used the first mechanism. It would be nice if that also worked in the second case. (For example, that would make the value consistently available to jinja2 templates within meta.yaml, as well as the build.sh environment.)

This little PR just copies config.CONDA_PY (and config.CONDA_NPY, etc.) into os.environ, so the two modules are in sync for these variables.

It allows meta.yaml syntax like this, which doesn't always work in the current version of conda-build:

build:
  string: np{{CONDA_NPY}}py{{CONDA_PY}}_0_foo_bar

[stuarteberg]

To better understand this problem, consider this example:

package:
  name: mypackage
  version: "0.1"

build:
  number: 0
  string: py{{ CONDA_PY }}_0

requirements:
  build:
    - python
  run:
    - python

In this case, CONDA_PY=27 and --python=2.7 do not have the same effect on the build string:

$ CONDA_PY=27 conda build mypackage
...
BUILD START: mypackage-0.1-py27_0
...

Looks good so far...

$ conda build mypackage --python=2.7
...
BUILD START: mypackage-0.1-py_0
...

Whoops, I expected to see py27!

[stuarteberg]

Ping @msarahan and @groutr:

Sorry to pester you guys with more jinja template stuff today, but can you take a look at this? This is a tiny PR (4 lines) that fixes CONDA_PY, CONDA_R, CONDA_PERL, and CONDA_NPY in meta.yaml jinja templates.

[msarahan]

Just so I'm clear on this: you are effectively giving priority to any setting passed in with command line stuff, like "--python" over the environment variables, right? I'm ok with that, just want to make sure I understand.

[stuarteberg]

That was already the case. The original behavior was equivalent to the following pseudo-code:

# By default, use os.environ
conda_build.config.Config.CONDA_PY = os.environ['CONDA_PY']

# Override with --python=foo.bar, if available
if args.python:
    conda_build.config.Config.CONDA_PY = args.python

I just want os.environ to also reflect the change. In the pseudo-code, I'm adding a line to the if-block:

# By default, use os.environ
conda_build.config.Config.CONDA_PY = os.environ['CONDA_PY']

# Override with --python=foo.bar, if available
if args.python:
    conda_build.config.Config.CONDA_PY = args.python
    # Also, update os.environ
    os.environ['CONDA_PY'] = args.python

[stuarteberg]

Well, I guess it's going outside the if-block. But it's equivalent.

# By default, use os.environ
conda_build.config.Config.CONDA_PY = os.environ['CONDA_PY']

# Override with --python=foo.bar, if available
if args.python:
    conda_build.config.Config.CONDA_PY = args.python

# No matter what, make sure os.environ is in-sync with conda_build.config
os.environ['CONDA_PY'] = conda_build.config.Config.CONDA_PY

[groutr]

when you set --python=2.7, does CONDA_PY have a value of 27 or 2.7?

[msarahan]

OK, well +1 from me. Will check in with @groutr

[stuarteberg]

when you set --python=2.7, does CONDA_PY have a value of 27 or 2.7?

CONDA_PY has a value of 27

Edit: That's the original behavior, unchanged in this PR. See here: https://github.com/conda/conda-build/pull/662/files?diff=unified#diff-c79cbf0306ce864b4ea844b108e06d4dL301

[groutr]

Ok. I didn't see where they reformatted the string. +1 from me too.

[stuarteberg]

Excellent. Thanks, guys.