On 07/30/2016 06:36 PM, P. Larry Nelson wrote: > Hi all, Greetings!
[snip] > 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). > > In my brief Googling, I have not found OS requirements for 2.7.x, but > have inferred that it probably needs SL7.x. > > 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? I have the exact same problem. Don't try to replace 2.6.6. It broke ALL KINDS of things including RPM when I tried it...did not go well at all (but a good learning experience! :-). Here are three solutions: 1) Software Collections: https://www.softwarecollections.org/en/ Upside, A certain favored upstream vendor backs a lot of these packages (just no support). Downside, they run in a special environment which can be tricky depending on the application. It basically runs in a subshell and that confuses my users at least.... 2) Inline Upstream Stable (aka IUS): https://ius.io/ Upside: Backed by Rackspace (again no suport), easy RPMS, they do not stomp on Upstream Vendor packages (different names), and they are kept pretty up-to-date. Downside: they don't have a ton of packages, but they do have your Python 2.7 3) Anaconda Python: https://www.continuum.io/downloads Upside: it runs its own environment which plays nicely with cluster modules (for the most part). You can update that environment inside itself. Need a new version of scipy? 'conda update scipy'. Done. Need Intel Accelerated Python? Or Python 3.5 too? Easy. Downside: When it breaks or when it gets pissy, it can be a pain to figure out. The documentation isn't great. It is open source and you can get official support for it, but it is PRICEY!!! We chose Open Source Anaconda when we needed a new python. For the most part it does its job really well and we are very happy with it. More importantly, the users are happy with it. We use IUS elsewhere but we needed more packages then they provide and it was a pain managing all those packages manually. Same with SCL. We use it elsewhere too, but anything that the users have to interact with, we found they get frustrated because of the weird subshell-environment it uses. Good luck! ~Stack~
signature.asc
Description: OpenPGP digital signature
