I’m running my own Galaxy and I want to use it to run the SPAdes assembler as part of a Galaxy pipeline, instead of running SPAdes at my command line with shell scripts.

Ostensibly, this should be easy to do by simply installing a SPAdes module in Galaxy from a friendly Tool Shed.

Is SPAdes in the Tool Shed?

Apparently.

Can I install it?

Apparently.

Is it available to use as a tool once installed?

Apparently. But I bet you’re starting to guess where this is going.

Does it work?

I’ve run SPAdes successfully on this chloroplast data before. Driven it with shell scripts and bpipe scripts even, and on the very same laptop that I’m using to run this local instance of Galaxy. So I know that all of the pieces are in place for this calculation to work and that it will run in a few minutes. But sadly, that is not the case from inside Galaxy.

But why not?

This should be the easiest thing ever. Very reliable program, pre-vetted data set, tool in the Tool Shed, right? So what’s the error? Double click on data set 29 to expand its menu, and click the bug/info button to see what the error message is.

Whoops.  Apparently the tool authors didn’t make sure that the correct executables get delivered when someone installs the tool from an OSX machine, even though SPAdes runs on OSX.

So what can we do?

In response to my forum question, the Galaxy team tells me that I can just point my local Galaxy at a different executable so I don’t have to have more than one on my machine, but not really how to do that. But it can be done. That answer could mean one of a few things:

1. I need to symlink or move my working SPAdes executable to the location where Galaxy is looking for the non-working one
2. I need to change some tool definition file somewhere so that Galaxy looks for a working SPAdes executable
3. I need to change the installer somehow so that it gets the correct executables from the web to begin with

And of course there’s always the option of just contacting the SPAdes guys and asking them to fix their installer, but I’m an impatient person. Before I ask more questions, let’s try out option 1, which is easy to do. Because I’m sure if this was hard, the Galaxy people would have given me a more detailed answer.

Galaxy puts SPAdes in:
/Users/cgibas/galaxy-dist/tool-dependencies/spades/3.0.0/lionelguy/spades/1f1943b29266/bin


There are seven executables there.

My local SPAdes is in:

/Users/cgibas/Applications/SPAdes-3.1.0/bin

My SPAdes is version 3.1.0, but it has the same executable names and as far as I can tell uses the same command line flags and such as the previous version, so it’s fairly likely I can fake out Galaxy and not have to reconfigure the tool for the new version. Deep in the Galaxy tool-dependencies directory, in the directory where Galaxy expects to find a SPAdes bin directory, I can:

mv bin bin-old
ln -s  ~/Applications/SPAdes-3.1.0/bin .


(move the existing SPAdes bin to another directory name that’s not in the Galaxy path, and then make a symbolic linked copy of my working SPAdes in its place).

Now I can go back into galaxy-dist, start up the Galaxy server on localhost, and try my job again. Select the contigs set on your failed run and click on the little recycle icon to start it again. Galaxy should recover your chosen parameters, too:

Et voila, it appears to work:

And the results are, in fact, contigs:

Easy explanation, for the win!