-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drop support for Python 2.6 #1596
Comments
For Centos 6 you can easily install Python 2.7 using software collections with:
Then the software collection needs to be enabled with:
|
Could be a problem at sites where this is not allowed, although I'd like to hear people at such sites chime in. |
Just to add this, pip's now spouting:
|
So, +1 |
Currently, we are still using Python 2.6 to run Galaxy. Since we are about to change 'everything' within the next few months, we will also jump to Python 2.7. |
My experiences: our first production Galaxy instance used Python 2.6 (which was the default on Scientific Linux 6.whatever) - I never had trouble with the core Galaxy platform but I remember a couple of tool installations from the TS implicitly expected Python 2.7 (e.g. using 2.7-only modules) and this caused me a few headaches at the time. Since then I've always installed Python 2.7 and use this for Galaxy if it's not otherwise available. Building 2.7.11 from source seems to install to |
We are still using Python 2.6 and CentOS 6 in order to match our cluster. We don't yet have a date for moving that to CentOS 7. |
@peterjc is installing Python 2.7 on your CentOS 6 systems an option for you? |
Python2.7 on SL6.6 here, so we are fine and could share our Python build scripts and setup if needed. |
We can look into using Python 2.7 rather than Python 2.6 under CentOS 6, but would have to roll this out for the Galaxy server and the entire cluster. I don't know if our SysAdmins would prefer doing this via the software collection package repository, or perhaps just having a Python 2.7 compiled from source... |
@peterjc we installed python 2.7 specifically for our local Galaxy instance and have been running it off our NFS, which seemed to work fine. |
galaxy-dev informed this is on horizon - http://dev.list.galaxyproject.org/Python-2-6-Support-td4668888.html |
I would sort of like to retain Python 2.6 support in the subset of Galaxy that is galaxy-lib for now... I think... for Pulsar. Maybe not though, time to just let go huh? |
👍 for letting go |
According to @dannon svgwrite is the first causality of dropping Python 2.6 support (#1882). Galaxy needs to have an explicit early abort when run with older unsupported versions of Python to save people pain of this kind of cryptic failure.... i.e. Update https://github.com/galaxyproject/galaxy/blob/dev/scripts/check_python.py which still says Python 2.6 is supported. |
@peterjc Nice catch. I'm closing that other issue and will update check_python to assert 2.7+. |
(and this one, I guess) |
Seems like something is not quite right still though. We are installing latest GALAXY on CentOS 6.5 system. routinely using python2.7 along side python2.6 and have aliased python, pip, etc all to 2.7 version - but GALAXY install (clean, from scratch) still carps about 2.6 being installed and not support, install then fails.
scratching my head here a bit... |
@jonathanjacobs It seems that the python installed in your virtualenv
If this works, you can remove the |
Nope. No dice. I removed galaxy all together to start fresh, and re cloned from github. Now, oddly enough - when I run ./run.sh it skips the install steps and immediately reports the python version mismatch. (which isn't correct).
And... I don't have a .venv directory in the first place... i'll keep hacking away at this... |
Now this... (bold text added for some clarity)
Any idea what's going on? It seems like the developers should simply hardcode python2.7 in the install scripts instead of just "python". I can't seem to figure out why this ./run.sh script is still calling python2.6 -- must be something to do with my bash environment? by where would I look? my PATH include python2.7 for all users... |
@jonathanjacobs aliases are for interactive environments, they are not passed on to shell scripts. If you want to ensure that the first python found is python 2.7, set Alternatively, you can create the virtualenv by hand first, as you did in your last comment. Are you certain that |
Python 2.6's EOL was with the 2.6.9 release in October 2013. The primary reason why we have continued to support Python 2.6 is that RHEL (and derivatives) 6 is still in wide deployment, and RHEL 6's Python is 2.6. I am not sure when the right time to drop 2.6 support will be, but wanted to make sure we had an issue to allow for discussion and cross referencing.
Many tools already require Python 2.7, to the extent that even though usegalaxy.org runs CentOS 6, we have compiled and use Python 2.7 to run tools. Although this is ultimately a tool dependency issue (for example, some IUC tools depend on an IUC Python 2.7 package) and need not necessarily guide the decision for the framework.
The text was updated successfully, but these errors were encountered: