Problem with sqlalchemy / python versions
Hello, After pulling the latest version, I've encountered a problem with importing sqlalchemy. (I haven't upgraded in a long time, so I can't be sure which changeset introduced this issue). The symptom is that running the upload.py python script throws the following exception: ----------------------- Traceback (most recent call last): File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/tools/data_source/upload.py", line 10, in import galaxy.model File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/model/__init__.py", line 13, in import galaxy.datatypes.registry File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/datatypes/registry.py", line 6, in import data, tabular, interval, images, sequence, qualityscore, genetics, xml, coverage, tracks, chrominfo File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/datatypes/data.py", line 6, in import metadata File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/datatypes/metadata.py", line 5, in from galaxy.web import form_builder File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/web/__init__.py", line 5, in from framework import expose, json, require_login, require_admin, url_for, error, form, FormBuilder File "/home/gordon/projects/galaxy_servers/galaxy_fresh_copy/lib/galaxy/web/framework/__init__.py", line 31, in from sqlalchemy import and_ ImportError: No module named sqlalchemy ------------------------ It happens in the following scenario: 1. clone a fresh copy of galaxy 2. run "sh setup.sh" 3. run "sh run.sh" 4. upload a data file to galaxy. 5. The file is completely uploaded (the purple rectangle step) 6. galaxy executes "upload.py" - then the problem happens. I can also reproduce it quickly by doing: 1. clone a fresh copy of galaxy 2. run "sh setup.sh" 3. remove the "-ES" parameters from "run.sh" 4. run "sh run.sh" In which case the following exception is thrown: gordon@tango:~/temp/galaxy$ sh run.sh Traceback (most recent call last): File "./scripts/paster.py", line 27, in <module> command.run() File "build/bdist.solaris-2.11-i86pc/egg/paste/script/command.py", line 78, in run File "build/bdist.solaris-2.11-i86pc/egg/paste/script/command.py", line 117, in invoke File "build/bdist.solaris-2.11-i86pc/egg/paste/script/command.py", line 212, in run File "build/bdist.solaris-2.11-i86pc/egg/paste/script/serve.py", line 227, in command File "build/bdist.solaris-2.11-i86pc/egg/paste/script/serve.py", line 250, in loadapp File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 193, in loadapp File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 213, in loadobj File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 237, in loadcontext File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 267, in _loadconfig File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 397, in get_context File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 439, in _context_from_explicit File "build/bdist.solaris-2.11-i86pc/egg/paste/deploy/loadwsgi.py", line 18, in import_string File "/home/gordon/temp/galaxy/lib/pkg_resources.py", line 1912, in load entry = __import__(self.module_name, globals(),globals(), ['__name__']) File "/home/gordon/temp/galaxy/lib/galaxy/web/__init__.py", line 5, in <module> from framework import expose, json, require_login, require_admin, url_for, error, form, FormBuilder File "/home/gordon/temp/galaxy/lib/galaxy/web/framework/__init__.py", line 31, in <module> from sqlalchemy import and_ ImportError: No module named sqlalchemy My guess is that this is a mix-up of using my site-wide python modules (without "-ES") and Galaxy's eggs (with "-ES"). But I don't know how to solve it. Also, there's the issue of executing python from inside galaxy: On my development station, python2.5 is the default and all is well. My production server is CentOS-5.3 - in which the default python is 2.4 (I had to change 'run.sh' to run "python2.5"). On an Ubuntu machine, the problem is reversed: Ubuntu switched to python2.6 (since 9.04) - so running just "python" runs 2.6. So far I (wrongly) assumed I only needed to change the shell scripts (run.sh, setup.sh, manage_db.sh) to use a fixed python version. But if galaxy runs python internally (other than tools written in python), then maybe a better solution is needed. Any help from a python guru will be greatly appreciated - so far I can't run the upgraded version (and can't really go back since I've upgrade the DB to version 21). Thanks! gordon. P.S. I'm running Debian 5.0, with the following python (and site-wide sqlalchemy) $ python Python 2.5.2 (r252:60911, Jan 4 2009, 21:59:32) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.
import sqlalchemy sqlalchemy.__version__ '0.4.7p1'
Assaf Gordon wrote:
My guess is that this is a mix-up of using my site-wide python modules (without "-ES") and Galaxy's eggs (with "-ES"). But I don't know how to solve it.
This is most likely correct. Any chance you can remove any conflicting copies of SQLAlchemy from your site-packages/$PYTHONPATH? There appears to be a bug in the pkg_resources.require monkeypatch we've written.
Also, there's the issue of executing python from inside galaxy: On my development station, python2.5 is the default and all is well. My production server is CentOS-5.3 - in which the default python is 2.4 (I had to change 'run.sh' to run "python2.5"). On an Ubuntu machine, the problem is reversed: Ubuntu switched to python2.6 (since 9.04) - so running just "python" runs 2.6.
So far I (wrongly) assumed I only needed to change the shell scripts (run.sh, setup.sh, manage_db.sh) to use a fixed python version. But if galaxy runs python internally (other than tools written in python), then maybe a better solution is needed.
Any help from a python guru will be greatly appreciated - so far I can't run the upgraded version (and can't really go back since I've upgrade the DB to version 21).
Since there's not any easy way to say "find the right Python," I solve this by symlinking to the version I want. Since you're running on a diverse set of systems, you may need to do some 'case'ing in your shell startup scripts to add the right symlinked python to your $PATH. --nate
Nate Coraor wrote, On 10/05/2009 12:06 PM:
My guess is that this is a mix-up of using my site-wide python modules (without "-ES") and Galaxy's eggs (with "-ES"). But I don't know how to solve it.
This is most likely correct. Any chance you can remove any conflicting copies of SQLAlchemy from your site-packages/$PYTHONPATH? There appears to be a bug in the pkg_resources.require monkeypatch we've written.
It works! thanks!
participants (2)
-
Assaf Gordon -
Nate Coraor