Plans for Package Tooling

Lee el hilo completo del issue y, después, inspecciona el pyproject.toml referenciado, la configuración de CI y las decisiones sobre el src-layout. Separa los elementos de la checklist ya completados de las propuestas no resueltas y confirma un alcance concreto y criterios de aceptación antes de empezar; este issue no define actualmente cómo saber cuándo está terminado.

Agreed-Upon Package Plans:
(Read full Issue thread to see discussion)

Configuration/CI/CD:

• package management:
  • pyproject.toml (no setup.py or setup.cfg)
  • uv, including in CI
• build-system
  • hatch
  • hatch-vcs
• src-layout
  • When reaching API stability then try walled-garden API separation.
• tests / task running
  • pytest for tests
  • sybil for doctests.
  • start with tox (+ tox-uv)
  • Static checking with mypy, pyright, basedmypy, & basedpyright to check from most-used to most-correct static typing. We aim for correctness (following the official typing spec), but want to ensure a good experience with the most-used checkers.
• linting / formatting / non-test checks
  • left-hook
  • sp-repo-review
  • ruff (configured in pyproject.toml), not black / isort / pylint / etc.
  • a markdown linter
  • typos
• commit messages:
  • gitmoji
  • commitizen
  • https://github.com/liorocks/cz-gitmoji for commiten-gitmoji bridge.
• versioning: (see discussion link)
  • Date versioning (matching array-api) + minor & bugfix: YYYY-MM-minor.bug
  • main + branch-per-version format: e.g. main, 2023-11.2.1
  • Use meeseeksmachine for backporting from main branch to older version branch.
• GH labels:
  • using gitmoji
  • automated

(Original Comment)

Here's a list of my suggestions for this package. @jorenham LMK what you agree with.

Configuration/CI/CD:

• pyproject.toml, no setup.py or setup.cfg
• use ruff (configured in pyproject.toml), not black / isort / pylint / etc.
• use uv, including in CI
• build-system is hatch and hatch-vcs
• use pre-commit
• check with mypy and pyright, the most common type checkers. EDIT: adding basedmypy & basedpyright

Docs:

• same look and feel as the main docs.
• markdown

Package layout:

• src-layout
• use walled-garden separation between public and private API for easy adherence to PEP8 and dev QoL. EDIT: do at later date.

src/
    array_api_typing/
        __init__.py  # defines the public API
        _src/  # private API walled garden. Everything here is private and easily worked on by devs w/out public API consequences.
            base.py  # named whatever we want. no pre-fix underscores.
            core.py  # named whatever we want. no pre-fix underscores.

Package Contents:

• Array. Let's start (pre-release) by not making it parametric, then see what we can do well, e.g. lessons from optype.
  • I would actually like to have 2 classes a "minimal" and "full", where the minimal is only

@runtime_checkable
class BaseArray(Protocol):  # name TBD
    def __array_namespace__(self, ...) -> Namespace: ...

and the full version contains all the attributes and methods.

• Namespace
• DType, Device, etc.