For us, it was more the fact that we are locked down to a certain OS version due to our local IT policy and the software repositories don't provide a newer Python than v2.6.8. It was not the first occasion in terms of desperately outdated software (recently it's gcc itself), so we are used to compile from source. Using pre-compiled packages from OpenSUSE repos is not guaranteed to work properly. For us, it is just another (larger) paragraph for our setup environment written in Ansible. Overall, it is quite generic and nearly everything needed by Galaxy is installed in home scheme. On top, although we are in a quite tight internal network, we realized that our OpenSSL is of 'pre-heartbleed' times, so it was a good deal to re-integrate that. Python, wget and others take advantage from this update if properly linked. Certificate exchange and SSL version usage have moved on in the last years, and from time to time we got errors/warnings when accessing external servers.
On Wed, Mar 23, 2016 at 10:54 PM, D K email@example.com wrote:
Great! thanks for the suggestions. I just tried using centos software collections and that seems to work. I'll do some more testing but hopefully it's as simple as that! Is there any reason that most of you who responded have decided to compile your own pythons?
It sounds like both options are effective.
In my case it was perhaps a choice out of ignorance about just how the CentOS software collections works - and fear about the CentOS 6 to 7 migration.
In our case both the Galaxy server and the cluster is still on CentOS 6, so we need to use a custom Python 2.7 on both the Galaxy server and also on the cluster nodes - ideally the exact same version so that all the wheel dependencies match up for running the set metadata scripts.
I'm hoping that using a custom Python 2.7 installation (from source) ought to work in our favour if we have to deal with a mixture of CentOS 6 and 7 (although ideally we'd update the cluster and Galaxy server together).