Bug 1315305

Summary:	Python executable not usable in virtualenv due to library path
Product:	[Community] softwarecollections.org	Reporter:	Matt Williams <matt>
Component:	python33	Assignee:	Python Maintainers <python-maint>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	1.0	CC:	ncoghlan, torsava
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-07 14:12:06 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1479406
Bug Blocks:

Description Matt Williams 2016-03-07 12:43:56 UTC

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:
Always

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-05 02:21:19 UTC

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 14:12:06 UTC

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.