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
Anton Nekrutenko
@nekrut
what would bump it up front?
Marius van den Beek
@mvdbeek
4.3+T.galaxy1 would
Anton Nekrutenko
@nekrut
So <token name="@wrapper_version@“>4.3+T.galaxy1</token>
Marius van den Beek
@mvdbeek
Yeah. Alternatively there's also https://github.com/galaxyproject/tools-iuc/pull/1798/files, which uses 4.3.1.1
Anton Nekrutenko
@nekrut
but in the case how do we know that it is a ’T’ version?
Marius van den Beek
@mvdbeek
both would be in front of the lineage, I prefer my version because you can still recognise the upstream version
Anton Nekrutenko
@nekrut
ok
Dave B.
@davebx
@mvdbeek of course the one that parses correctly was the one combination of 4, 3, and T that I didn't try
Martin Cech
@martenson
seems like we have a first exception to an unborn standard
@mvdbeek ad your comment above on removing tools - nobody is proposing to remove old snpeff I think
since it parses as legacy and poses no known security vulnerability we can just leave it there forever
Marius van den Beek
@mvdbeek
I read something about removing tools above. Either way it'd be good to have a mechanism for security vulnerabilities (don't run at all) and known broken versions (dependency issues are probably a common problem, binaries with an expiration date, all those we should actively let the user know that he can run the tool / workflow, but that its probably not going to work)
Martin Cech
@martenson
That would be really good, agreed.
As of the 'lost' parameter, can't you find them without rerunning? On the dataset info?
Marius van den Beek
@mvdbeek
No, we just store the state, but that doesn't include the label etc. In principle you could display the parameters name and value, but without the label it's hard to understand
Jennifer Hillman-Jackson
@jennaj
Params set up on certain tool forms can get fairly complicated, nested, etc. So, agree- matching these up -- tool form labels and what is reported on job details -- isn't always an obvious match.
We could improve that. But I find reruns with tool upgrades very very convenient. We should keep that if at all possible
+1 on marking tool in UI with known issues somehow. many good ideas so far.
Slugger70
@Slugger70
I'm updating the prokka tool to the new released version 1.13. It is currently owned by crs4 but in the iuc repo. Should I change the owner to iuc? Or should we leave it?
Nicola Soranzo
@nsoranzo
Leave it, we've being doing that for tools that are moved to the tools-iuc repo after being on the Tool Shed for a while under a different owner
iuc has write and admin permissions
Slugger70
@Slugger70
cool thanks @nsoranzo
Anton Nekrutenko
@nekrut
if I run freebayes using ‘Merge output VCFs’ does it actually run separate jobs and them merges, or does merge BAMs and then runs a single job?
@Delphine-L look at @Slugger70 post above. Do we need to do anything with prokka here?
Jennifer Hillman-Jackson
@jennaj
There is a question about two IUC data managers at Biostars. I'm not sure what the problem is - @bebatut these are yours, yes? Could you help troubleshoot?
I noticed that one of these has a bad link to the dev repo - maybe it moved? https://toolshed.g2.bx.psu.edu/view/iuc/data_manager_humann2_database_downloader/9244804f69a7
Marius van den Beek
@mvdbeek
I think we'll have to come to a decision at some point about how to handle errors in pipes e.g galaxyproject/tools-iuc#1733
Are we OK to assume bash/zsh and set pipefail, or do we want to instead recommend mkfifo as a workaround?
bwa / bowtie2 / hisat2 are all affected, since we pipe the output into samtools
is there an obvious downside to using mkfifo / named pipes?
Brad Langhorst
@bwlang
IHMO, pipefail is easier to implement than named pipes - and I’ve never seen a system without bash.
Marius van den Beek
@mvdbeek
agreed, we can easily handle that on the framework level (we already have strict="True", which prepends set -e)
I think the concern is execution in containers
which may not have bash
Brad Langhorst
@bwlang
really? that seems like a pretty minimal requirement...
Marius van den Beek
@mvdbeek
busybox doesn't come with bash I think, neither do the biocontainers
last time i checked ...
docker: Error response from daemon: oci runtime error: container_linux.go:265: starting container process caused "exec: \"bash\": executable file not found in $PATH".
that's busybox
Brad Langhorst
@bwlang
loos like -o pipefail was added to busybox 22 November 2010 -- BusyBox 1.18.0 (unstable)
Marius van den Beek
@mvdbeek
Oh, that is nice
Brad Langhorst
@bwlang
any other shells to worry about
?
Marius van den Beek
@mvdbeek
dash
which is the default in ubuntu but doesn't support pipefail
but ubuntu comes with bash
Brad Langhorst
@bwlang
this might be relevant: http://cfajohnson.com/shell/cus-faq-2.html#Q11 - looks pretty damn nasty to me.
Marius van den Beek
@mvdbeek
you mean option d ?
Brad Langhorst
@bwlang
yup