Skip to content

Instantly share code, notes, and snippets.

@mtekman
Last active October 25, 2020 22:25
Show Gist options
  • Save mtekman/5e109aa54a208390470d3178e2d70ab1 to your computer and use it in GitHub Desktop.
Save mtekman/5e109aa54a208390470d3178e2d70ab1 to your computer and use it in GitHub Desktop.
Galaxy xUnit Errors

Exception: Cannot locate xUnit report

This gist has migrated to GitLab

https://gitlab.com/mtekman/galaxy-snippets

(The copy here is archived. Please see the above link for the latest developments)

What does this mean?

Something is either wrong with your planemo, your conda, your python version, or your galaxy installation somewhere.

Did I do something wrong?

Probably. Who knows? I get this error so often every year it’s almost the most accurate way I can measure time.

Galaxy has a love/hate thing going on with Python, where it throws large errors (read: warnings, with the helpful prefix “ERROR:”) that it is using Python3, but at the same time only seems to work properly if you are using Python2. Yeah. Since 2020-08-01 this is no longer valid and both planemo and galaxy use Python3

Galaxy also has a weird conda obsession, where it uses it for everything except launching itself, and so installing planemo through conda is frowned upon.

Conda itself has a tendency to enable itself every time you start a shell, and so unless you run the deactivate code (below) to counter this and don’t use a weird shell which hides the PS1 variable, you might miss this.

What do I do?

In each of these scenarios, I am going to assume that you are in your tools-iuc repository located at ~/repos, and are looking at the tool dropletutils.

Running

planemo test dropletutils.xml

should give the error in the title

Some Checks

Check if you’re in the conda base environment

Before running planemo test, check that you are not in the conda (base) environment

conda deactivate
conda deactivate
conda deactivate

You don’t have to do it three times, I’m just angry at conda (plus conda has the ability to stack environments, so…)

If by running planemo test after this works fine, then yep you need to disable the conda base environment being called every friggin time you start a shell.

To do this do:

conda config --set auto_activate_base false

Then new shells should not have this problem anymore and you will not need to call the deactivate function.

Check if you have enough disk space

It could just be that you have run out of disk space in your temp (/tmp) directory. Some solutions to this is free up space by deleting files in your root file system, and tools like du, df, and ncdu (← this one rocks) will show you where your space is distributed.

Another option is to change where your temporary Galaxy files are written. If you have more space in another drive, e.g. /scratch, then you tell Galaxy to write files temporary there instead using the TEMP environment variable.

mkdir -p /scratch/galaxytmp
TEMP=/scratch/galaxytmp planemo test <file>

Delete Everything and Reinstall

If the above didn’t work, then we need to wipe everything related to planemo and galaxy, and do clean setup

Delete Planemo

sudo pip2 uninstall planemo virtualenv
sudo pip3 uninstall planemo virtualenv
rm -rf ~/.planemo/ ~/miniconda3/ ~/.venv

By doing this we should have planemo installed. You can verify this via

whereis planemo

which should draw a blank.

Reinstall Planemo

The best way to install planemo is via a virtualenv and using Python3.

sudo pip3 install virtualenv
virtualenv ~/.venv
. ~/.venv/bin/activate
# now in a (venv) environment
~/.venv/bin/pip3 install planemo

Clone Galaxy

So when you run planemo test it checks to see if galaxy is installed in ~/.planemo/ and if not does a shallow clone of the galaxy repo and uses that to launch Galaxy.

The version of Galaxy that planemo installs is absolute garbage though, and this right here is likely the cause of the problems.

mkdir -p ~/repos/
git clone [email protected]:galaxyproject/galaxy

Now we should pin this cloned version of galaxy, not to the unstable dev branch, but to a release version.

cd ~/repos/galaxy
git checkout release_20.01

This should enable a stable version of galaxy to be used when we ask planemo to target it

Point Planemo to Galaxy

So now we can simply run

. ~/.venv/bin/activate
planemo test dropletutils --galaxy_root=~/repos/galaxy

and this should run fine.

If you want to the --galaxy_root part to be automatic and not have to type it each time, then we need to create a config file for planemo and tell it where the galaxy root is.

. ~/.venv/bin/activate
planemo config_init
sed -i 's|#galaxy_root:.*|galaxy_root: ~/repos/galaxy|' ~/.planemo.yml

Now you can just run

. ~/.venv/bin/activate
planemo test dropletutils

and all should work well.

Do I really need to call planemo in a .venv?

Yes. Trust me, if you install planemo globally it works well for a few weeks, then you do a system update and your python libraries are all messed up. Just use the virtual environment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment