On Sat, Jul 30, 2016 at 7:36 PM, P. Larry Nelson <lnel...@illinois.edu> 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 File Hierarchy System, 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. > 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 I've personally written about.... 160 SPRMs for the python27 working tools installed this way, and which live in /opt/rh/python27/. If necessary, it's possible to share *that* across multiple Scientific Linux 6 based systems, but it's not necessary. If they student needs to share the python 2.7 built tools across multiple environments, then they should use a *different* deployment location thatn the top of /usr/local. /usr/local/python2.7, for example, might be a reasonable share location, and it can be autofs shared via NFS. > 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. This was done precisely to avoid people 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, and, gradle, and many re-inventions of software installation tools, does not keep track of *anyone* else's installations and upgrades them and replaces without even checking the dependencies of any other component of the system. There are words for this kind of behavior, the but key aspect is that whatever you are installing right now is more important than anything else already present. And every single one of those installers grabs the latest version of the software, and installs the latest version of all unsatisfied dependencies, by default. That works just fine with one-host, one application models, but if you have to share workspaces it breaks down pretty badly. > 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! > > 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. > > I've followed up with that inquiry to the student and waiting to hear back. > > Thanks! > - Larry See above. For SL 6, definitely activate the software collections to gain access to Python 2.7 binaries and package environments. > -- > 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: lnel...@illinois.edu | > http://hep.physics.illinois.edu/home/lnelson/ > ------------------------------------------------------------------------------ > "Information without accountability is just noise." - P.L. Nelson