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