Set required environment variables in Python sanity check

[Flamefire]

(created using eb --new-pr)

Without this the sanity check might fail due to user modules or required venv:

== FAILED: Installation ended unsuccessfully: `python -m pip check` failed:
ERROR: Could not find an activated virtualenv (required).

[Flamefire]

Test report by @Flamefire

Overview of tested easyconfigs (in order)

• SUCCESS Python-3.11.3-GCCcore-12.3.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
i8024 - Linux Rocky Linux 8.9 (Green Obsidian), x86_64, AMD EPYC 7352 24-Core Processor (zen2), 8 x NVIDIA NVIDIA A100-SXM4-40GB, 555.42.06, Python 3.9.18
See https://gist.github.com/Flamefire/55c83c3d0cb5c13216a7b25df3f4d97c for a full test report.

[Crivella]

I guess this would be relevant for any version of pip < 24.2

• https://pip.pypa.io/en/stable/news/#v24-2
• Ignore --require-virtualenv for check and freeze commands pypa/pip#12842

Another interesting aspect that might be work considering for Python module-wise would be to set PYTHONNOUSERSITE=1 in general.
While reproducing this i was wondering why python -m pip -V was reporting my user installed pip even if i had loaded Python from easybuild

This lead me to think that it is possible that the pip check ran right now by easybuild might be affected by what is installed in $HOME/.local/... so another possible benefit of this change would be to avoid this

[Flamefire]

I guess this would be relevant for any version of pip < 24.2

Yes. Nice that they fixed that part.

Another interesting aspect that might be work considering for Python module-wise would be to set PYTHONNOUSERSITE=1 in general.

Where? In framework or so? Or in the module file?

This lead me to think that it is possible that the pip check ran right now by easybuild might be affected by what is installed in $HOME/.local/... so another possible benefit of this change would be to avoid this

Depends. For PythonPackage/Bundle we already set the env var. Only here (and in LAMMPS which I just found) we don't

[Crivella]

Where? In framework or so? Or in the module file?

In the module file from either the Python or PythonBundle easyblocks (or both).
Should give it more thought if it could break something, but i do not think there is a realistic case where we would want to pick up local user installs together with our installs (unless the user is loading a virtualenv on top of it that would not bbe affected by it)

[Flamefire]

In the module file from either the Python or PythonBundle easyblocks (or both).

Python would be enough, doesn't need to be in every module. We currently have a hook adding PIP_REQUIRE_VIRTUALENV=1 to the Python module as we had too many instances of users/admins installing stuff to the Python module by accident.

That could be a standard setting as it doesn't make sense to use pip outside a virtualenv with the Python module, does it? Maybe pip install --prefix might be used by users though.

Should give it more thought if it could break something, but i do not think there is a realistic case where we would want to pick up local user installs together with our install

Not sure. Outside of virtualenvs the users regular pip install installs to his $HOME which is then always available when loading the module. Some sites might allow/suggest that.

It would certainly be a breaking change but I wouldn't mind. It does avoid a class of issues.

[Flamefire]

Could we get this in for the next release please?

[boegel]

lgtm

[boegel]

@boegelbot please test @ jsc-zen3
EB_ARGS="--installpath /tmp/$USER/pr3913 Python-2.7.18-GCCcore-12.3.0.eb Python-3.11.3-GCCcore-12.3.0.eb Python-3.13.5-GCCcore-14.3.0.eb"
CORE_CNT=16

[boegel]

I forgot that jsc-zen3 is down currently, I'll look into uploading a test report myself so we can get this one merged...

[boegelbot]

@boegel: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de

PR test command 'if [[ develop != 'develop' ]]; then EB_BRANCH=develop ./easybuild_develop.sh 2> /dev/null 1>&2; EB_PREFIX=/home/boegelbot/easybuild/develop source init_env_easybuild_develop.sh; fi; EB_PR=3913 EB_ARGS="--installpath /tmp/$USER/pr3913 Python-2.7.18-GCCcore-12.3.0.eb Python-3.11.3-GCCcore-12.3.0.eb Python-3.13.5-GCCcore-14.3.0.eb" EB_CONTAINER= EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3913 --ntasks="16" ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 8995

Test results coming soon (I hope)...

Details

- notification for comment with ID 3605685743 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegel]

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS Python-2.7.18-GCCcore-12.3.0.eb
• SUCCESS Python-3.11.3-GCCcore-12.3.0.eb
• SUCCESS Python-3.13.5-GCCcore-14.3.0.eb

Build succeeded for 3 out of 3 (total: 27 mins 22 secs) (3 easyconfigs in total)
node4243.shinx.os - Linux RHEL 9.6, x86_64, AMD EPYC 9654 96-Core Processor (zen4), Python 3.9.21
See https://gist.github.com/boegel/df74769d7f9fb2f9b4e98ea836044bb2 for a full test report.

[boegelbot]

Test report by @boegelbot

Overview of tested easyconfigs (in order)

• SUCCESS Python-2.7.18-GCCcore-12.3.0.eb
• SUCCESS Python-3.11.3-GCCcore-12.3.0.eb
• SUCCESS Python-3.13.5-GCCcore-14.3.0.eb

Build succeeded for 3 out of 3 (total: 32 mins 38 secs) (3 easyconfigs in total)
jsczen3c1.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.6, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.21
See https://gist.github.com/boegelbot/bfa831df680e94ed956c16824caa72a3 for a full test report.