dhtslib provides D bindings, high-level abstractions, and additional functionality for htslib, the most widely-used library for manipulation of high-throughput sequencing data.
dhtslibas a dependency to
Object-oriented, idomatic D wrappers are available for:
- SAM/BAM/CRAM files and streams (
- VCF/BCF files (
- BGZF compressed files (
- FASTA indexes (
- Tabix-indexed files (
Additional functionality is provided for:
- GFF(2|3) files and streams (
- BED files and streams (
- FASTQ files and streams (
- Compile-time coordinate system (
dhtslib.coordinates) to avoid off-by-one errors
All htslib bindings can be found under the
htslibnamespace (in prior versions they were under
dhtlsib.htslib). These can be used directly as you would with
Direct bindings to htslib C API are available as submodules under the
htslibnamespace. Naming remains the same as the original
.hinclude files. For example,
import htslib.faidxfor direct access to the C function calls. Where the OOP wrappers manage their own data along the the D garbage collector, these functions use traditional C memory management (or lack thereof). The current compatible htslib versions are 1.10+.
- cram (untested)
- hts_expr (untested)
- hts_os (untested)
- kbitset (untested)
- kfunc (untested)
- knetfile (untested)
- synced_bcf_reader (untested)
- thread_pool (untested)
- vcf_sweep (untested)
- vcfutils (untested)
Missing or work-in-progress:
dstep has matured and is an incredibly powerful tool for machine-assisted C-to-D translation. We've used dstep for the majority of bindings in the since version v0.11.0. After dstep translation, we port inline functions by hand as they are not translated, tweak some macros into templates (done although dstep already does an amazing job on simple
#definemacros translating to D templates!), and update the documentation comments to ddoc format.
Q: Does this work with the latest htslib?
A: bioD, as a more general bioinformatics framework, is more comparable to bio-python, bio-ruby, bio-rust, etc. bioD does have some excellent hts file format (BGZF and SAM) handling, and at one time sambamba, which relied on it, was faster than samtools. However, the development resources poured into
htsliboverall are tremendous, and we wish to leverage that rather than writing VCF, tabix, etc. code from scratch.
Q: How does this compare to bio-Rust's htslib bindings?
A: We love Rust, but dhtslib has way more complete bindings and more and better high level constructs. We have also implemented a novel compile-time type-safe coordinate system to mostly avoid off-by-one errors.
Q: Why am I getting a segfault?
A: It's easy to get a segfault by using the direct C API incorrectly. Or possibly correctly. We have tried to eliminate most of this (use after free, etc.) in the OOP wrappers via reference counting. If you are getting a segfault you cannot understand when using purely the high-level D API, please post an issue.
Do not call
hts_log_*from a destructor, as it is potentially allocating via