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