Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Marius van den Beek
@mvdbeek
is that locally ?
(I think the PR might be missing a .shed.yml file, nothing got tested)
scholtalbers
@scholtalbers
yeah indeed, cause the other tests are not finished yet and should be throwing errors in any case
its not a new set of tools, they are existing, the shed.yml should not be updated?
Marius van den Beek
@mvdbeek
is ~/.planemo/gx_repo up to date ?
sometimes it get's stuck on an old galaxy -- just rm it and try again ?
scholtalbers
@scholtalbers
might be will try
Marius van den Beek
@mvdbeek
for me it fails like this:
---------------------- >> begin tool stdout << -----------------------
Deduplicating with: 'deduplicate_bismark -s submitted_reads.bam --bam'
Processing single-end Bismark output file(s) (SAM format):
submitted_reads.bam


If there are several alignments to a single position in the genome the first alignment will be chosen. Since the input files are not in any way sorted this is a near-enough random selection of reads.

Checking file >>submitted_reads.bam<< for signs of file truncation...

samtools view: writing to standard output failed: Broken pipe
samtools view: error closing standard output: -1

Output file is: submitted_reads.deduplicated.bam


Total number of alignments analysed in submitted_reads.bam:    554
Total number duplicated alignments removed:    50 (9.03%)
Duplicated alignments were found at:    44 different position(s)

Total count of deduplicated leftover sequences: 504 (90.97% of total)

skipping header line:    @HD    VN:1.0    SO:queryname
skipping header line:    @SQ    SN:chrY_JH584300_random    LN:182347
skipping header line:    @SQ    SN:chrY_JH584301_random    LN:259875
skipping header line:    @SQ    SN:chrY_JH584302_random    LN:155838
skipping header line:    @SQ    SN:chrY_JH584303_random    LN:158099
skipping header line:    @PG    ID:Bismark    VN:v0.19.1    CL:"bismark --bam --gzip --temp_dir /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpn4m609_i -o /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpn4m609_i/results --quiet --fastq -L 20 -D 15 -R 2 --un --ambiguous /var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpe8nkca8w /private/var/folders/cf/k7c5rjhj1sggk6x8z1jnw4b80000gp/T/tmpDiq_J8/files/000/dataset_2.dat"

----------------------- >> end tool stdout << ------------------------

---------------------- >> begin tool stderr << -----------------------

----------------------- >> end tool stderr << ------------------------

FAIL
which from the datatype perspective looks OK. might even just be an issue with how samtools view is used inside bismark
scholtalbers
@scholtalbers
yes thanks @mvdbeek it was the galaxy version
Marius van den Beek
@mvdbeek
cool, good luck!
scholtalbers
@scholtalbers
the failures now are probably from the missing expected outputs :)
thx for the patience - will have to continue this later
Marius van den Beek
@mvdbeek
sure, np
John Chilton
@jmchilton
@mvdbeek I have a worry that has been growing. Do you think auto-propagating the group:* tags is a mistake - because we are too aggressive with our tag propagation. The simplest way to think about it is a imagine a collection with two group tags in the HDAs, then you run a mapping step or something and resulting collection has those group tags on the HDCA itself. This so far is fine - the HDCA does have those groups so that sort of makes sense, then imagine running a structured_like tool on the result - the input to the tool is the HDCA - so every resulting HDA will get all the auto propagated tags (name tags and group tags). I think anyway. Can we do a better job auto propagating or do we just need to disable it or hide it behind a flag for 18.09? I was also contemplating group and autogroup tags - to the tool they could look the same but they'd behave different in this behavior
I'm ultimately nervous about committing to this behavior until we see it works for a broad range of workflows - maybe just sticking with your tagging tool for 18.09 is the way to go
Marius van den Beek
@mvdbeek
Going with the tagging tool / the apply rules tool sounds perfectly reasonable to me
for a first shot, that is
the concerns you have also apply to name tags, which already have this behavior, and for some scenarios like the one you described they just dont work
John Chilton
@jmchilton
is there a tweak to the propagation we can do to fix this all - like prevent collection contents from propagating up to HDCAs? Fixing nametags would probably fix group tags then also
Or do we just not have enough metadata to infer what should happen and we should give up
Marius van den Beek
@mvdbeek
It would always break down for scenarios where we don't know which tag should propagate. If you subtract input1 from input2 (we do that quite often with bedtools for instance) -- which tag should the output have ?
I think that depends on the context
So in workflows I drop certain tags from an output using PJAs, that is quite flexible and I haven't had the scenario where that didn't work
John Chilton
@jmchilton
Is that for getting nametags working properly or are you already using the newer stuff?
Marius van den Beek
@mvdbeek
Up to now only nametags, for the deseq2 workflow everything works absolutely beatiful
but the PJAs should work for all kinds of tags
btw a colleague of mine asked me recently why he can't name outputs in the tool form -- maybe tool form PJAs would be worth thinking about ?
John Chilton
@jmchilton
100% agree - anything to capture more metadata for valid workflow extraction from histories
galaxybot
@galaxybot
[Ferris] If one were to move a Galaxy install from one directory to the other, what would one have to do to get conda to move as well? Conda keeps trying to use python from the old directory
Marius van den Beek
@mvdbeek
setconda_prefix in the galaxy.ini / galaxy.yml to the new conda directory
Nate Coraor
@natefoo
does anyone know travis-fu to run something (a pre-stage?) that can determine what additional stages should be run and set something to do that conditionally?
maybe circleci is a better fit for this
Nicola Soranzo
@nsoranzo
Nate Coraor
@natefoo
yeah, i've looked in to the stages but i can't see a way to have one stage set something that can be used in a conditional (either via if: or in a script) in a later stage
Nicola Soranzo
@nsoranzo
I don't think that's possible in Travis
Nate Coraor
@natefoo
yeah. =( i can have it check on each executor (job? the terminology is muddled) but that requires a lot of repetition. for something you already "know"
although repetition is not exactly uncommon in CI. =)
Nicola Soranzo
@nsoranzo
Indeed
Marius van den Beek
@mvdbeek
what is it for ? is there not a chance a single build would be enough ? those can share artifacts with the deploy stage IIRC
Nicola Soranzo
@nsoranzo
And you can use macros in .travis.yml, if that helps
Nate Coraor
@natefoo
it's for starforge wheel building - wheels are either platform, pure python (needs seperate 2 and 3 builds), or pure python universal (2 and 3 in one wheel)
Nicola Soranzo
@nsoranzo
Look for py3_addons in https://github.com/galaxyproject/galaxy/blob/dev/.travis.yml for macro syntax.
Nate Coraor
@natefoo
right now over in galaxyproject/starforge-recipes it can build platform ones w/ matrix jobs out to linux and macos, 2.7, 3.4, 3.5, 3.6
@nsoranzo: oh using standard YAML references?
Nicola Soranzo
@nsoranzo
Speaking of which, we need to build wheels for the recently-released uwsgi 2.0.17.1 , building the previous 2.0.17 on Fedora 28 is broken due to its new glibc
@natefoo Yes (I think)
Nate Coraor
@natefoo
yeah it should be possible in its current state