[scl.org] Problems with Python scripts that use SCL runtimes

[Nick Coghlan]

On Thu, Jun 9, 2016 at 7:59 AM, Davis, Daniel (NIH/NLM) [C]
<daniel.davis at nih.gov> wrote:
> Nick,
>
> We also encountered this issue, and we wished DevOps and developers not to have the issue.
> So, our development users, DevOps account, and CI account all have in their ~/.bash_profile:
>
>         test -f /opt/rh/rh-python34/enable && source /opt/rh/rh-python34/enable
>
> This enable script is different from "scl enable" in that it does not start a sub-process.
>
> This could be done for everyone via /etc/profile.d/, but we haven't gone that far - we would want then to test whether the user is in a group that gets Python 3, because we don't want this for everyone - vendor provided python scripts may sadly start with "#!/usr/bin/env python"!
>
> We also place this line in /etc/sysconfig/httpd, but now that we have switched from mod_wsgi to Phusion Passenger, it is not clear that this is needed.
>
> Does this address your issue?

Not quite, although I do like it as a way to improve the situation in
managed environments that only want to support a single
non-system-Python version at a time.

It occurs to me that a potential better illustrator than pipsi of the
user experience problem I see with the status quo is the "vex" virtual
environment manager, which I use to switch between Python 2 and Python
3 for different projects (my own primary OS is Fedora, so I have both
installed as system packages):

    vex --python `which python2` -m py2-example
    vex --python `which python3` -m py3-example

Given virtual environments created that way, I no longer need to
remember which ones are Python 2 and which are Python 3 - "vex
py2-example" and "vex py3-example" will automatically activate the
right runtime.

SCLs don't currently offer that same degree of seamlessness, since
they rely on LD_LIBRARY_PATH being set in the environment, rather than
building knowledge of the SCLs additional shared library directories
directly into the binaries. They certainly *can* be used without it,
but it's an ongoing source of friction since Python tools generally
assume that a Python runtime will know where to find its shared
libraries.

Cheers,
Nick.

-- 
Nick Coghlan
Fedora Environments & Stacks
Red Hat Developer Experience, Brisbane

Software Development Workflow Designer & Process Architect