Skip to content

Information for developers

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