On Sat, Jul 30, 2016 at 7:36 PM, P. Larry Nelson <[log in to unmask]> 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: [log in to unmask] |
> http://hep.physics.illinois.edu/home/lnelson/
> ------------------------------------------------------------------------------
> "Information without accountability is just noise." - P.L. Nelson
|
