Contributing

Use this section when you are changing Abacus itself rather than using it as a library. The contributor docs focus on three questions:

  1. How do you get a working local environment?
  2. Where should new code live?
  3. What do you need to run before you consider a change complete?

Abacus is intentionally local-first. The source of truth for development workflow is the combination of the repo Makefile, ARCHITECTURE.md, and the verification scripts in scripts/.

Start Here

  • Development Setup explains the supported local environment, editable install, and the verification commands you are expected to use.
  • Architecture explains the module boundaries, dependency direction, and where new code should land.
  • Testing explains the test layout, recommended pytest commands, and when to run the heavier local verification scripts.
  1. Create or refresh your local environment.
  2. Read the architecture page before touching abacus/mmm/panel.py or the extracted panel modules.
  3. Make the smallest coherent code change that solves the task.
  4. Run targeted lint and tests for the touched area.
  5. For substantial work, run make verify_local.
  6. If packaging, imports, or bundled assets changed, run make verify_package.

Subsections of Contributing

Architecture

Abacus is structured so that the public MMM API stays small while the implementation can evolve behind stable seams. The most important rule is that PanelMMM is a facade, not the place where new core behaviour should accumulate.

For the complete module map, read ARCHITECTURE.md in the repository root. This page summarises the parts that matter most when you are deciding where to put new code.

Design Principles

  1. PanelMMM stays thin. Constructor normalisation, data prep, graph construction, prediction, calibration, runtime helpers, and serialisation live under abacus/mmm/models/.
  2. Compute comes before presentation. Diagnostics, summaries, and plotting should consume structured outputs from the model layer rather than embedding analytical logic in presentation code.
  3. Dependencies flow downward. Shared root infrastructure can be imported by MMM modules, but MMM-specific modules should not leak back into the shared layer.
  4. Compatibility is deliberate. If you move imports or rename internals, keep facades or compatibility shims where public usage would otherwise break.

High-Level Package Layers

Layer Purpose Examples
Public facades Stable user-facing entry points abacus.mmm.panel, abacus.mmm.plot, abacus.mmm.summary
Panel implementation seams Core panel behaviour abacus.mmm.models.panel_config, panel_build, panel_predict, panel_runtime, panel_serialize
MMM primitives Reusable modelling building blocks abacus.mmm.components, abacus.mmm.transforms, abacus.mmm.fourier, abacus.mmm.hsgp, abacus.mmm.events
Post-fit outputs Diagnostics, summaries, optimisation, plots abacus.mmm.diagnostics, abacus.mmm.summarization, abacus.mmm.optimization, abacus.mmm.plotting
Shared root Generic infrastructure used across the package abacus.modeling, abacus.prior, abacus.metrics, abacus.data, abacus.pipeline

Where New Code Goes

If you are adding… Put it in…
Constructor normalisation, dims logic, transform configuration abacus/mmm/models/panel_config.py
Data conversion, scaling, Mundlak support, prediction-data prep abacus/mmm/models/panel_data.py
PyMC graph construction abacus/mmm/models/panel_build.py
Posterior predictive or response-curve sampling abacus/mmm/models/panel_predict.py
Serialisation or save/load compatibility abacus/mmm/models/panel_serialize.py and shared helpers in abacus/modeling/io.py
Diagnostics compute abacus/mmm/diagnostics/
Summary tables and exported curve summaries abacus/mmm/summarization/
Static charts abacus/mmm/plotting/
Budget optimisation logic abacus/mmm/optimization/
Adstock or saturation behaviour abacus/mmm/components/ and abacus/mmm/transforms/
Shared model-builder infrastructure abacus/modeling/

Dependency Rules

Allowed

  • Shared root modules can be imported by MMM modules.
  • abacus/mmm/models/ can depend on MMM primitives and shared root modules.
  • Facades such as panel.py can depend on the extracted panel modules.
  • Plotting, summaries, diagnostics, and optimisation can depend on model outputs and extracted helpers.

Avoid

  • Importing panel.py from abacus/mmm/models/*.
  • Adding plotting or summary logic to core model-building modules.
  • Adding MMM-specific behaviour to the shared abacus/modeling/ layer unless it is genuinely reusable.
  • Defaulting to panel.py for new features just because it is visible.

Practical Guidance

When you touch a feature area, check whether there is already an extracted seam for it before adding a new helper. Examples:

  • Plot behaviour should usually land in abacus/mmm/plotting/, not in abacus/mmm/plot.py.
  • Serialisation changes should usually land in abacus/mmm/models/panel_serialize.py, not directly in PanelMMM.
  • Time-varying parameter behaviour should use the HSGP and TVP support modules rather than embedding new logic in plotting or builders.

Before You Merge

  • Confirm the change landed in the correct layer.
  • Keep public facades thin.
  • Preserve public API compatibility unless the change is explicitly breaking.
  • Add or update tests in the matching test area.
  • Run the local verification commands described in Testing.

Development Setup

This page describes the supported local setup for working on Abacus. The project is maintained with local verification scripts rather than a CI-first workflow, so your development environment needs to be able to run linting, pytest, and the packaging smoke checks directly.

Prerequisites

  • Python 3.12
  • A local environment manager such as Conda
  • A writable temporary directory such as /tmp for PyTensor caches and package verification artefacts

Create the Development Environment

The simplest supported path is the repository environment file:

conda env create -f environment.yml
conda activate abacus-dev
python3 -m pip install -e .

If you know you will be running linting and tests frequently, install the optional extras as well:

python3 -m pip install .[lint,test]

Local Runtime Defaults

Some parts of the stack need writable cache directories. In restricted or sandboxed environments, set the same defaults used by the repo’s local verification scripts:

export PYTENSOR_FLAGS="base_compiledir=/tmp/pytensor,linker=py"
export JAX_PLATFORMS=cpu
export XDG_CACHE_HOME=/tmp

The Makefile already applies these defaults for make test and make smoke_mmm.

Common Commands

Lint and format

make check_lint
make lint
make check_format
make format

These targets check abacus, tests, scripts and runme.py. MyPy uses its configured file list in pyproject.toml; sandbox/ is outside these targets.

Tests

make test
pytest tests/<path>/test_*.py -v

Use targeted pytest first when you are working on a narrow area. Run the wider verification commands before closing substantial changes.

Local verification

make smoke_mmm
make verify_local
make verify_package
make verify_local_all

What these commands do:

  • make smoke_mmm runs the full timeseries demo with its configured main-fit and holdout-refit budgets. It does not reduce sampling. For a small execution check, use the bounded software smoke.
  • make verify_local runs formatting, linting, typing, and the configured test suite in sequence.
  • make verify_package builds package artefacts and validates an installed package smoke path.
  • make verify_local_all runs the local verification matrix and includes the packaging smoke step.

The package verifier builds a source distribution and wheel in a temporary workspace. It creates a clean venv without system or user packages, resolves runtime dependencies, runs pip check, and checks installed imports and assets from outside the checkout. A seeded, tiny model exercises fitting, prediction, metrics and save/load. This is an installation smoke check, not convergence or statistical qualification.

make verify_package runs both reviewed profiles in requirements/:

  • verification-current.txt pins the reviewed direct runtime stack.
  • verification-minimum.txt pins every direct runtime dependency to its declared floor, including NumPy 2.0.0, scikit-learn 1.4.2 and SciPy 1.15.0.

These profiles were exercised on Linux with Python 3.12. Runtime lower bounds now match that tested minimum stack; older versions are no longer declared supported. This does not establish every allowed combination or other Python/platform combinations. Transitive versions are resolved by pip and printed in the log. Retain that output with release verification evidence. Review and rerun both profiles when changing the dependency stack; inference upper bounds remain in pyproject.toml.

To exercise an unconstrained resolution within the package metadata bounds:

python3 scripts/run_package_verification.py

The scikit-learn floor provides the required RMSE API and NumPy 2 support. See the upstream RMSE API and 1.4.2 release notes.

Important Working Files

File Why it matters
Makefile Primary local entry point for lint, test, smoke, and package verification
environment.yml Supported dev environment definition
pyproject.toml Packaging metadata, extras, Ruff, MyPy, and pytest configuration
scripts/run_package_verification.py Package build and installed-wheel smoke verification
ARCHITECTURE.md Contributor-facing module map and dependency rules

Local-Only Areas

The repo contains some directories that are useful locally but are not part of the shipped library surface:

  • .archive/ for archived planning and reference material
  • .planning/standards/ for local documentation and writing standards
  • sandbox/ for ignored local scratch work

Keep temporary scripts in sandbox/ rather than mixing them into the package.

Troubleshooting

PyTensor cache permission errors

If you see errors related to .pytensor lock files or compiledir creation, export the runtime defaults shown above and rerun the command.

Package verification fails because build is missing

Run:

python3 -m pip install build

The make verify_package target does this automatically.

You are not sure which command to run

As a rule:

  • run targeted pytest and ruff while iterating
  • run make verify_local before finishing non-trivial code changes
  • run make verify_package when packaging, imports, or bundled assets changed

Testing

Abacus uses pytest for automated tests, plus local verification scripts for the broader confidence checks that glue linting, smoke paths, and packaging together. The expected workflow is to run targeted tests while you iterate and then run the wider local verification commands before you finish substantial work.

Test Layout

Path What it covers
tests/test_*.py Shared infrastructure such as model IO, paths, package identity, and root-level helpers
tests/mmm/ MMM behaviour at the public surface
tests/mmm/models/ Extracted panel implementation seams
tests/mmm/components/ Adstock and saturation component behaviour
tests/mmm/plotting/ Static plotting helpers and theme/layout behaviour
tests/mmm/optimization/ Budget optimisation logic and wrappers
tests/mmm/diagnostics/ Structured diagnostics compute
tests/mmm/summarization/ Summary/export helpers

When you change a specific module seam, add or update tests in the matching test area instead of only asserting through a broad end-to-end test.

Core Commands

Fast targeted runs

pytest tests/<path>/test_*.py -v
pytest tests/mmm/plotting/test_theme.py --no-cov -q
pytest tests/mmm/models/test_panel_serialize.py --no-cov -q

Use targeted runs first. They are faster to interpret and make regressions easier to localise.

Whole-suite pytest

make test

This installs the test extras and runs pytest with the local runtime defaults from the Makefile.

Local verification

make verify_local
make verify_local_all

The Makefile defines the command graph:

Target Checks run
verify_local check_format, then check_lint, then test
check_format Install lint extras; Ruff format check on abacus tests scripts runme.py
check_lint Install lint extras; Ruff check on the same paths; configured MyPy
test Install test extras; the full configured pytest suite with local runtime defaults
smoke_mmm Run the full runme.py --demo timeseries workflow with unchanged demo sampling budgets
verify_package Install the build tool; build and clean-install the wheel under both reviewed dependency profiles; check requirements, imports, fitting, prediction and persistence
verify_local_all verify_local, then verify_package

verify_local does not include an explicit byte-compilation step or the separate smoke_mmm target. Run make smoke_mmm when you intend to verify execution of the full demo. For a small execution check, use the bounded software smoke, which explicitly skips holdout validation. MyPy checks the files selected in pyproject.toml, not the whole package. Lint targets do not check ignored scratch scripts in sandbox/.

Inspect the current command graph without executing it:

make -n verify_local verify_local_all smoke_mmm

Pre-commit static checks

With the lint extras installed in the active environment, run:

python3 -m pre_commit validate-config
python3 -m pre_commit run --all-files

The local hook configuration runs Ruff format checking, Ruff lint and the configured MyPy scope. It uses the active python3 environment without downloading hook environments. Each hook checks its full configured scope on every invocation, even when only documentation changed. The hooks do not rewrite files.

Run pytest separately for test coverage. These static hooks do not replace make verify_local or packaging checks. Manual invocation does not install a Git hook; use python3 -m pre_commit install only if you want automatic checks on local commits.

Packaging smoke

make verify_package

Run this when any of the following changed:

  • packaging metadata in pyproject.toml
  • import surfaces or compatibility facades
  • bundled assets under abacus/
  • install-time behaviour or README/package artefacts

Runtime Environment

Some test paths need writable cache directories. The recommended defaults are:

export PYTENSOR_FLAGS="base_compiledir=/tmp/pytensor,linker=py"
export JAX_PLATFORMS=cpu
export XDG_CACHE_HOME=/tmp

The Makefile applies these defaults to test and smoke_mmm. Direct pytest commands use your current environment; export them explicitly when needed. The package verifier sets its own temporary PyTensor cache and Python linker.

Special Cases

Plotting tests

Prefer tests that inspect stable properties such as axes, labels, colours, sizes, rcParams, and return types. Avoid brittle pixel-perfect assertions.

For a focused plot run, you can disable Numba JIT explicitly:

NUMBA_DISABLE_JIT=1 pytest tests/mmm/test_plot.py --no-cov -q

Save/load and compatibility work

If you change model serialisation, identity strings, or import compatibility, add tests that prove older saved data or old import paths still work where that compatibility is expected.

Packaging and bundled assets

If you add or move package data, use make verify_package so the change is checked against an installed wheel rather than only the editable repo checkout. See dependency verification profiles for their interpreter/platform scope and lower-bound limits. Passing tests and installation smoke checks does not establish convergence, statistical validity or causal identification.

What to Run Before You Finish

Small, localised change

  • Targeted pytest
  • Targeted ruff check

Moderate code change

  • Targeted pytest
  • make check_lint
  • make smoke_mmm

Broad or risky change

  • make verify_local
  • make verify_package if packaging or bundled assets changed

Writing Good Tests

  • Test observable behaviour, not implementation noise.
  • Keep fixtures close to the layer you are testing.
  • Prefer additive compatibility tests when preserving old behaviour.
  • Use small synthetic data where possible.
  • For plotting and serialisation, assert the stable contract rather than fragile internals.