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

[Davis, Daniel (NIH/NLM) [C]]

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?

Dan Davis, Systems/Applications Architect (Contractor),
Office of Computer and Communications Systems,
National Library of Medicine, NIH


-----Original Message-----
From: sclorg-bounces at redhat.com [mailto:sclorg-bounces at redhat.com] On Behalf Of Nick Coghlan
Sent: Thursday, June 09, 2016 10:07 AM
To: sclorg at redhat.com
Subject: [scl.org] Problems with Python scripts that use SCL runtimes

Hi folks,

The question of the explicit "scl enable" step for using SCLs is one that's come up a few times in different contexts, and I finally sat down to document a relatively straightforward scenario that illustrates the problem:
https://github.com/ncoghlan/scl-pipsi-demo#demonstrating-the-problem

What the demo covers doing is:

1. Enable the Python 3.5 SCL
2. Use pipsi within that SCL to install the pygmentize script for a particular user within a virtual environment configured to use that particular runtime 3. Disable the SCL 4. Show that the installed script doesn't work due to the runtime being unable to find its shared libraries

Ideally, the fact I used an SCL to install (and subsequently run) pygmentize would be an invisible implementation detail. However, at the moment, it's visible, since Python's virtual environment machinery only fixes paths for Python level imports - it doesn't touch the paths for operating system level dynamic library loading.

As far as I am aware, changing the SCL binaries to set RPATH and/or RUNPATH should be sufficient to resolve the problem, at least with pipsi managed script installation (plain "--user" installations are likely to still have problems, but I'm more comfortable with a restriction saying not to use --user installs in conjunction with
SCLs)

Regards,
Nick.

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

Software Development Workflow Designer & Process Architect

_______________________________________________
SCLorg mailing list
SCLorg at redhat.com
https://www.redhat.com/mailman/listinfo/sclorg