Repository: conda/conda-build

Issue:
During testing phase, platform.machine() returns None on Windows (regression)
I am maintaining a conda package for [py-cpuinfo](https://github.com/workhorsy/py-cpuinfo), but with recent conda-build versions (from the 2.1.x branch) it fails during the test phase when it tries to check via `platform.machine()` whether it runs on a supported platform. The reason is that `platform.machine()` does not return `AMD64` as expected, but instead `None` (it works during the build phase).
I bisected the problem to commit 430ce9928, although I can't say I see how the commit would lead to this outcome. Here's a pretty minimal `meta.yaml` file that reproduces the issue for me, it fails with an `AssertionError` with conda-build versions after the above mentioned commit (or from release 2.1.6 on):
```yaml
package:
  name: dummy
  version: 1.0

requirements:
  run:
    - python

test:
  commands:
    - python -c "import platform; assert platform.machine()"
```
The problem seems to be Windows-specific (I only tested 64bit), it works fine for me on Linux and OS X.


Discussion:
It [looks like on Windows](https://github.com/python/cpython/blob/v3.6.1/Lib/platform.py#L933-L944) the information for `platform.machine()` is being detected from PROCESSOR_* environment variables.  Conda build limits the environment variables which are passed to the build environment and these do not seem to be passed through.  It is possible to ["white-list" variables](https://conda.io/docs/building/meta-yaml.html#use-environment-variables) to be passed through to the build script using **script_env**.  For example adding the following to the example recipe allows the build to pass:

``` yaml
build:
  script_env:
    - PROCESSOR_ARCHITEW6432
    - PROCESSOR_ARCHITECTURE
    - PROCESSOR_IDENTIFIER
```

Longer term it might make sense to add these to the list of variables automatically inherited.
Ah, many thanks, passing on these variables could be a viable workaround for my issue. However, according to the documentation, the whitelist seems to be about the *build* phase, not the testing phase. In the build phase, `platform.machine()` does actually seem to work fine, it is only broken during the testing phase.
The whitelist should affect the build and test phases similarly.  If it's not, that's a bug.  I'll look into it.

This sort of system environment info is stuff that I'd be OK with whitelisting.  I never want to whitelist something like PATH, but hardware identification should be fine.  We just want to avoid user-specific configuration that limits reproducibility from leaking into packages.
> The whitelist should affect the build and test phases similarly. If it's not, that's a bug. I'll look into it.

Apologies if my comment was misleading: the whitelisting works for the test phase as well. I could therefore successfully use `script_env` as a workaround to fix my package. My comment was referring to the [documentation](https://conda.io/docs/building/meta-yaml.html#use-environment-variables) which states

> Normally the build script in build.sh or bld.bat does not pass through environment variables from the command line. Only environment variables documented in Environment variables are seen by the build script. To “white-list” environment variables that should be passed through to the build script, use script_env.

This leaves it open whether all this also applies to the test phase.

Resolving patch:
diff --git a/conda_build/environ.py b/conda_build/environ.py
--- a/conda_build/environ.py
+++ b/conda_build/environ.py
@@ -433,6 +433,10 @@ def windows_vars(prefix):
         'USERNAME': os.getenv('USERNAME'),
         'USERPROFILE': os.getenv('USERPROFILE'),
         'windir': os.getenv('windir'),
+        # CPU data, see https://github.com/conda/conda-build/issues/2064
+        'PROCESSOR_ARCHITEW6432': os.getenv('PROCESSOR_ARCHITEW6432'),
+        'PROCESSOR_ARCHITECTURE': os.getenv('PROCESSOR_ARCHITECTURE'),
+        'PROCESSOR_IDENTIFIER': os.getenv('PROCESSOR_IDENTIFIER'),
     }
 
 


Test patch: