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-boun...@redhat.com [mailto:sclorg-boun...@redhat.com] On Behalf Of Nick Coghlan Sent: Thursday, June 09, 2016 10:07 AM To: sclorg@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@redhat.com https://www.redhat.com/mailman/listinfo/sclorg _______________________________________________ SCLorg mailing list SCLorg@redhat.com https://www.redhat.com/mailman/listinfo/sclorg