On Sat, Jul 30, 2016 at 7:36 PM, P. Larry Nelson <[email protected]> wrote: > Hi all, > > Please don't shoot the questioner (me), as I have no experience with > Python, other than knowing "what" it is and that my SL6.8 systems have > version 2.6.6 installed. > > I have been asked by one of our Professors that one of his grad students > apparently needs Python 2.7.x installed on our cluster (optimally in > /usr/local, which is an NFS mounted dir everywhere).
Your professor needs to be schooled in the Filesystem Hierarchy Standard, and what /usr/local is for. It is a very, very, very bad idea to NFS deploy potentially incompatible versions of software that overlaps with system based software. Been there done that, took a while to clean up. The current FHS is at https://wiki.linuxfoundation.org/lsb/fhs. > In my brief Googling, I have not found OS requirements for 2.7.x, but > have inferred that it probably needs SL7.x. Nope!!!! For RHEL 6 and thus for SL 6, Red Hat maintains the "Software Collection Library". These can be accessed by consulting http://linux.web.cern.ch/linux/scientific6/docs/softwarecollections.shtml What *these* do is install Python 2.7 in /opt/rh/python27, and use the "scn enable python27 [program]" or use "source /opt/rh/python27/enable command" to reset the working PATH and MANPATH and LD_LIBRARY_PATH, etc. to use Python 2.7 by default I've personally written about.... 160 SPRMs for the python27 working tools installed this way/. If necessary, it's possible to share *that* across multiple Scientific Linux 6 based systems, but it's not necessary. The student's tools can then be written and published in /usr/local/bin or wherever to use those that alternative version of python directly. I'd really recommend the student's tools use a non-default directory, so that the need for python 2.7 can be set separately, especially if they're going to have to use "pip install" to create new modules. It can also be time for the student to learn to use the "py2pack" tool to build actual RPM's, if these tools need to be version controlled and handle dependencies correctly instead of being spewed into "/usr/local". > Can anyone confirm that? > Or has anyone installed Python 2.7.x (and which .x?) on an SL6.8 system > without replacing 2.6.x? See above. And I'll do something I usually don't do here, and point to my professional work at https://github.com/SkyhookWireless/airflowrepobuilder to see where I've done a great deal of python module RPM building work. My current employer has been very good about letting me publish open source. These tools were created precisely to avoid doing "pip install whatever" and potentially overwriting and breaking the existing system published modules. "pip install" for Python modules, like "cpan" for Perl, and like maven, artefactory, gradle, npm, and many re-inventions of software installers, does not keep track of *anyone* else's installations and overwrites them willynilly. "pip install" also installs potentially incompatible versions of the same module at different times of day, depending on the dependencies of the *last* run of the tool. To avoid this on RHEL, CentOS, and Scientific Linux systems, learn to use "py2pack" to build up RPMs. And yes, that airflowrepobuilder includes a python27 compatible version of py2pack and many versions of generated .spec files with the syntax to build for the local python environment, and the python27 environment. > I'm guessing this can be quite a morass to delve into as when I do a > 'rpm -qa|grep -i python|wc' > It returns with 67 rpms with python in the rpm name! Sounds like you've not enabled EPEL, which publishes many more. > If the solution is indeed simple, I might proceed, otherwise, I'm > of a tendency to reply to the Professor and student, "No way - won't work." > I think the student probably has access to CERN systems that probably > have what he's looking for. See above. The requested /usr/local is very dangerous. Note that it is *also* opssible to set up "/usr/local/python27", and basically replicate all the work RHEL did upstream with the software connections library. But lordie, why would you want to? > I've followed up with that inquiry to the student and waiting to hear back. > > Thanks! > - Larry > > > -- > P. Larry Nelson (217-244-9855) | IT Administrator > 457 Loomis Lab | High Energy Physics Group > 1110 W. Green St., Urbana, IL | Physics Dept., Univ. of Ill. > MailTo: [email protected] | > http://hep.physics.illinois.edu/home/lnelson/ > ------------------------------------------------------------------------------ > "Information without accountability is just noise." - P.L. Nelson
