by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 2019 17:58
    jorgemachucav starred galaxyproject/tools-iuc
  • Jan 31 2019 17:45
    bebatut opened #2270
  • Jan 31 2019 16:18
    cpreviti synchronize #2267
  • Jan 31 2019 14:15
    cpreviti synchronize #2267
  • Jan 31 2019 12:42
    bernt-matthias review_requested #2269
  • Jan 31 2019 12:42
    bernt-matthias edited #2269
  • Jan 31 2019 12:41
    bernt-matthias edited #2269
  • Jan 31 2019 12:40
    bernt-matthias synchronize #2269
  • Jan 31 2019 12:13
    cpreviti commented #2267
  • Jan 31 2019 12:07
    nsoranzo commented #2267
  • Jan 31 2019 12:01
    cpreviti synchronize #2267
  • Jan 31 2019 11:21
    cpreviti synchronize #2267
  • Jan 31 2019 09:47
    cpreviti synchronize #2267
  • Jan 31 2019 09:27
    cpreviti synchronize #2267
  • Jan 30 2019 20:38
    bernt-matthias commented #2131
  • Jan 30 2019 20:19
    hepcat72 commented #2239
  • Jan 30 2019 19:50
    lparsons commented #2239
  • Jan 30 2019 18:36
    bgruening commented #2268
  • Jan 30 2019 15:23
    nsoranzo commented #2268
  • Jan 30 2019 15:23
    nsoranzo commented #2267
Marius van den Beek
@mvdbeek
Marius van den Beek
@mvdbeek
@nsoranzo the old source tarball is at ftp://emboss.open-bio.org/pub/EMBOSS/old/5.0.0/EMBOSS-5.0.0.tar.gz, should we use that instead of cheating our way around the linter ?
Nicola Soranzo
@nsoranzo
So compile it?
The linter seems broken though, should_not_be_noarch_source when there is no noarch makes no sense
Marius van den Beek
@mvdbeek
yep
to both
Robert Leach
@hepcat72
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.)
Martin Cech
@martenson
@hepcat72 maybe some conda cache clearing is needed? It should work.
Robert Leach
@hepcat72
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.
Robert Leach
@hepcat72
Gee. It still uses 2.006. If I do a which on the tool before doing planemo serve, it's the correct version.
Martin Cech
@martenson
can you share the tool?
Robert Leach
@hepcat72
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
Martin Cech
@martenson
sounds like it could be some caching issue
glad it works now
M Bernt
@bernt-matthias
Is it correct that for <param name="in" multiple="true"> there is atm no way to create a list with the same name of elements, i.e. like<collection name="out" type="list" structured_like="in" inherit_format="true">? Would be really handy.
Marius van den Beek
@mvdbeek
yes, that’s right, and I wouldn’t implement this. If you need to derive a structure you should use a collection input
M Bernt
@bernt-matthias
Hmm. Have to think about this.
Marius van den Beek
@mvdbeek
You can take a look around the code, you’ll see that multiple=“true” is very different from a collection input
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
M Bernt
@bernt-matthias

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.

Marius van den Beek
@mvdbeek
is this a 1 to 1 relationship ? each input produces one output but you need all the inputs for tool execution ?
M Bernt
@bernt-matthias
Yep, exactly.
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.
Marius van den Beek
@mvdbeek
isn’t this going to be quite messy if you have more than 2 inputs ?
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
M Bernt
@bernt-matthias
I just create a folder for each input and output for storing files and links.
Marius van den Beek
@mvdbeek
you mean in the tool ?
I was talking about the history
M Bernt
@bernt-matthias
Yes - in the tool command sections
Marius van den Beek
@mvdbeek
the tool should be as complex as necessary
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
M Bernt
@bernt-matthias
Most of the time there is one output (and potentially some optional ones) .. so the user can decide how much mess is wanted/needed .. the outputs are differentiated by name.
Marius van den Beek
@mvdbeek
but if you just have one output why would you want to use inherit_format ?
do you have the tool somewhere ?
M Bernt
@bernt-matthias

Sniffing might be an option .. and appealingly simple .. but there are some very under specified data types used in OpenMS for which sniffing does not work.

I could post the a ctd file that I try to autotranslate.

In the end I just want to set the format of the output and I know that it is the same as the input, but there are multiple possible input formats.
Marius van den Beek
@mvdbeek
how do you derive the format from multiple inputs ?
I am still lost here. This should work fine with collection input if you set inherit_format. If you use multiple=“true” you need to create an arbitrary number of outputs using discover_datasets. This will be difficult to impossible to use in workflows
M Bernt
@bernt-matthias
Good points. What is the limiting point for the usability in workflows, i.e. in which case(s) multiple=“true” inputs do not work in work flows?
Marius van den Beek
@mvdbeek
oh, that works fine, discovered outputs aren’t usable
there’s no output to attach them to
there is a single, primary dataset, but I guess that won’t be of much/any use
M Bernt
@bernt-matthias

So if you have data with discover_outputs (which I would understand) or also if you have a collection with discover_outputs? I will always have the later case.

... but I have to admit that I have a few cases where I abuses data+discover to set the format, but its always just a single data set .. so in this case the single data set is of use :) Nice