On Thu, Jun 9, 2016 at 7:59 AM, Davis, Daniel (NIH/NLM) [C] <daniel.da...@nih.gov> wrote: > 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?
Not quite, although I do like it as a way to improve the situation in managed environments that only want to support a single non-system-Python version at a time. It occurs to me that a potential better illustrator than pipsi of the user experience problem I see with the status quo is the "vex" virtual environment manager, which I use to switch between Python 2 and Python 3 for different projects (my own primary OS is Fedora, so I have both installed as system packages): vex --python `which python2` -m py2-example vex --python `which python3` -m py3-example Given virtual environments created that way, I no longer need to remember which ones are Python 2 and which are Python 3 - "vex py2-example" and "vex py3-example" will automatically activate the right runtime. SCLs don't currently offer that same degree of seamlessness, since they rely on LD_LIBRARY_PATH being set in the environment, rather than building knowledge of the SCLs additional shared library directories directly into the binaries. They certainly *can* be used without it, but it's an ongoing source of friction since Python tools generally assume that a Python runtime will know where to find its shared libraries. Cheers, 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