Hi Daniel, I've been using python27 from CentOS Software Collections for quite some time. It's a bit annoying because you have to remember to load it, but it is surely doable.

Cheers, Nicola

On 21/03/16 17:46, D K wrote:

Hi Galaxy Devs,

This may be premature but I read that for Galaxy after 16.01 that the plan is for python 2.6 to no longer be supported. I'm currently running CentOS 6.6 which uses python 2.6. In order to be able to use newer versions of Galaxy is my only option to upgrade to a newer version of CentOS? Is it possible to use Conda, RedHat Software Collections or some other similar method instead of doing this upgrade?

Thanks!

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

We Iocally compile 2.7.8 and keep it in a distinct location that our paths references.

This is very easy and has worked well for us.

Please excuse any typos -- Sent from my iPhone

On Mar 21, 2016, at 5:32 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

Hi D. K.,

We're currently trying a locally compiled Python 2.7 (from source) under the shared Galaxy mount for use with a CentOS 6 cluster and Galaxy server.

This seems to be working once we got the $PATH working for cluster jobs (initially they would try to set the Galaxy metadata using the system Python 2.6, which would fail).

I don't know if this is any easier than using the CenOS Software Collections as suggested by Nicola, especially when it comes to updating the OS.

Peter

...

On Mon, Mar 21, 2016 at 5:59 PM, Nicola Soranzo nsoranzo@tiscali.it wrote: Hi Daniel, I've been using python27 from CentOS Software Collections for quite some time. It's a bit annoying because you have to remember to load it, but it is surely doable.

Cheers, Nicola

On 21/03/16 17:46, D K wrote:

Hi Galaxy Devs,

This may be premature but I read that for Galaxy after 16.01 that the plan is for python 2.6 to no longer be supported. I'm currently running CentOS 6.6 which uses python 2.6. In order to be able to use newer versions of Galaxy is my only option to upgrade to a newer version of CentOS? Is it possible to use Conda, RedHat Software Collections or some other similar method instead of doing this upgrade?

Thanks!

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

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?

D

On Tue, Mar 22, 2016 at 2:26 AM, Sebastian Schaaf < schaaf@ibe.med.uni-muenchen.de> wrote:

Same here for v2.7.11 on SLES 11. If you want to integrate as many modules as possible at compilation time (we had to skip four unimportant ones in the end) it may be painful with an older OS, but I assume CentOS is a bit less recalcitrant than SLES. We installed everything in home scheme, which requires proper setup of environment variables like $PATH, $LD_LIBRARY_PATH, $PYTHONPATH, etc... For us the trigger for switching the Python version was an issue with an outdated OpenSSL (just days before the Galaxy announcement regarding the coming deprecation of 2.6), so we included the reworked/conmpiled OpenSSL libraries first. I would recommend the same for you, if your OpenSSL package is <v1.0.2. Currently we are still testing, so we did not reply yet to our own dev list toppic. Be prepared for recursive dependency issues, if your repository software packages are old.

...

We Iocally compile 2.7.8 and keep it in a distinct location that our

paths

...

references.

This is very easy and has worked well for us.

Please excuse any typos -- Sent from my iPhone

...

On Mar 21, 2016, at 5:32 PM, Peter Cock p.j.a.cock@googlemail.com wrote:

Hi D. K.,

We're currently trying a locally compiled Python 2.7 (from source) under the shared Galaxy mount for use with a CentOS 6 cluster and Galaxy server.

This seems to be working once we got the $PATH working for cluster jobs (initially they would try to set the Galaxy metadata using the system Python 2.6, which would fail).

I don't know if this is any easier than using the CenOS Software Collections as suggested by Nicola, especially when it comes to updating the OS.

Peter

...

On Mon, Mar 21, 2016 at 5:59 PM, Nicola Soranzo nsoranzo@tiscali.it wrote: Hi Daniel, I've been using python27 from CentOS Software Collections for quite some time. It's a bit annoying because you have to remember to load it, but it is surely doable.

Cheers, Nicola

On 21/03/16 17:46, D K wrote:

Hi Galaxy Devs,

This may be premature but I read that for Galaxy after 16.01 that the plan is for python 2.6 to no longer be supported. I'm currently running CentOS 6.6 which uses python 2.6. In order to be able to use newer versions of Galaxy is my only option to upgrade to a newer version of CentOS? Is it possible to use Conda, RedHat Software Collections or some other similar method instead of doing this upgrade?

Thanks!

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: https://lists.galaxyproject.org/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

-- Sebastian Schaaf, M.Sc. Bioinformatics Faculty Coordinator NGS Infrastructure Chair of Biometry and Bioinformatics Department of Medical Informatics, Biometry and Epidemiology (IBE) University of Munich DKTK Munich Marchioninistr. 15, K U1 808 D-81377 Munich (Germany) Tel: +49 89 4400 77499

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 danielfortin86@gmail.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?

D

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).

Regards,

Peter