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 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: [log in to unmask] |
> http://hep.physics.illinois.edu/home/lnelson/
> ------------------------------------------------------------------------------
> "Information without accountability is just noise." - P.L. Nelson
|
