Snippy has a samtools version dependency conflict - Main only

[jennaj]

Tool: snippy Snippy finds SNPs between a haploid reference genome and your NGS sequence reads. (Galaxy Version 4.4.5+galaxy2)

MTS: https://toolshed.g2.bx.psu.edu/view/iuc/snippy/3fe8ef358d66

Impacted Server(s): Galaxy Main https://usegalaxy.org

Tests:

• EU (pass) https://usegalaxy.eu/u/jenj/h/test-snippy-dependencies
• Main (fail) https://usegalaxy.org/u/jen/h/test-snippy-dependencies

Error:

[13:15:14] Need samtools --version >= 1.7 but you have 1.10 - please upgrade it.

Related: Included in updated containerized tool tests here (marked as fixed): galaxyproject/tools-iuc#2701

@natefoo @mvdbeek -- doesn't appear to be resolved yet. Is this a fix for the server or does it need an /tools-iuc ticket/update?

[davitero]

Hi @jennaj

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
Obtained from http://github.com/tseemann/snippy
Enabling bundled tools.
Found any2fasta - /usr/local/tools/_conda/envs/mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e/binaries/noarch/any2fasta
Found samtools - /usr/local/tools/_conda/envs/mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e/bin/samtools
Found minimap2 - /usr/local/tools/_conda/envs/mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e/bin/minimap2
Found bedtools - /usr/local/tools/_conda/envs/mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e/bin/bedtools
Found snp-sites - /usr/local/tools/_conda/envs/mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e/bin/snp-sites
Saving reference FASTA: core.ref.fa
This is any2fasta 0.4.2
Opening 'ref.fna'
Detected FASTA format
Read 66311 lines from 'ref.fna'
Wrote 1 sequences from FASTA file.
Processed 1 files.
Done.
Loaded 1 sequences totalling 4641652 bp.
Will mask 0 regions totalling 0 bp ~ 0.00%
0 LOIE01_1_fsa_nt_uncompressed snp=0 del=0 ins=0 het=0 unaligned=4509755
1 LPWV01_fasta snp=0 del=0 ins=0 het=0 unaligned=4511031
Opening: core.tab
Opening: core.vcf
Processing contig: gi|556503834|ref|NC_000913.3|
Generating core.full.aln
Creating TSV file: core.txt
Running: snp-sites -c -o core.aln core.full.aln
Warning: No SNPs were detected so there is nothing to output.
ERROR: Could not run: snp-sites -c -o core.aln core.full.aln

[jennaj]

@davitero

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.

Warning: No SNPs were detected so there is nothing to output.
ERROR: Could not run: snp-sites -c -o core.aln core.full.aln

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).

[davitero]

Hi @jennaj

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.

https://usegalaxy.eu/u/davitero/h/e-coli-snps

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

[jennaj]

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

[natefoo]

Sorry, I'd downgraded samtools to 1.9 in the __snippy@4.4.5 conda environment, not realizing that this tool is using a mulled environment (mulled-v1-8b12e3c0ffd8bb115bc7f1ba98dc3e6f2437163780e6bedf407dfe51c8fc8d1e). It should be fixed now.

[mvdbeek]

Did you also downgrade bcftools in that enviroment ? Has the same issue.

[natefoo]

Yes, downgrading samtools downgraded bcftools and htslib.

[jennaj]

Retested and while still running, would have failed by now if had the same issue. finished successfully!

Thanks and closing!