Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PIP_NO_DEPENDENCIES & co not set for outputs/*/script #3993

Closed
mbargull opened this issue Jul 22, 2020 · 6 comments · Fixed by #5368
Closed

PIP_NO_DEPENDENCIES & co not set for outputs/*/script #3993

mbargull opened this issue Jul 22, 2020 · 6 comments · Fixed by #5368
Labels
duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR type::bug describes erroneous operation, use severity::* to classify the type

Comments

@mbargull
Copy link
Member

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
Copy link
Contributor

isuruf commented Jul 24, 2020

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
Copy link
Member Author

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
Copy link
Member

This also looks similar to issue ( #4292 )

cc @jaimergp

@rlratzel
Copy link

rlratzel commented Nov 7, 2022

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
Copy link
Member

FWIW just saw this issue again today

@jaimergp jaimergp added the duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR label Mar 25, 2024
@h-vetinari
Copy link
Contributor

Thanks for fixing this long-standing issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate::primary if an issue/PR has duplicates, this is the consolidated, primary issue/PR type::bug describes erroneous operation, use severity::* to classify the type
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

6 participants