Galaxy miscellanea

Odds and ends and the surprising.


If you are serving the installation with a proxy redirect (e.g. the galaxy server is running on port 7070 but is being redirect by Apache to appear at port 80 on /galaxy), while you can access Galaxy at both addresses, login will only work on one. This is because Galaxy tracks where you are with cookies that record the path of the instance you are using, so you can use more than one Galaxy instance. This creates a slightly strange behaviour where you can login on the other port/path but are instantly logged out.

The mixup between these cookies can leave you in a situation where you can't login to your account. The solution is to delete your cookies.


While uploading a sequence file (Upload File), a harmless error was issued that disrupted the upload:

/home/f0/paul/Installed/lib/python2.6/site-packages/pytz/ DeprecationWarning: the sets module is deprecated from sets import Set

This can be easily fixed by installing the latest version of pytz:

% easy_install pytz

Tool config

Interestingly, if your tool_conf.xml entry is incorrect (e.g. pointing at a non-existent directory), an error is written to the log and the tool just simply not appear in the menu. Note that changes to the config file will require a restart to be detected.

Duplicate tool ids

An interesting way to make an invisible mistake: if you register tools with the same id (the id in the specific tool configuration file), only the first one gets registered, the others silently fail:

<tool id="hpa_seqtools_datelabel-seqs" name="Do this thing"> ... <tool id="hpa_seqtools_datelabel-seqs" name="Do the other thing">

The only way you can tell (apart from the tool not showing up) is to look in the output of a Galaxy instance run from the commandline. It prints the id of each tool being registered.

Only sleeping

It _seems_ as if when Galaxy has not been used for a while, going to its address produces a strange traceback. However, immediately reloading the page shows the usual appearance. It's unclear whether it is Galaxy or Apache, but it's just a cosmetic annoyance. This may be the result of our local setup.

The BioPython that wasn't there

An odd incident that Galaxy provoked, although it was not at fault: Biopython was installed on the Galaxy python (the egg is in site-packages), but tools that imported it failed, saying:

from Bio import SeqIO ImportError: No module named Bio

This perplexed me for a while, until I went to the extent of unzipping the Biopython egg. It contained nothing but the metadata (i.e. the EGG-INFO), having no actual module or executables.

I realise now that I'd seen this before when a library installation fails or is aborted. The lib can get "half-installed", leading to the above problems. Solution: manually delete the egg, edit it's line out of easy-install.pth and reinstall the lib.

Templates not all there

The templating for building commandlines lacks one feature of fully blown Cheetah templates - you can't include Python code between angled braces, i.e.:

<% foo = "bar" %> #this won't work

This is because the xml parser can't cope with the angled brackets. No biggie.

Template debugging

Some helpful tip from the galaxy-developers list.

You can embed a direct python command after a ”#silent” directive. This can be used to print something to STDERR, that won't appear in the generated tool commandline:

#silent sys.stderr.write("Hello World from cheetah generated code ");

All available parameters in a template can be dumped with:

#silent sys.stderr.write("!!!! Cheetah Template Variables !!!! ") #silent sys.stderr.write(" searchList = '%s' " % (str($searchList)) ) #silent sys.stderr.write("!!!! end-of-list !!!! ")

#breakpoint stops template compilation at any given point and can be used to bisect template problems. i.e. If the template compiled fine, then all the statements above the breakpoint are valid.

Parameter sanitizing

Something that is there in the documentation, but is easy to miss: Galaxy filters tool form text. As a result, a field like %y-%m-%d will get passed to the tool as Xy-Xm-Xd. You get around this by giving a "sanitizer" tag to the relevant param. This can switch off param cleaning, set the characters to be filtered and suggest substitutions:

<param name="date_fmt" type="text" label="Date format"> <sanitizer> <valid initial="string.printable"> <remove value="&apos;"/> </valid> </sanitizer> </param>

STDERR is an error

If a tool writes anything to stderr, this is interpreted as a failure.