# Rachis: the QIIME 2 framework renamed, and what the rename changes > Rachis is the framework formerly known as the QIIME 2 Framework, a plugin-based pipeline system for microbiome analysis that keeps the QIIME 2 ecosystem, documentation and community in place while the code moves to a new name and a new home. It suits the teams already running QIIME 2 and the developers who intend to keep contributing to it. **rachis-org/rachis** — Rachis Framework (Formerly Known as QIIME 2 Framework (Q2F)) - Repository: https://github.com/rachis-org/rachis - Website: https://qiime2.org - Stars: 532 · Forks: 253 - Language: Python - License: BSD-3-Clause - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/rachis-org-rachis ## A rename, not a rewrite The README opens with the repository's purpose in one line: it is the source code repository for the rachis Framework, the framework formerly known as the QIIME 2 Framework. The project description says the same thing in the other direction, Rachis Framework, formerly known as QIIME 2 Framework. What is striking is how much the rest of the README is about continuity rather than change. The project homepage is still qiime2.org, with a note that they will be migrating soon to rachis.org. The announcement explaining why the framework is now called rachis, and how it differs from QIIME 2, is linked, and the README reassures readers in the same breath that the QIIME 2 that they know and love is still alive and well. That last clause is the one to hold on to. The rename is of the framework, not of the QIIME 2 distribution that people install and use for amplicon and metagenome analysis. The amplicon documentation is at amplicon-docs.qiime2.org, the metagenome documentation at moshpit.qiime2.org, the QIIME 2 Library holds installation instructions, plugins, books, videos and workshops, and the help forum is still forum.qiime2.org. So there are two things here, and they are easy to conflate. The framework is the plugin system and pipeline engine that the distributed applications are built on. The QIIME 2 distribution is the application that most people mean when they say QIIME 2. The rename applies to the first, and the ecosystem of documentation, plugins and community that surrounds the second is unchanged so far. The language is Python, the licence is BSD-3-Clause, and the default branch is `dev`, which is worth noting in a project with a public rename in progress. ## The plugin entry point is the contract The packaging metadata shows the framework's core abstraction more clearly than any prose would, because the entry point tables are short and explicit. There is a `rachis.plugins` entry point group, and the metadata lists two entries, `dummy-plugin` and `other-plugin`, both pointing into `rachis.core.testing.plugin`. Those names are self-evidently test fixtures, which tells you that the group is where third party code registers itself with the framework. There is also a `rachis.usage_drivers` group with a single entry, `python3`, mapped to `rachis.core.archive.provenance_lib:ReplayPythonUsage`. Usage drivers are the mechanism by which the framework records how a result was produced. This one is the Python replay driver, and the location of it, in a module called `provenance_lib` under the archive package, connects the plugin system to the data model: the framework is not only running pipelines, it is recording the provenance of the results so that they can be replayed. That provenance concept is the reason a framework exists at all in this domain. A microbiome analysis is a chain of steps, each with parameters, and a result that cannot be traced back to the exact chain that produced it is not reproducible. The framework's job is to make every step a plugin with declared inputs and outputs, to record the parameters, and to package the result with enough metadata that the chain can be replayed later. The two entry point groups together describe the whole surface a plugin author touches: the plugin itself, and the driver that records how it ran. ## The dependency list is a description of the framework's design The runtime dependencies in `pyproject.toml` are worth reading closely, because several of them name a specific architectural choice. `parsl>=2026.0` is the most telling. Parsl is a workflow execution library, so the framework delegates task scheduling, parallel execution and workflow composition to it rather than implementing its own. For a pipeline system that has to run the same analysis on a laptop, on a cluster and in the cloud, delegating to a library that already handles those cases is a significant decision, and it means the framework inherits rather than reimplements retries, caching and remote execution. `flufl-lock` is a file lock library, and its presence tells you the framework takes concurrent access to shared state seriously, which is what you would expect from something that writes results into a shared archive. `dill` is the serialisation library, and `networkx` is the graph library. The `dill` choice in particular indicates that the framework serialises Python objects rather than plain data structures, which is consistent with a system whose results include plugin-defined artefacts. The rest is a conventional scientific stack: `numpy`, `pandas`, `scipy` implied through the scientific set, `pyyaml` for configuration, `lxml` for XML handling, `bibtexparser` for bibliography handling, `tomlkit` for TOML manipulation, `python-dateutil` and `tzlocal` for time handling, `platformdirs` for user directories, and `psutil` for process information. The version floors are tight and mostly bounded above, for example `pandas>=2.2,<3.0.0` and `numpy>=1.26,<3.0.0`. A framework that pins its numeric stack in a narrow range is one where a breaking change in pandas would break every plugin at once, and the upper bounds are there to keep that from happening under you. ## Building and testing: uv, nox and a Makefile The `Makefile` at the top of the repository shows the development workflow, and it is short enough to quote in full: ```bash lint: uv run nox -s lint test: all uv run nox -t test-max install: all $(PYTHON) -m pip install --no-deps -v . dev: all pip install -e . ``` Three things stand out. First, everything runs through `uv run nox`, so the nox sessions are the interface and the Makefile is a thin wrapper. The `lint` target runs the `lint` nox session, and `test` runs the `test-max` session, whose name suggests a maximum-parallelism test run rather than a quick one. Second, the `install` target uses `pip install --no-deps -v .`. The `--no-deps` is the point: the framework is installed without its dependencies, because a framework's dependencies are supposed to be resolved by the environment, which for this project is a conda environment, and installing them again from PyPI would override the conda resolution. Third, there is a `dev` target that does an editable install with `pip install -e .`, and a `mystery-stew` target that runs a nox session named `test_mystery_stew`. The name is worth noticing. A test session called mystery stew is a session that runs a broad or randomised set of checks, and the existence of it alongside `test-max` suggests the project distinguishes a deterministic full test run from something more exploratory. The `clean` and `distclean` targets are present, and the `all` target is empty, which is the convention for a Makefile whose real targets are the phony ones. The `noxfile.py` at the top level is where the sessions themselves are defined, and the dev dependency group pins `nox>=2025.11.12`, `pytest>=9.0.2,<10.0.0` and `ruff>=0.14.10`. ## Versioning by calendar, and the rename's slow middle The release history tells two stories at once. On one hand, the calendar versioning. Releases are named 2026.4.0 and 2026.1.0, and the older QIIME 2 release was 2017.2.0, described in the tag as QIIME 2 release 2017.2 with paired-end analysis support and 100x faster denoising with DADA2. So the scheme is year, then a release within that year, and it is a scheme designed for a project that ships a coordinated distribution of a framework and a set of plugins. On the other hand, the gap. The tagged releases visible are 2026.1.0 on 2026-01-28 and 2026.4.0 on 2026-05-15, and before those a 2017.2.0 from February 2017. Between the 2017.2 tag and the 2026 series there is a long stretch with no tagged release in this list, which is when the QIIME 2 project was publishing its own version scheme rather than this one. The build system tells you how the version is derived. `versioningit` is used with the `git-archive` method, meaning the version comes from the git tag and, for a checkout without a tag, from a distance and revision count appended to a default tag of `0.0.1`. The `next-version` method is `minor`, and the format templates produce things like `{base_version}+{distance}.{vcs}{rev}` with a `.dirty` suffix for an untagged working tree. The default branch is `dev`, not `main`, and the last push was on 2026-10-05. So the active development line is a development branch, and the published versions are cut from it. For a project in the middle of a rename, that is a normal arrangement, and it is also the arrangement that means the stable releases and the framework under its new name are not the same thing at every moment. ## Where Rachis is the wrong tool The first wrong-tool case is an analyst who wants to run a microbiome analysis. The framework is the plumbing, not the application. The README routes amplicon analysis learners to the QIIME 2 documentation and metagenome analysis learners to the MOSHPIT documentation, and neither is a substitute for those guides. A researcher who wants a result this week should use the distribution, not build a plugin. The second is a team outside the microbiome field that has heard that a plugin framework is a good way to structure their own analysis pipelines. The design carries a specific domain assumption, the archive with provenance and replay, and the entry point groups are named for a microbiome ecosystem. Adapting that to another domain means fighting the data model rather than reusing it. The third is a plugin author who needs a stable API right now. The framework is in the middle of a rename, the homepage is still qiime2.org and is expected to move to rachis.org, the `rachis.plugins` entry point group is new, and the public API is still QIIME 2's. A plugin written against the current interface may need attention when the migration completes, and the announcement is the document to read first. The fourth is a deployment that cannot use conda. The `conda-recipe/` directory at the top level and the `PREFIX ?= $(CONDA_PREFIX)` variable in the Makefile both point the same way, and the install target's `--no-deps` flag is an instruction to let the environment resolve dependencies. The alternative worth naming is writing a standalone analysis tool that reads your inputs and writes your outputs, with no plugin system and no archive. The difference in approach is that a plugin framework buys you reproducibility, a shared data model and a marketplace of third party steps, all of which cost you a dependency on a moving platform, a plugin compatibility matrix and a learning curve in the framework's own concepts. For a single well-defined analysis, a script with a versioned environment is less machinery, and the ecosystem of tools the framework wraps, such as the DADA2 denoising the 2017.2 release note mentions, is where most of the actual scientific method lives anyway. ## Conclusion Adopt Rachis when you already run QIIME 2 pipelines or you intend to develop plugins for them, since the framework's data model, plugin interface and provenance machinery are unchanged and the ecosystem around it is still QIIME 2. Do not adopt it as a fresh bioinformatics tool for someone outside that community, because the learning resources, the forum and the plugin library are all still on qiime2.org and the migration to rachis.org is announced as still in progress. Before you upgrade, read the transition announcement linked from the README, check that the plugins you depend on have moved to the `rachis.plugins` entry point group, and confirm that the release you install matches the conda package your environment resolves, since the version numbers follow a calendar scheme. ## FAQ ### What is the Rachis Framework? Rachis is the framework formerly known as the QIIME 2 Framework, and this repository holds its source code. The rename applies to the plugin and pipeline framework, while the QIIME 2 distribution, its documentation, its library of plugins and its community forum remain on qiime2.org, with a migration to rachis.org announced as still to come. ### How do plugin authors register code with the Rachis framework? Through the `rachis.plugins` entry point group, which the packaging metadata lists with two test fixtures, `dummy-plugin` and `other-plugin`, both in `rachis.core.testing.plugin`. A second group, `rachis.usage_drivers`, registers the driver that records how a result was produced, with the Python3 entry pointing at `rachis.core.archive.provenance_lib:ReplayPythonUsage`. ### How do I install and test the Rachis framework from source? The Makefile provides the targets: `make install` runs `pip install --no-deps -v .` so the environment resolves dependencies, `make dev` does an editable install, `make lint` runs the lint nox session, and `make test` runs the `test-max` session. Everything goes through `uv run nox`, with the sessions defined in `noxfile.py`. ### What does the QIIME 2 to Rachis rename change for users? The README states that the QIIME 2 that users know is still alive and well, and that the project homepage is still qiime2.org while a migration to rachis.org is planned. Documentation for amplicon and metagenome analysis, the QIIME 2 Library of plugins and resources, and the QIIME 2 Forum all remain on the qiime2.org domain. ### What licence is the Rachis framework released under? BSD-3-Clause, with the licence file listed in the packaging metadata as `LICENSE` and a `LICENSE` file present in the repository root. The project asks users of rachis, QIIME 2, or any rachis distributions for published research to cite Bolyen, Rideout, Dillon, Bokulich and colleagues from 2019. ## Sources - [License: BSD-3-Clause](https://github.com/rachis-org/rachis/blob/dev/LICENSE) - [Project website](https://qiime2.org) - [rachis-org/rachis on GitHub](https://github.com/rachis-org/rachis) - [README](https://github.com/rachis-org/rachis/blob/dev/README.md) - [Releases](https://github.com/rachis-org/rachis/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rachis-org-rachis