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
there is a mismatch in the colum definition in extract_genomic_dna and the data manager
I suppose the data manager one should win
Nicola Soranzo
@nsoranzo
There's a definition also in Galaxy config/tool_data_table_conf.xml.sample , from which the data manager correctly derives.
Since 2015, commit galaxyproject/galaxy@30f1815
Marius van den Beek
@mvdbeek
does anyone know why we put emboss5 in the IUC conda channel ?
it’s pretty much the only package there that we still need in non-deprecated iuc tools
M Bernt
@bernt-matthias
Marius van den Beek
@mvdbeek
could be
I’ll open a PR, let’s see if it gets in
M Bernt
@bernt-matthias
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.
Marius van den Beek
@mvdbeek
yeah, and now we need to build a container that includes the IUC channel, while we already had a container
that was emboss 5 only
Marius van den Beek
@mvdbeek
do all the emboss 5 tools need perl to run / should I add perl to the run requirements ?
M Bernt
@bernt-matthias
I think its only for the 4 perl script that are included in the galaxy wrappers. I guess requirements are fine.
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