Description of problem:

When installing Python projects, pip generates wrapper scripts for declared entry points: https://packaging.python.org/distributing/#console-scripts

This process assumes that running the script with the shebang line set to `sys.executable` will be sufficient to start Python with the correct sys.path settings, which is a correct assumption for Python virtual environments and full Linux containers, but not correct for Software Collections (since dynamically linked external C libraries won't be found correctly).


How reproducible:

Always

Steps to Reproduce:
1. Install a project with entry points defined that relies on external C extensions linked against the SCL Python binary
2. Run that project via a wrapper script generated by pip, setuptools, or pipsi
3.

Actual results:

You have to explicitly activate the SCL before the wrapper scripts will work

Expected results:

The wrapper scripts work automatically without requiring separate activation of the SCL (i.e. the use of the SCL Python becomes a transparent implementation detail of the installed script)

Additional info:

Ideally, this could be done *without* needing to patch the wrapper generation process by instead setting RPATH appropriately in the SCL Python executable, as then it would also fix subprocess execution of sys.executable with environment inheritance disabled (SCLs currently rely on the active environment being passed through to subprocesses), as well as every other piece of Python code that assumes that "sys.executable" provides all the info you need in order to re-run the "same" Python environment.

Such an approach would also ensure that running "pip install --upgrade pip wheel setuptools" inside a virtual environment doesn't break anything (this is a common technique to ensure a project is using the latest version of these tools with full support for modern Python packaging techniques)

Alternatively, the fix could be implemented by patching the SCL provided python-pip and python-setuptools to be "SCL aware", but that has the downside of being quite fragile, and inconsistent with the established techniques for running Python programs in a particular environment.