Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Snippy has a samtools version dependency conflict - Main only #283
Tool: snippy Snippy finds SNPs between a haploid reference genome and your NGS sequence reads. (Galaxy Version 4.4.5+galaxy2)
Impacted Server(s): Galaxy Main https://usegalaxy.org
Related: Included in updated containerized tool tests here (marked as fixed): galaxyproject/tools-iuc#2701
Thank you for your help. I see that the test was passed by the EU server. However, you can see in "6 snippy on data 2 and data 1 snps table" that no SNPs were detected.
I tested snippy with my WGS contigs in Fasta format. Then, I tested snippy-core and the tool generated the following error.
This is snippy-core 4.4.5
Thanks - right, the test cases I included for snippy Snippy finds SNPs between a haploid reference genome and your NGS sequence reads. have two test. The first is a negative result (no SNPs) and the second test is a positive result (some SNPs). The same "reference genome" was used for both tests -- what varied are the F/R reads only.
Neither of these is an official automated test case -- I just cherry-picked out of the existing test's data a few files that would produce results for what I wanted to check. These were limited tests in scope, on purpose.
Check 1) that all dependencies are available on the servers when all outputs are selected. ORG has a mismatched samtools dependency (what this ticket is reporting). EU is fine.
Check 2) that situations, where there is a "no SNP" result, are handled in a way that is meaningful. Eg: do not cause the tool to fail with an obscure/untrapped/unreported reason due to the technical handling of the data (input or output). ORG didn't get far enough to produce any result for either test ("SNPs" vs "no SNP") due to the dependency issue. EU made it through both and I think the results are expected and clear. The first test (the "no SNP" result) outputs an empty VCF. It just has headers, no data lines for SNPs. That is probably the first output dataset a person would "sanity-check" after a snippy run, plus the other logs and outputs support that same "no SNPs" called result. The inputs are valid technically, so I think it is appropriate that the tool did not fail.
I didn't run any tests for snippy-core Combine multiple Snippy outputs into a core SNP alignment. That said, I think the result you report is expected if the "no SNP" snippy test run data was input. In short, the tool produces a warning that the input didn't have any meaningful content to act on. The inputs are NOT valid technically in this case, I think it is appropriate that the tool failed.
If you are getting the same result with your own data with snippy-core (this part wasn't clear), then it also has no SNPs called in the snippy input and snippy-core wouldn't have any data to act on.
I would expect snippy-clean_full_aln Replace any non-standard sequence characters in snippy 'core.full.aln' file. to also fail, if the input was invalid (empty).
I have no problem to perform snippy analysis using as input NGS sequence reads. However, when the inputs are complete or draft genomes download from NCBI, then snippy fails to call SNPs.
Please see this share history for more details.
4: snippy on data 1 snps table. 1 line, 0 SNPs identified
15: snippy on data 11 and data 12 snps table. 78,562 lines, 78,562 SNPs identified
Snippy expects NGS reads as an input. Please see: https://github.com/tseemann/snippy.
The Galaxy wrapper repository and the underlying tool are also linked from MTS (Main Tool Shed, aka the Galaxy "app store"). Link above but also here again: https://toolshed.g2.bx.psu.edu/view/iuc/snippy/3fe8ef358d66