Contributing guide#
We assume that you are already familiar with git and with making pull requests on GitHub. If not, please refer to the [scanpy developer guide][].
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.
The easiest way is to get familiar with hatch environments, with which these tasks are simply:
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]
If you prefer managing environments manually, you can use pip
:
cd dso
python3 -m venv .venv
source .venv/bin/activate
pip install -e ".[dev,test,doc]"
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 prettier.
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
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.
Continuous integration#
Continuous integration 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.
Publishing a release#
Updating the version number#
DSO uses hatch-vcs to automaticlly retrieve the version number from the git tag. To make a new release, 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.
Please adhere to Semantic Versioning, in brief
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards compatible manner, and
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.
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 napoloen extension).
sphinx-autodoc-typehints, to automatically reference annotated input and output types
Citations can be included with sphinxcontrib-bibtex
See scanpy’s Documentation for more information on how to write your own.
Hints#
If you refer to objects from other packages, please add an entry to
intersphinx_mapping
indocs/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 indocs/conf.py
Building the docs locally#
hatch docs:build
hatch docs:open