I must concede that scl is not as convenient as just having both python and python3 installed side by side, as they are on Ubuntu and Fedora. I really don't think developer convenience is the differentiator point of CentOS/RHEL however, CentOS/RHEL do well in managed environments.
During my start-up experience, our desktops were Fedora, and the product ran on CentOS, depending on the version. That is not a bad way to do it if your governance/systems allows it. I am feeling your pain, however. My current organization runs Python 3 on Windows and deploys on CentOS, as the best solution to some concerns about security and what developers are allowed/encouraged to do. Dan Davis, Systems/Applications Architect (Contractor), Office of Computer and Communications Systems, National Library of Medicine, NIH -----Original Message----- From: Nick Coghlan [mailto:ncogh...@redhat.com] Sent: Thursday, June 09, 2016 2:41 PM To: Davis, Daniel (NIH/NLM) [C] <daniel.da...@nih.gov> Cc: sclorg@redhat.com Subject: Re: [scl.org] Problems with Python scripts that use SCL runtimes 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
