it’s pretty much the only package there that we still need in non-deprecated iuc tools
I’ll open a PR, let’s see if it gets in
Is this for the container tests? I remember that in the first iteration there was only one failing emboss tool which I tried to fix here galaxyproject/tools-iuc#2725.
that was emboss 5 only
The linter seems broken though,
should_not_be_noarch_source when there is no noarch makes no sense
to both
Question, I added a new version of a tool to bioconda-recipes. I'd like my galaxy wrapper to use that new version (no interface changes to the wrapper - just a bug fix). I updated the version attribute of the requirement tag in the wrapper's xml, but when I run
planemo serve, it's still using the older version. What change must I make to have it use the newer bioconda-recipes version? (Note, if I do conda install toolname on the command line, it installs the new version.)
Hmmm. It's is still using version
2.006 instead of 2.0013. I think I probably need to bump the wrapper version. I was using some weird version spec and I see that the latest spec says that the <tool version attribute should be tool_version+wrapper_version. I only had wrapper_version.
Sure, although I accidentally got it to run the new version - and I'm not sure why it worked. I accidentally ran
planemo serve from the main tool repo directory instead of the specific tool directory and it happened to use the new version when I ran it. Now if I run it from either, it uses the new version. I don't understand it. https://github.com/hepcat72/robs_galaxy_tools/tree/vcfsc13/tools/vcfsamplecompare
glad it works now
It might be a nice project to replace that with implicit collection building, I think it could unify some code paths
but that’s just a guess, it might also become more messy
Agree completely. Any other idea on how to set the format of the collection elements? In my case it would be nice to discover data sets, but only get the name from this and take the format from the corresponding input.
Background: OpenMS often requires that the output files have specific extensions which are (of course) not equal to the Galaxy extensions. The only idea I had so far is to rename the files after creation, such that discovering works.
From tool programming perspective it seems best (at least in the amount of needed code) to have an input and an output collection. But I'm wondering about the usability if I force the users into forming a collection. Using a
multiple="true" input is just more flexible.
ok, exaggrating here, but I easily get lost when a tool produces more than 5 outputs
this would be less of an issue if you produce a collection output
I was talking about the history
the history should be as simple as possible IMO
though heterogenous collections are a pain as well
as you would create there
hmm, not sure we have a great solution there
I guess discovering the output and sniffing could work ?
but if you know the formats it’s probably best to rename as the sniffers aren’t perfect