deepTools: turning deep sequencing reads into normalized coverage and plots

The pipeline runs from quality checks to normalized coverage to figures

deepTools describes itself as a set of user-friendly tools for exploring deep-sequencing data, and the description in the README lays out the pipeline in three stages.

First, quality checks on mapped reads. Then the creation of normalized coverage files in standard bedGraph and bigWig formats, which the README frames as what allows comparison between different files, giving the example of a treatment against a control. Third, the visualizations, described as publication-ready, built from those normalized and standardized files, used to identify enrichments and for functional annotation of the genome.

That middle stage is the one that makes the suite worth a single install. Normalization is what turns counts into a signal that can be compared across samples with different depth and different library size, and every downstream figure depends on getting it right. Building it yourself means deciding on a normalization method, handling sparse regions consistently and producing a format that downstream viewers can read.

The topic list gives the scope in terms of assays: bioinformatics, chip-seq, genomics, ngs, python and rna-seq. So the suite spans enrichment-style assays and sequencing-based transcriptomics, and the same coverage machinery serves both.

The tool is distributed on PyPI as deepTools, with a Bioconda recipe, a ReadTheDocs documentation site, a DOI for citation and a Galaxy integration. The Galaxy route matters more than it used to, since a server installation gives access to the computeMatrix tool through a web interface for people who are not running a command line.

Version 4 moved the core into a Rust extension built by maturin

The 4.0.0 release is the notable change, and the release history shows how long it took to arrive. The versions listed are 4.0.0 on 2026-09-05, 3.5.6 on 2025-01-20 and 3.5.5 on 2024-03-08. That is a gap of a full major version, released after a long stretch of patch-level work.

The architectural shift is visible in the packaging. The build backend is now maturin rather than a pure Python toolchain, and the project configuration sets python-source to pydeeptools with module-name deeptools.hp and bindings pyo3. The repository holds both a pydeeptools/ directory and a src/ directory, and a Cargo.toml at the root describes a crate named hp built as a cdylib.

The Rust dependencies tell you what the extension does. It uses rust-htslib for reading sequencing files, bigtools with read and write features for the bigWig format, ndarray and ndarray-npy for array handling, flate2 for compression, rayon for parallelism, tokio for async work, and openssl-sys with the vendored feature. The GitHub Actions badges in the README confirm the split, with separate workflows for pytest, docs, rust and planemo.

So the hot paths, the ones that iterate over reads and write large coverage files, are now native code, while the orchestration and plotting stay in Python. The Python side also grew a dependency: deeptoolsintervals at 0.1 or above, which is a separate interval handling package, and the minimum versions across the stack are high, with numpy 2.0, scipy 1.13 and matplotlib 3.10, and requires-python set to 3.12 or newer.

For an existing lab, the Python floor is the operational detail that matters most. A 3.11 environment cannot run this release.

Four installation routes, and the source build now needs a Rust toolchain

Installation is offered in several forms, and the README separates the stable release from the development version.

For the released version, pip is the shortest path:

	$ pip install deeptools

Conda is the route most bioinformatics environments already have configured:

	$ conda install -c conda-forge -c bioconda deeptools

The newer installers are grouped together as well:

	$ uv tool install deeptools
	$ pipx install deeptools
	$ pixi global install -c conda-forge -c bioconda deeptools

For a development version, the documented route is to clone the repository and use pixi, which resolves the system dependencies through conda on your behalf:

	$ git clone https://github.com/deeptools/deepTools
	$ cd deepTools
	$ pixi install

The README explains why that route is no longer trivial. The pixi install pins the entire build toolchain, naming Rust, maturin, libclang and HTSlib, through conda, with the exact pins in the pyproject.toml file under the pixi dependencies section. Building without pixi, through uv, pip or pipx, is still possible, but then you are responsible for providing that same toolchain yourself, and the documentation points to the building from source section for the details.

That sentence is the real change for contributors. Before this release, a Python developer could clone and install without thinking about a Rust compiler. Now the toolchain is a prerequisite unless you use pixi, and a missing libclang or a mismatched Rust version is the first thing that will bite someone building from a fresh clone.

Galaxy integration covers the same tools for people without a shell

The second installation target in the README is Galaxy, described as integration into Galaxy servers via the toolshed, the API or a web browser. The repository contains a galaxy/ directory for that work, and the badge in the README links to the European Galaxy server with the computeMatrix tool loaded, which is a direct demonstration rather than a promise.

The Galaxy path is genuinely different in kind from pip. A Galaxy instance runs the tools on behalf of a user through a web interface, which means the compute happens where the data and the server configuration are, and the person using it does not need a Python environment at all. For a lab with a shared Galaxy server, the same suite is available without asking anyone to maintain a local install of a stack that now includes compiled extensions.

The docs go further and describe an introduction to the deepTools Galaxy web server, including step-by-step protocols, and there is a separate FAQ that the README says it updates regularly. There is also a Gallery page the README suggests for more ideas about the scope of the tools.

Two details are worth noting for anyone integrating rather than just running. The tool is offered through the toolshed, which is the Galaxy mechanism for distributing tools with their dependencies, and the documentation has a dedicated Galaxy installation section. Separately, the repository's CI includes a planemo workflow, and planemo is the tool Galaxy itself uses to test a tool suite, which is a reasonable signal that the Galaxy integration is tested rather than incidental.

Citing deepTools is a specific step, not an optional one

The README gives a single citation and places it prominently under its own heading, which is unusual and correct practice for a research tool. The reference is the deepTools2 paper: Ramírez, Ryan, Grüning, Bhardwaj, Kilpert, Richter, Heyne, Dündar and Manke, published in Nucleic Acids Research in 2016, describing a next generation web server for deep-sequencing data analysis. The README also carries a Zenodo DOI badge, which gives the software itself a citable identifier.

For anyone using deepTools in published work, the instruction is to cite it, and the two identifiers cover the two things that need citing: the paper for the method and the software for the version you ran.

The licensing is MIT with the licence file referenced from the project metadata, and the classifiers place the project in the Science/Research intended audience and the Bio-Informatics topic. The dependency list is worth a look for anyone reproducing an environment later, since it names exact lower bounds rather than leaving everything open: numpy 2.0 or above, scipy 1.13 or above, matplotlib 3.10 or above, pysam 0.23 or above, pyBigWig 0.3 or above and deeptoolsintervals 0.1 or above.

The release mechanics are automated. A .release-please-manifest.json and a release-please-config.json at the root are the configuration for release-please, which handles version bumps and changelog entries, and a CHANGELOG.md is committed. A pre-commit configuration is present as well, so formatting and lint checks run before a commit lands.

Editorial conclusion

deepTools is worth adopting for any lab that produces mapped reads and needs comparable, normalized coverage tracks and figures for a paper, because the normalization step is the part that is painful to reimplement and the one that determines whether a treatment and control comparison is valid. It is the wrong tool if you only need a single coverage plot, or if your environment is locked to Python 3.11, since version 4 requires 3.12 or newer and the pyBigWig, pysam and deeptoolsintervals dependencies pull in compiled components. Before you upgrade from the 3.x line, verify three things yourself: that your existing scripts still work against the 4.0.0 command set, since the release gap between 3.5.6 and 4.0.0 is long and the Python floor moved, that the Rust toolchain is available if you build from source rather than installing a wheel, and that your Galaxy instance can be updated to a version carrying the current suite.

Frequently asked questions

Official sources

1. deeptools/deepTools on GitHub
2. Issues
3. License: MIT
4. README
5. Releases