Information for developers

Jump to bottom

John Kerl edited this page Mar 3, 2023 · 10 revisions

PRs

OK to branch from https://github.com/single-cell-data/TileDB-SOMA -- no need to fork-and-branch (although you can if you like)
Follow the PR template
Pro-tip: alias pav='python -m pre_commit run -a -v' before submitting the PR, to catch CI issues before they reach GitHub

Branches and releases

See https://github.com/single-cell-data/TileDB-SOMA/wiki/Branches-and-releases.

Top-level namespacing

Items in the top-level namespace should include things we expect a user to instantiate themselves or call directly
Exception: helper packages such as tiledbsoma.io
Anything storage-dependent should include the storage engine as a prefix or submodule: e.g. soma.tiledb_foo()
- For Python: prefix or submodule
- For R: use a prefix since there are no submodules in R

Sandbox setup

Automated QA

These run in CI, so you can run them locally (in apis/python) before putting up a PR: black, isort, flake8, mypy, python -m pytest tests
See also #193 for an opt-in way to use pre-commit hooks, if you prefer

Coding and code review

1 reviewer suffices unless stated otherwise, unless explicitly:
- If the author wants more than one approval, they should @-tag the people they need
- If the one accepting reviewer says "LGTM, but I lack enough context on ____ to be sure" they should say so (and, ideally and if possible, @-tag someone who they think would be a good second approver)
Squash-and-merge is preferred