Conda-build: Conda needs to activate _build and _test environments - not monkey with PATH

[jakirkham]

When using the following recipe.

package:
  name: blas_openblas
  version: 1.0.0

build:
  number: 0
  track_features:
    - blas_openblas

test:
  commands:
    - conda list blas_openblas

about:
  home: NA
  license: NA
  summary: Metapackage to enable the use of OpenBLAS in an environment.

extra:
  recipe-maintainers:
    - jakirkham

I run the build, but it appears not to activate the _test environment during the testing phase, but remains in the _build environment. Here is a snippet that I see in the log.

TEST START: blas_openblas-1.0.0-0
Using Anaconda Cloud api site https://api.anaconda.org
Fetching package metadata: ..............
.Solving package specifications: .........

The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    blas_openblas-1.0.0        |                0          657 B  file:///zopt/conda2/conda-bld/osx-64/

The following NEW packages will be INSTALLED:

    blas_openblas: 1.0.0-0 file:///zopt/conda2/conda-bld/osx-64/

Fetching packages ...
blas_openblas- 100% |#############################################################################################################| Time: 0:00:00 947.94 kB/s
Extracting packages ...
[      COMPLETE      ]|################################################################################################################################| 100%
Linking packages ...
[      COMPLETE      ]|################################################################################################################################| 100%
+ conda list blas_openblas
Error: Error: environment does not exist: /zopt/conda2/envs/_build
#
# Use 'conda create' to create an environment before listing its packages.
TESTS FAILED: blas_openblas-1.0.0-0

[msarahan]

This is very related to your compiler configuration PR on conda-forge. IMHO, we need conda-build actually activating environments. That will both clean up code in conda-build, and make it more predictable.

[jakirkham]

Also, this issue ( https://github.com/conda/conda-build/issues/355 ) seems to be related.

[jakirkham]

Also, maybe this issue ( https://github.com/conda/conda-build/issues/353 ) too.

[jakirkham]

Here is a use case for configuring compiler tools ( https://github.com/conda-forge/thrift-cpp-feedstock/pull/4 ). Note that the toolchain simply sets environment variables as part of its activate.sh script to avoid having users do this manually.

[jakirkham]

Just so I know (as there is a 2.0.0beta out), is this still planned for 2.0.0?

[msarahan]

I forgot about it, but it fits. This is what prerelease is for!

[jakirkham]

Awesome, that is very exciting. What do we need to do to make this work?

[msarahan]

Here's what I have so far:

``` def _set_environ_from_subprocess_values(vars): """ Vars is an unprocessed string of envrionment variable output, such as fromset on Windows, orenv``` elsewhere
"""
vars = vars.split("n")
vars = {var.split("=")[0].strip(): var.split("=")[1].strip() for var in vars}
for key, value in vars.items:
os.environ[key] = value

def activate_env(env_name_or_path):
if sys.platform == "win32":
vars = subprocess.check_output(["activate", env_name_or_path,
"&&", "set"]).replace("\rn", "n")
else:
vars = subprocess.check_output(["source", "activate",
env_name_or_path, "&&", "env"])
return _set_environ_from_subprocess_values(vars)

def deactivate_env():
if sys.platform == "win32":
vars = subprocess.check_output(["deactivate", "&&", "set"]).replace("\rn", "n")
else:
vars = subprocess.check_output(["source", "deactivate", "&&", "env"])
return _set_environ_from_subprocess_values(vars)
``````

Still need test cases that prove functionality. Have not run tests to see if this breaks anything.

[jankatins]

This branch has such a functions which I got from xonsh: https://github.com/janschulz/jupyter_environment_kernels/commits/conda_windows -> last two commits

[I've currently no clue why the real repo, where that branch was PR to, has gone missing :-(]

[astrojuanlu]

I would be glad to see this merged to 2.0 too :smile:

[msarahan]

@Juanlu001 this is in 1.21.0. It's a bit buggy. If you're comfortable installing from source, I'd appreciate your review and comments on https://github.com/conda/conda-build/pull/1044, which should hopefully clear up a lot of the errors.

[astrojuanlu]

Great, I will try to provide some feedback this weekend.

[msarahan]

I'm calling this implemented between #1002 and #1044. Please try 1.21.1 and let me know how it works for you.

[ijstokes]

@msarahan I'm not about to reopen this, but I'm using latest conda-build 1.21.6 and I think there is some vestige of this problem manifesting itself: many Conda-Forge feedstock build.sh scripts have a source activate line in them with a comment before that line to this issue to say that the source activate is being done to overcome problems with conda-build. Seeing that this issue was closed I removed those lines but then I have the surprising experience I just described to @mingwandroid in a private chat:

I'm trying to build libhdfs3 from https://github.com/conda-forge/libhdfs3-feedstock, I was surprised to see this line (the first one) in the conda build output:

-- Found PROTOBUF: /home/ijstokes/.conda/envs/protobuf/lib/libprotobuf.so  
-- Found KERBEROS: /home/ijstokes/.conda/envs/_build/lib/libkrb5.so  
-- Found GSASL: /home/ijstokes/.conda/envs/_build/lib/libgsasl.so  
-- Found LIBUUID: /home/ijstokes/.conda/envs/_build/lib/libuuid.so

My build.sh script has in it:

export PROTOBUF_LIBRARY=$CONDA_PREFIX/lib
export PROTOBUF_INCLUDE_DIR=$CONDA_PREFIX/include

And I assumed that would have $CONDA_PREFIX point to /home/ijstokes/.conda/envs/_build. The fact that it does not surprises me, and feels like it might be tied to https://github.com/conda/conda-build/issues/910 which is the piece mentioned at the top of several Conda-Forge build.sh scripts when they explicitly do a source activate ....

@mingwandroid has checked and believes that conda-build does not activate the _build environment. That is the piece that surprises me. Is there a reason for that? What should I be putting instead of CONDA_PREFIX for those two export lines?

[ijstokes]

The plot thickens! I have no idea how conda-build works, but investigating a little bit more I noticed that the very end of my (failed) build attempt had this output:

/home/ijstokes/.conda/envs/_build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../libkrb5.so: undefined reference to `k5_get_error@krb5support_0_MIT'
/home/ijstokes/.conda/envs/_build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.8.5/../../../libkrb5.so: undefined reference to `k5_json_string_create_len@krb5support_0_MIT'
collect2: error: ld returned 1 exit status
make[3]: *** [test/unit/unit] Error 1
make[3]: Leaving directory `/home/ijstokes/conda-bld/work/pivotalrd-libhdfs3-2.2.31/build'
make[2]: *** [test/unit/CMakeFiles/unit.dir/all] Error 2
make[2]: Leaving directory `/home/ijstokes/conda-bld/work/pivotalrd-libhdfs3-2.2.31/build'
make[1]: *** [test/CMakeFiles/unittest.dir/rule] Error 2
make[1]: Leaving directory `/home/ijstokes/conda-bld/work/pivotalrd-libhdfs3-2.2.31/build'
make: *** [unittest] Error 2
Command failed: /bin/bash -x -e /home/ijstokes/conda-bld/work/pivotalrd-libhdfs3-2.2.31/conda_build.sh

So I thought I'd dig around and what does conda_build.sh contain?

$ cat /home/ijstokes/conda-bld/work/pivotalrd-libhdfs3-2.2.31/conda_build.sh
source activate /home/ijstokes/.conda/envs/_build
#!/usr/bin/env bash

export PROTOBUF_LIBRARY=$CONDA_PREFIX/lib
export PROTOBUF_INCLUDE_DIR=$CONDA_PREFIX/include

mkdir build
cd build
export LIBHDFS3_HOME=`pwd`
../bootstrap --prefix=$PREFIX
make
make unittest
make install

So it appears that whatever it is that creates conda_build.sh did add source activate to the top of my build.sh script. More of a mystery as to how protobuf got into the build environment!

[mingwandroid]

I looked a bit more carefully and I can see where it is done now, apologies for the misinformation:

activate _test:
https://github.com/conda/conda-build/blob/master/conda_build/build.py#L749

activate _build (Windows):
https://github.com/conda/conda-build/blob/master/conda_build/windows.py#L209

activate _build (Unix):
https://github.com/conda/conda-build/blob/master/conda_build/build.py#L582

[msarahan]

I believe you should depend primarily on $PREFIX for things like this, which will always be the build environment prefix. $CONDA_PREFIX is brand new, and depends on a very up-to-date conda. Aside from that, it is much less tested.