Installation

Standard

Pip

To install using pip, run the following within a suitable virtual environment:

pip install dingo-gw

This installs Dingo and its runtime dependencies, as specified in pyproject.toml.

Optional functionality can be enabled via extras, for example:

pip install "dingo-gw[wandb,pyseobnr]"

Conda

Dingo is also available from the conda-forge repository. To install using conda, first activate a conda environment, and then run

conda install -c conda-forge dingo-gw

Development

Installation

If you would like to make changes to Dingo or contribute to its development, install it from source.

First clone the repository:

git clone git@github.com:dingo-gw/dingo.git
cd dingo-gw

Recommended (using uv)

We recommend using uv for development installs, as it provides fast, reproducible dependency resolution.

Create a virtual environment and install all development dependencies:

uv sync

This installs Dingo in editable mode along with development, documentation, and typing dependencies. To also install optional dependencies, use

uv sync --extra wandb --extra pyseobnr

Alternative (pip)

If you prefer pip, create and activate a virtual environment:

python3 -m venv dingo-venv
source dingo-venv/bin/activate

Install Dingo in editable mode with development tools:

pip install -e ".[dev]"

Optional user-facing features can be enabled via extras, for example:

pip install -e ".[dev,wandb]"

Documentation

The documentation is built with Quarto and quartodoc, which generates the API reference from the package docstrings. First install Quarto, then install the Python doc tooling (pinned in the docs dependency group; jupyter is needed to render the notebook pages). From the repo root:

pip install --group docs jupyter

The hosted documentation on Read the Docs runs this same build via .readthedocs.yaml; every pull request gets a preview build, linked from the PR checks.

The documentation sources live in docs/source. From that directory, first refresh the API reference: gen_api.py scans the dingo package and lists every public object in _quarto.yml (the analogue of sphinx-apidoc), then build_api.py writes a reference page for each object from its docstrings, merging each __init__’s parameters into its class page:

python gen_api.py     # refresh the API object list (run when objects are added or removed)
python build_api.py   # generate the reference/ pages from docstrings (merges __init__ params)

Then render the site:

quarto render

The HTML is written to docs/source/_site, with the main index at docs/source/_site/index.html. While editing, run

quarto preview

to serve the documentation locally with live reload.