Bug 1315305 - Python executable not usable in virtualenv due to library path
Python executable not usable in virtualenv due to library path
Product: softwarecollections.org
Classification: Community
Component: python33 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Python Maintainers
Depends On: 1479406
  Show dependency treegraph
Reported: 2016-03-07 07:43 EST by Matt Williams
Modified: 2017-12-07 09:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-12-07 09:12:06 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Matt Williams 2016-03-07 07:43:56 EST
Description of problem:
The binaries of applications installed with SCL do not set their RPATH to point to their libraries. I understand that there are good reasons in general to avoid using RPATH when building distribution packages but I feel that software collections are a special case of packaging.

It is usual in Python development to create a virtualenv which creates an isolated environment which runs everything against a specific version of Python. It does this by making a copy of the appropriate Python executable into the virtualenv directory. Ordinarily this is fine since it is copying a system python binary which is linking against system python libraries. However, when using SCLs the python libraries aren't available in the system library search path.

To make it work, as a user you have to enable both the SCL *and* the virtualenv before you can run python. Instead, if /opt/rh/python33/root/usr/bin/python3 sorted an RPATH of '$ORIGIN/../lib64' then the standard Python workflow would work.

How reproducible:

Steps to Reproduce:
$ scl enable python33 -- virtualenv ~/scl_test
$ ~/scl_test/bin/pip list

Actual results:
~/scl_test/bin/pip: error while loading shared libraries: libpython3.3m.so.1.0: cannot open shared object file: No such file or directory

Expected results:
It should run the tool `pip` using the correct SCL version of Python.
Comment 1 Nick Coghlan 2017-12-04 21:21:19 EST
Tomas, with https://bugzilla.redhat.com/show_bug.cgi?id=1479406 implemented for the Python collections in RHSCLs 3.0, can this be closed now?
Comment 2 Tomas Orsava 2017-12-07 09:12:06 EST
Indeed I tested that the abovementioned RFE fixes this issue as well, though it's only fixed in rh-python36 (and any later versions), as python33 collection is EOL now.

Note You need to log in before you can comment on or make changes to this bug.