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.

HatchuvPip

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]

When using an IDE such as VS Code, you’ll have to point the editor at the paths to the virtual environments manually. The environment you typically want to use as your main development environment is the hatch-test environment with the latest Python version.

To get a list of all environments for your projects, run

hatch env show -i

From the Envs column, select the environment name you want to use for development.

Next, create the environment with

hatch env create <env-name>

Then, obtain the path to the environment using

hatch env find <env-name>

In case you are using VScode, now open the command palette (Ctrl+Shift+P) and search for Python: Select Interpreter. Choose Enter Interpreter Path and paste the path to the virtual environment from above.

Code-style

This package uses pre-commit to enforce consistent code-styles. On every commit, pre-commit checks will either automatically fix issues with the code, or raise an error message.

To enable pre-commit locally, simply run

pre-commit install

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

Alternatively, you can rely on the pre-commit.ci service enabled on GitHub. If you didn’t run pre-commit before pushing changes to GitHub it will automatically commit fixes to your pull request, or show an error message.

If pre-commit.ci added a commit on a branch you still have been working on locally, simply use

git pull --rebase

to integrate the changes into yours. While the pre-commit.ci is useful, we strongly encourage installing and running pre-commit locally first to understand its 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. Just point yours to one of the environments returned by

hatch env create hatch-test  # create test environments for all supported versions
hatch env find hatch-test  # list all possible test environment paths

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

HatchuvPip

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

in the root of the repository.

Testing the correctness of the plots

Many tests will produce plots and check that they are correct by comparing them with a previously saved and serialized version of the same plots. The ground truth images are located in tests/_images. Different OS/versions may produce similar but not identical plots (for instance the ticks/padding could vary). To take into account for this please consider the following:

• you should not use locally generated plots as ground truth images, but you should commit images that have been generated by a GitHub Action. The recommended workflow is to go to the “actions” page for the repo, download the artifacts, and upload them as ground truth (after having reviewed them).

• the ground truth images need to be updated when a new test is passing, or when a test starts producing a slightly different (but consistent) plot.

• please never replace the ground truth images without having manually reviewed them.

• if you run the tests locally in macOS or Windows they will likely fail because the ground truth images are generated using Ubuntu. To overcome this you can use act, which will generate a Docker reproducing the environment used in the GitHub Action. After the Docker container is generated you can use it within IDEs to run tests and debug code.

• in the case of PyCharm, it is easier to create a container from a Dockerfile instead of using act. Please in such case use the Dockerfile made available in the repository. In this thread you can find extra details, and the process is shown in this Loom recording.

• If you are encountering problems with act or docker, please get in touch with the developers via Zulip and we will help troubleshoot the issue.

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:

• The myst extension allows to write documentation in markdown/Markedly Structured Text

• Numpy-style docstrings (through the napoleon extension).

• Jupyter notebooks as tutorials through myst-nb (See Gallery notebooks (submodule))

• sphinx-autodoc-typehints, to automatically reference annotated input and output types

• Citations (like [VBH+23]) can be included with sphinxcontrib-bibtex

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

Gallery notebooks (submodule)

The gallery rendered into the docs lives in a separate repository, scverse/spatialdata-plot-notebooks, mounted here as a git submodule at docs/notebooks/. This follows the scverse convention used by anndata, spatialdata, scvi-tools, and squidpy.

Notebooks are pre-executed by humans and committed with their outputs; the docs build performs no execution and pulls no data. A scheduled CI job in the notebooks repo re-executes every notebook against the latest spatialdata-plot release and fails on output drift.

Working with the gallery locally

# First-time clone — pull this repo with submodules
git clone --recurse-submodules https://github.com/scverse/spatialdata-plot.git

# Already cloned without submodules — initialise after the fact
git submodule update --init --recursive

# Pull the latest gallery content from the notebooks repo's main branch
git submodule update --remote docs/notebooks

ReadTheDocs is configured (submodules: include: all in .readthedocs.yaml) to fetch the submodule on every build, so PR previews always render the current pinned gallery content.

Adding or editing a notebook

Notebook changes are made in the notebooks repo, not here. See its CONTRIBUTING.md for the workflow. After your notebook PR merges there, open a small follow-up PR in this repo bumping the submodule pin:

git submodule update --remote docs/notebooks
git add docs/notebooks
git commit -m "Bump notebooks submodule"

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

Important

The docs include a git submodule (docs/notebooks → spatialdata-plot-notebooks). If you cloned this repo without --recurse-submodules, initialise it once before building:

git submodule update --init --recursive

Without the submodule, the gallery pages will be missing and sphinx will warn about broken toctree entries.

HatchuvPip

hatch run docs:build
hatch run docs:open