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

Nick Coghlan ncoghlan at redhat.com
Thu Jun 9 14:07:07 UTC 2016


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




More information about the SCLorg mailing list