Contributing guide

Contributing guide#

This document aims at summarizing the most important information for getting you started on contributing to this project. We assume that you are already familiar with git and with making pull requests on GitHub.

For more extensive tutorials, that also cover the absolute basics, please refer to other resources such as the pyopensci tutorials, the scientific Python tutorials, or the scanpy developer guide.

Tip

The hatch project manager

We highly recommend to familiarize yourself with hatch. Hatch is a Python project manager that

  • manages virtual environments, separately for development, testing and building the documentation. Separating the environments is useful to avoid dependency conflicts.

  • allows to run tests locally in different environments (e.g. different python versions)

  • allows to run tasks defined in pyproject.toml, e.g. to build documentation.

While the project is setup with hatch in mind, it is still possible to use different tools to manage dependencies, such as uv or pip.

Installing dev dependencies#

In addition to the packages needed to use this package, you need additional python packages to run tests and build the documentation.

On the command line, you typically interact with hatch through its command line interface (CLI). Running one of the following commands will automatically resolve the environments for testing and building the documentation in the background:

hatch test  # defined in the table [tool.hatch.envs.hatch-test] in pyproject.toml
hatch run docs:build  # defined in the table [tool.hatch.envs.docs]

VS Code

If you are using VS code, install the hatch-code extension. Additionally, make sure that the vscode-python-environments extension is installed (should be by default) and "python.useEnvironmentsExtension": true is activated in your settings.json.

Next, open the “Python Environment Managers” sidebar. You can do so by opening the command palette (Ctrl+Shift+P) and searching for Python: Focus on Environment Managers View. It will show a collapsible list where you can expand “Hatch” and activate an environment by clicking on the checkmark next to it. As the main development environment, we recommend to use hatch-test with the latest supported Python version.

Other IDEs

For other IDEs, you’ll have to point the editor at the paths to the virtual environments manually. To get a list of all environments for your projects, run

hatch env show -i

This will list “Standalone” environments and a table of “Matrix” environments like the following:

+------------+---------+--------------------------+----------+---------------------------------+-------------+
| Name       | Type    | Envs                     | Features | Dependencies                    | Scripts     |
+------------+---------+--------------------------+----------+---------------------------------+-------------+
| hatch-test | virtual | hatch-test.py3.12-stable | dev      | coverage-enable-subprocess==1.0 | cov-combine |
|            |         | hatch-test.py3.14-stable | test     | coverage[toml]~=7.4             | cov-report  |
|            |         | hatch-test.py3.14-pre    |          | pytest-mock~=3.12               | run         |
|            |         |                          |          | pytest-randomly~=3.15           | run-cov     |
|            |         |                          |          | pytest-rerunfailures~=14.0      |             |
|            |         |                          |          | pytest-xdist[psutil]~=3.5       |             |
|            |         |                          |          | pytest~=8.1                     |             |
+------------+---------+--------------------------+----------+---------------------------------+-------------+

From the Envs column, select the environment name you want to use for development. As the main development environment, we recommend to use hatch-test with the latest supported Python version. In this example, it would be hatch-test.py3.14-stable.

Next, create the environment with

hatch env create hatch-test.py3.14-stable

Then, obtain the path to the environment using

hatch env find hatch-test.py3.14-stable

and manually point it to the python binary.

A popular choice for managing virtual environments is uv. The main disadvantage compared to hatch is that it supports only a single environment per project at a time, which requires you to mix the dependencies for running tests and building docs. This can have undesired side-effects, such as requiring to install a lower version of a library your project depends on, only because an outdated sphinx plugin pins an older version.

To initialize a virtual environment in the .venv directory of your project, simply run

uv sync --all-extras

The .venv directory is typically automatically discovered by IDEs such as VS Code.

Pip is nowadays mostly superseded by environment manager such as hatch. However, for the sake of completeness, and since it’s ubiquitously available, we describe how you can manage environments manually using pip:

python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev,test,doc]"

The .venv directory is typically automatically discovered by IDEs such as VS Code.

Code-style#

This package uses Git hooks to enforce consistent code-styles. They are defined in .pre-commit-config.yaml and run with prek. On every commit, the checks will either automatically fix issues with the code, or raise an error message.

To enable the checks locally, run

hatch run hatch-check-code:prek install
# or
uvx prek install

in the root of the repository. prek will automatically download all dependencies when it is run for the first time.

If you didn’t run the checks locally, the Pre-commit checks job of the GitHub Actions CI runs them on your pull request, pushes the automatic fixes back to your branch, and reports any remaining failures. We strongly encourage installing and running the checks locally first to understand their usage.

Finally, most editors have an autoformat on save feature. Consider enabling this option for ruff and biome.

Writing tests#

This package uses pytest for automated testing. Please write Tests for every function added to the package.

Most IDEs integrate with pytest and provide a GUI to run tests. If you set up your virtual environments as described in installing dev dependencies, test cases should be automatically discovered by your IDE.

Alternatively, you can run all tests from the command line by executing

hatch test  # test with the highest supported Python version
# or
hatch test --all  # test with all supported Python versions

uv run pytest

source .venv/bin/activate
pytest

in the root of the repository.

Continuous integration#

Continuous integration via GitHub actions will automatically run the tests on all pull requests and test against the minimum and maximum supported Python version.

Additionally, there’s a CI job that tests against pre-releases of all dependencies (if there are any). The purpose of this check is to detect incompatibilities of new package versions early on and gives you time to fix the issue or reach out to the developers of the dependency before the package is released to a wider audience.

The CI job is defined in .github/workflows/test.yaml, however the single point of truth for CI jobs is the Hatch test matrix defined in pyproject.toml. This means that local testing via hatch and remote testing on CI tests against the same python versions and uses the same environments.

Publishing a release#

Updating the version number#

Before making a release, you need to update the version number in the pyproject.toml file. Please adhere to Semantic Versioning, in brief

Given a version number MAJOR.MINOR.PATCH, increment the:

  1. MAJOR version when you make incompatible API changes,

  2. MINOR version when you add functionality in a backwards compatible manner, and

  3. PATCH version when you make backwards compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Once you are done, commit and push your changes and navigate to the “Releases” page of this project on GitHub. Specify vX.X.X as a tag name and create a release. For more information, see managing GitHub releases. This will automatically create a git tag and trigger a Github workflow that creates a release on PyPI.

Writing documentation#

Please write documentation for new or changed features and use-cases. This project uses sphinx with the following features:

See scanpy’s Documentation for more information on how to write your own.

Kinds of page#

Documentation pages come in three kinds, and they are held to different standards.

Kind

Answers

Data

Prose

Tutorial

how do I analyse a screen?

a real screen from mt.ds

short, between figures

Example

what does this one function do?

mt.ds.synthetic_plate is fine

short

Pitfall

why does this method mislead?

whatever demonstrates it

long by design

A tutorial runs end to end on real data. An example demonstrates a single function in as few cells as possible. A pitfall is a method note — why sphering can cost most of a retrieval score, why a four-parameter fit converges on noise — and is the one kind where prose should dominate.

Method caveats belong in a pitfall, not in the middle of a tutorial. A reader working through a tutorial has not yet seen the step succeed, and a paragraph of warnings ahead of the first result teaches them nothing.

Writing a tutorial or example#

  • Use real data in a tutorial. mt.ds ships public screens; use one. Synthetic data belongs in an example, or in a pitfall where known ground truth is the point.

  • Keep prose below roughly 250 words per figure. These are image analysis pages in a visual field. If a page is over budget, the fix is usually to move method discussion to a pitfall, not to add figures.

  • End a code cell in something the reader can use: a figure, a DataFrame, or an object repr. Not a hand-assembled dict literal of labelled numbers — that output cannot be sorted, filtered, plotted or pasted into an analysis.

  • Do not check output against ground truth in a page. Comparing a result with uns["mantispy"]["truth"] shows the function works; that belongs in tests/, where it runs on every push. A page shows the reader what the result looks like.

  • Never import a private name. Anything a page imports is code readers will copy, and a _-prefixed module carries no stability guarantee. If a page needs it, it belongs in the public API; tests/test_api_guards.py enforces this.

  • Link every API mention with a {func}, {class} or {mod} role, so it resolves to the API reference and the build catches a rename.

  • Put caveats in :::{note} or :::{warning} blocks, after the result they qualify.

  • Cite with {cite:t} or {cite:p}. Add the entry to docs/references.bib by fetching it from the DOI resolver rather than writing it by hand.

Open every page with what the reader will learn (three bullets), the dataset and its citation, the download size and the expected runtime; close it with a session-info cell.

Notebook execution#

Notebooks live in docs/tutorials and are rendered by myst-nb with their committed outputs: nb_execution_mode is off, so the Read the Docs build downloads nothing and renders the outputs as they are. The Tutorials run job in .github/workflows/test.yaml executes every tutorial with nb_execution_mode=cache, so a committed output cannot silently stop matching the code.

Re-run a notebook and commit its outputs whenever you change it. The pages in docs/datasets load about 3 GB, so CI skips them; re-run them whenever a loader or a function they call changes.

nb_output_stderr is remove, so warnings do not appear on the rendered page. Never write prose that tells the reader to read a warning. If a warning is part of the explanation, capture it and print it:

with warnings.catch_warnings(record=True) as caught:
    warnings.simplefilter("always")
    mt.pp.sphere(adata, reference="negcon")
print(caught[0].message)

Hints#

  • If you refer to objects from other packages, please add an entry to intersphinx_mapping in docs/conf.py. Only if you do so can sphinx automatically create a link to the external documentation.

  • If building the documentation fails because of a missing link that is outside your control, you can add an entry to the nitpick_ignore list in docs/conf.py

Building the docs locally#

hatch run docs:build
hatch run docs:open

cd docs
uv run sphinx-build -M html . _build -W
(xdg-)open _build/html/index.html

source .venv/bin/activate
cd docs
sphinx-build -M html . _build -W
(xdg-)open _build/html/index.html