PIP_NO_DEPENDENCIES & co not set for outputs/*/script

[mbargull]

Actual Behavior

Environment variables like PIP_NO_DEPENDENCIES set for the build script at https://github.com/conda/conda-build/blob/3.19.2/conda_build/build.py#L2372-L2397 , are not set during the execution of outputs/*/script.
https://github.com/conda/conda-build/blob/3.19.2/conda_build/build.py#L1406-L1450 seems to be the outputs/*/script relevant code.

See https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=186409&view=logs&j=1bf226d3-0e2f-52d8-fa93-7d9e633347b3&t=c09a5a47-eec3-5700-9284-6f1bd7b23501&l=333 .

Expected Behavior

The env vars set at https://github.com/conda/conda-build/blob/3.19.2/conda_build/build.py#L2372-L2397 should also be set when running a recipe's outputs' script.

Steps to Reproduce

See conda-forge/black-feedstock#14 .
If you run that recipe without the added --no-deps, it will trigger the reported behavior.

Output of conda info

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=186409&view=logs&j=1bf226d3-0e2f-52d8-fa93-7d9e633347b3&t=c09a5a47-eec3-5700-9284-6f1bd7b23501&l=189

     active environment : base
    active env location : /opt/conda
            shell level : 1
       user config file : /home/conda/.condarc
 populated config files : /opt/conda/.condarc
                          /home/conda/.condarc
          conda version : 4.8.3
    conda-build version : 3.19.2
         python version : 3.7.6.final.0
       virtual packages : __glibc=2.12
       base environment : /opt/conda  (writable)
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://repo.anaconda.com/pkgs/main/linux-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/r/linux-64
                          https://repo.anaconda.com/pkgs/r/noarch
          package cache : /opt/conda/pkgs
                          /home/conda/.conda/pkgs
       envs directories : /opt/conda/envs
                          /home/conda/.conda/envs
               platform : linux-64
             user-agent : conda/4.8.3 requests/2.24.0 CPython/3.7.6 Linux/4.15.0-1091-azure centos/6.10 glibc/2.12
                UID:GID : 1001:1001
             netrc file : None
           offline mode : False

cc @carlodri, @xhochy

[isuruf]

Isn't this a feature that the envs for outputs are not activated by default and activate_in_script: True has to be added explicitly to make it so?

[mbargull]

IDK. AFAICT, activate_in_script is still an undocumented feature.
There is not much to find with https://github.com/conda/conda-build/search?q=activate_in_script.
#3695
#2735
https://github.com/conda/conda-build/blob/3.19.3/CHANGELOG.txt#L1694

• Activate output scripts in meta.yaml ( run activation in .bat and .sh output scripts automatically #2667 ), but only when:
  • output has a build/script entry
  • output uses {{ compiler() }} jinja2 function in its requirements AND output extension is either .sh or .bat
  • output has build/activate_in_script key in meta.yaml set to a truthy value AND output extension is either .sh or .bat

We do have "output has build/script entry", so I would expect the environment gets activated.
I also tried adding build: activate_in_script: True for the recipe that can be found in conda-forge/black-feedstock#15 (whilst removing the manually set env vars for the pip install call). Even then, the expected environment variables are not set.

To me, it looks like this is broken currently (w/ 3.19.2). IDK if/when it worked before.

[jakirkham]

This also looks similar to issue ( #4292 )

cc @jaimergp

[rlratzel]

Bumping this issue since I recently ran into the same problem using mamba build, and I'm assuming they may be related. @jakirkham mentioned that I should apply the same workarounds used in this PR, which worked for me.

FWIW, I'm building my package using mamba build ... and I have conda-build version 3.21.8 installed.

[jakirkham]

FWIW just saw this issue again today

[h-vetinari]

Thanks for fixing this long-standing issue!