OmicVerse, and a transcriptomics package that keeps widening its scope

One package for bulk, single cell and spatial data

OmicVerse is the fundamental package for multi omics including bulk, single cell and spatial RNA-seq analysis with Python, and the project asks readers to start with its paper, published in Nature Communications as OmicVerse, a framework for bridging and deepening insights across bulk and single-cell sequencing.

Having a paper matters for this kind of project in a way it does not for a small utility. It means the design decisions were reviewed, and it gives a citation that a paper or a report can point at. The repository carries the DOI in several places, in the badge, in the citation link and in the preprint badge.

Version 2 is described as a unified Python project for modern transcriptomics and multi-omics analysis, bringing together bulk RNA-seq, single cell, spatial transcriptomics, downstream visualization, model-based analysis and AI-assisted workflows in one package and documentation system.

That last grouping, model-based analysis and AI-assisted workflows alongside the sequencing modalities, is the interesting part. The traditional transcriptomics stack is a set of single purpose libraries that a researcher assembles into a pipeline, and the value of a unified package is that the steps fit together without a pile of interface work. The risk is that a package that covers everything covers a lot of code, and the quality of the less used corners is harder to judge from the outside.

The project sits in the scverse ecosystem, and the README badge points at that community, which is a reasonable signal about where the design lineage comes from.

The primary language is Python, the licence is GPL-3.0, and the recent releases are v2.3.2 from 2026-09-23, v2.3.0 from 2026-07-28 and v2.2.4 from 2026-07-21.

Version 2 is a platform, and the notes say so

The introduction carries a note that sets expectations, and it is the most useful sentence in the project description for anyone deciding whether to adopt it.

OmicVerse v2 is organized as a broader analysis platform rather than a single-method package. In addition to core analysis modules, it now includes agent-style workflows through J.A.R.V.I.S., MCP-based tool serving for AI clients, and a growing documentation and tutorial system under omicverse_guide.

Three additions, and each one changes what the project is.

The agent-style workflows mean the package can be driven by an agent rather than only by a script, which is a design decision about the interface rather than about the analysis. The MCP-based tool serving for AI clients takes that further and exposes the analysis as tools over the Model Context Protocol, which means a client that speaks MCP can call into the pipeline.

The documentation and tutorial system under omicverse_guide is the third, and it is the least flashy and arguably the most important. A package covering this many modalities is only usable if the examples are there, and a growing tutorial tree is what turns a pile of modules into something a new user can learn from.

The other thing worth noting about the project description is how the release history reads. The versions move in a minor series with occasional patch releases, and the two most recent releases are a minor and a patch about two months apart, which is the pattern of a project that is being changed in response to what people actually use.

The top level also carries a WORKFLOW.md and a SECURITY.md, and the repository has a.claude directory, which tells you that AI tooling is part of how the project is worked on, not only what it ships.

Two optional extras: synthetic biology and molecular dynamics

The two features that most changed the character of version 2 are both optional installs, and both are described in detail.

The first is ov.synbio, described as a self-contained three-layer design stack that bridges metabolism, protein and enzyme engineering, and DNA. The metabolism layer covers genome-scale metabolic modelling, with FBA, FVA, strain design and enzyme-constrained GECKO models via COBRApy. The protein layer covers protein and enzyme design, with ESMFold structure prediction, ProteinMPNN inverse design, ESM zero-shot variant effect, delta delta G stability, k_cat and EC-number prediction, and ESM-2 embeddings. The DNA layer covers codon optimisation and primer design.

The signature of that stack is the A and B hinge. You predict a turnover number from an enzyme sequence, push it into a genome-scale model as an enzyme-capacity constraint, and re-solve the achievable yield. That is a genuine coupling between two normally separate tools, and it is the kind of thing that only happens because one project owns both halves.

The second is ov.mol, where the structural stack reaches past a static snapshot into physics. You take an omics hit to its 3D structure through AlphaFold, RCSB or ESMFold, score its pockets, dock a candidate with AutoDock Vina, and then run GPU molecular dynamics on the result with OpenMM, chaining dock, then MD, then MM-GBSA so a static docking score becomes a dynamics-averaged binding free energy.

Both are installed as extras, which is the right packaging decision.

pip install "omicverse[synbio]"

pip install "omicverse[md]"

The extras mechanism keeps the heavy optional stacks, the model weights and the GPU toolchain out of the base install, so the cost of these features is only paid by the people who use them.

Installation, and the pytorch requirement you cannot skip

The general getting started section is short, and it contains one requirement that is easy to miss.

OmicVerse can be installed via conda or pypi, and you need to install pytorch at first. The project points at an installation tutorial for more detailed steps and adaptations for different platforms, Windows, Linux or Mac OS.

conda install omicverse -c conda-forge

pip install -U omicverse

The pytorch requirement is worth pausing on. It is not a documentation nicety, because the model-based analysis and the AI-assisted workflows in version 2 need it, and a user who installs the package and then hits an import error deep in a module will not have been warned by the pip output.

The repository carries an install.sh, a make.bat, a conda directory and a requirements directory, which is the usual set of platform specific installation helpers for a package that has to work on three operating systems with different compilers.

The documentation is published in two places, the project page and the readthedocs site, and the top level of the repository has a readthedocs directory with its configuration, so the same content is served from a readthedocs build and from a GitHub Pages build.

The directory structure in the project description is worth quoting, because it shows the three-way split between code, documentation and the web platform.

.
├── omicverse                  # Main Python package
├── omicverse_guide            # Documentation files
├── omicverse_web              # Web Analysis Platform
├── sample                     # Some test data
├── LICENSE
└── README.md

omicverse_web is the web analysis platform, which is a separate deliverable from the library, and sample holds test data.

The dependency list, and the commented out extras

The project metadata shows a dependency list that is long and, more interestingly, edited in place rather than generated.

The core dependencies are the standard scientific Python stack: numpy, scanpy, pandas with a ceiling below 3.0.0, matplotlib, scikit-learn, scipy, networkx, multiprocess, seaborn, statsmodels, patsy, joblib, ipywidgets, igraph, tqdm, adjustText, scikit-misc and scikit-image.

The scanpy dependency is the one that tells you where the design lineage is, and it is why the package can present bulk and single cell work in the same set of data structures rather than translating between two worlds.

The pandas ceiling is worth noting. Pinning below 3.0.0 is a deliberate compatibility statement, and it is the kind of constraint that breaks the day pandas 3 lands unless someone widens it.

The interesting part is what is commented out. The dependency list has a series of entries that are present but disabled, including gseapy, lifelines, ktplotspy, python-dotplot, pybedtools, boltons, ctxcore, termcolor, gdown, leidenalg, phate, metatime, tensorboard, scrublet, scvi-tools and pynvml. Every one of them is a real analysis dependency that a serious user might want, and every one of them is disabled in the base install.

That is the extras strategy in its raw form, and it is a two edged design. The base install stays small and the environment resolves quickly, which matters a lot for a package with a large optional surface. The cost is that a user who wants one of those libraries has to know it is available and how to get it, and the disabled list in the metadata is effectively a catalogue of what the maintainers expect people to ask for.

The build system is setuptools with Cython in the build requirements, and the classifiers cover Python 3.9 through 3.12 on Linux and Mac OS.

A large repository with a Sphinx makefile and a shim setup.py

The top level listing is long, and a few entries explain the shape of the project.

There is the omicverse package, the omicverse_guide directory for documentation, an OvIntelligence directory, docs, examples, scripts, tests, a conda directory, a readthedocs directory, a sample directory, a READMEM directory holding the translated READMEs, and a .CodeCounter directory.

The .CodeCounter entry is unusual. It suggests the project counts lines of code, which is the kind of thing a group does when they want to show scope, and it is consistent with a project whose identity is being a broad platform.

The build files show the two eras of tooling in the repository. There is a modern pyproject.toml with the project metadata, and there is a setup.py that is explicitly a shim.

r"""
Shim setup.py
"""

import setuptools

with open("README.md", "r") as fh:
    long_description = fh.read()

from setuptools import setup, find_packages  

setup(  
    
)

The shim exists so that old invocations of setup.py still work, which is the usual reason, and the real metadata lives in pyproject.toml with the version 2.3.2 and the author Zehua Zeng.

The Makefile at the top level is a minimal Sphinx makefile with a help target and a catch-all rule that routes everything else to sphinx-build, and it points at a source directory and a build directory. The documentation requirements file, however, is a long list of MkDocs tooling, with mkdocs 1.6.1, mkdocs-material 9.1.2, mkdocs-jupyter 0.25.1, mkdocstrings 0.20.0, griffe 0.26.0, jinja2 3.1.2, mkapi 4.5.0 and a set of plugins.

So the repository carries two documentation toolchains, Sphinx and MkDocs, along with nbsphinx for notebooks and recommonmark. That is a maintenance burden and it is a reasonable thing to flag for anyone who wants to contribute documentation rather than code.

Editorial conclusion

Adopt OmicVerse if you are doing transcriptomics and want one package and one documentation set covering bulk, single cell and spatial data with a scanpy-compatible base, and you are willing to install a large dependency set. Do not adopt it for a single narrow analysis, because a focused package will give you a smaller environment, and do not assume the optional extras are stable, since synthetic biology and molecular dynamics are marked as new. Before you commit, read the peer reviewed paper the project points at, check which extras you actually need with pip install "omicverse[synbio]" or pip install "omicverse[md]", and confirm that your environment can satisfy the pinned documentation toolchain if you plan to build the docs yourself.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. omicverse/omicverse on GitHub
3. Project website
4. README
5. Releases