planemo shed_updatethe gemini tools after galaxyproject/tools-iuc#2147 is merged
Failed to write HTML output due to errors processing the XML: training_set@primary_sequences missing training_set@primary_count missing training_set@primary_positions missing training_set@control_sequences missing training_set@control_count missing training_set@control_positions missing at /usr/local/meme/libexec/meme-5.0.1/meme_xml_to_html line 453, <$fh> line 165.
The tool IDs all match now (via shed updates), but I had installed an earlier version which had a different tool ID. I don't know if anyone else installed that older version. Hopefully not. If they did, they may have the same trouble I did where it wouldn't update the tool to the latest version.
Anyway, I have another question. I've been tweaking my lumpyexpress galaxy wrapper to try and work around an issue with lumpyexpress (for which I submitted a PR - but I guess I'm just impatient). I implemented a workaround, did
planemo test and I even tested it on my own dev version of galaxy. Then I put it on the test toolshed, installed it in my dev version of galaxy and tested it again. Everything works. But once I install it on an instance of galaxy on another machine via the toolshed and test it, it fails. How can I avoid such failures?
So, for instance, I wanted to do something that I thought would be very simple: I needed to change the value of a variable in a script that lumpyexpress calls from 1000 to 1. So I wanted to copy a script from the lumpy package to the workdir, change the value of a variable set on one line of the script, copy the config file to set a new location for that script, and run lumpyexpress (supplying the new config file in the workdir). Doing that worked on my machine, but when it runs somewhere else, it complains about a missing bamlib.py. I don't care about this particular effort with lumpyexpress. It will eventually get fixed in lumpy itself. I was just being impatient. But in general, unless I'm submitting a package to conda-recipes, how can I test that my galaxy wrapper is going to work elsewhere? Is there a local circleci I can run to do
planemo test on?
would be very simple: I needed to change the value of a variable in a script that lumpyexpress calls from 1000 to 1
That doesn't sound simple at all, that sounds like it would be very likely to break. The more reasonable approach IMO is to package up your fork of lumpy, push it to your conda channel and install from there.
But in general, unless I'm submitting a package to conda-recipes, how can I test that my galaxy wrapper is going to work elsewhere? Is there a local circleci I can run to do planemo test on?
This is a fairly universal problem for which there are many solutions. I guess the easiest is to build on a service like travis or circle-ci (that's what the IUC is doing), or you can use a dockerized galaxy using planemo. You'll want to isolate your development environment from your tests. The other, qicker, but not as thorough alternative is to be careful to have nothing global in your environment
Thanks @mvdbeek. I had considered forking, but I imagine the developer will eventually fix the issue. I guess I was just being impatient. I reverted my tool to just suffer the failure and ping the developer once in awhile.
And thanks for the advice about testing. I will definitely try out one of your suggestions.