Chris Cole wrote:

OK. It looks it's a python 2.4 issue.

I've just re-run the working 2.6 version with 2.4. It fetched a whole bunch of 'out of date' eggs and then wanted me to scramble the DRMAA egg. Having done that, Galaxy refuses to start with the following error:

Hi Chris, Did you scramble the 2.4 egg using our scripts, or by hand? --nate

Traceback (most recent call last): File "/homes/www-galaxy/galaxy_devel/lib/galaxy/web/buildapp.py", line 61, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/app.py", line 67, in __init__ self.job_manager = jobs.JobManager( self ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/__init__.py", line 40, in __init__ self.dispatcher = DefaultJobDispatcher( app ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/__init__.py", line 777, in __init__ self.job_runners[runner_name] = runners.sge.SGEJobRunner( app ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/runners/sge.py", line 71, in __init__ raise Exception( "SGEJobRunner requires DRMAA_python which was not found" ) Exception: SGEJobRunner requires DRMAA_python which was not found

Anyone have ideas? Cheers,

Chris

On 03/05/2010 02:30 PM, Chris Cole wrote:

...

Hi,

We have two parallel installs of Galaxy one which runs with python2.4 and the other with 2.6. The 2.6 is working fine (other than the issues I've posted) however, the 2.4 won't start as it can't find DRMAA_python. I have scrambled the egg and it does exist: www-galaxy@ge-002: galaxy_live> ls -l /homes/www-galaxy/galaxy_live/eggs/DRMAA_python-0.2-py2.4-linux-x86_64-ucs4.egg

-rw-r--r-- 1 www-galaxy barton 62374 Mar 5 14:22 /homes/www-galaxy/galaxy_live/eggs/DRMAA_python-0.2-py2.4-linux-x86_64-ucs4.egg

What am I missing? Cheers,

Chris

_______________________________________________ galaxy-dev mailing list galaxy-dev@lists.bx.psu.edu http://lists.bx.psu.edu/listinfo/galaxy-dev

Chris Cole wrote:

Using your scripts: python scripts/scramble.py DRMAA_python

This is totally reproducible. I 'downgraded' the working py 2.6 server to py 2.4 and it stopped working, and I've 'upgraded' the not-working py 2.4 server to py 2.6 which is now working fine. At each change I re-scrambled the eggs.

Hi Chris, In /homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/runners/sge.py, could you require and import DRMAA outside of the try block (or put a 'raise' on line 13 after the 'except:' on line 12, instead of 'DRMAA = None'), and then paste the resulting traceback? Thanks, --nate

Cheers,

Chris

p.s. Is it just me or does 'scrambling python eggs' seem like a weird thing to say?

Chris Cole wrote:

Ok. I changed the code from: try: pkg_resources.require( "DRMAA_python" ) DRMAA = __import__( "DRMAA" ) except: DRMAA = None

to... pkg_resources.require( "DRMAA_python" ) DRMAA = __import__( "DRMAA" ) try: pkg_resources.require( "DRMAA_python" ) DRMAA = __import__( "DRMAA" ) except: DRMAA = None

Re-ran galaxy using py 2.4 and got this in the output (last few lines): galaxy.jobs.runners.local INFO 2010-03-11 15:39:10,001 starting workers galaxy.jobs.runners.local DEBUG 2010-03-11 15:39:10,007 3 workers ready Traceback (most recent call last): File "/homes/www-galaxy/galaxy_devel/lib/galaxy/web/buildapp.py", line 61, in app_factory app = UniverseApplication( global_conf = global_conf, **kwargs ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/app.py", line 67, in __init__ self.job_manager = jobs.JobManager( self ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/__init__.py", line 40, in __init__ self.dispatcher = DefaultJobDispatcher( app ) File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/__init__.py", line 776, in __init__ import runners.sge File "/homes/www-galaxy/galaxy_devel/lib/galaxy/jobs/runners/sge.py", line 11, in ? DRMAA = __import__( "DRMAA" ) File "/usr/lib64/python2.4/site-packages/DRMAA.py", line 28, in ?

Ah, here's the culprit. You have a locally-installed DRMAA_python installed that's getting in the way. If you remove the DRMAA bits from /usr/lib64/python2.4/site-packages, it should fix this problem. However, we're supposed to work around such conflicts, so it looks like there's a bug in my new version of the conflict handling code, which I'll have a look at. Thanks, --nate

File "/usr/lib64/python2.4/site-packages/cDRMAA.py", line 4, in ? import _cDRMAA ImportError: libdrmaa.so.1.0: cannot open shared object file: No such file or directory

Does this help? Cheers,

Chris