Overview: The first release

Once the first NumType version is ready, it will support numpy==2.2.* release (probably 2.2.3), and will be compatible with at least Python 3.10.

This is what needs to happen before that:

Initial project layout

• stubs (based on numpy/**/*.pyi)
• static rejection tests (based on numpy/typing/tests/data/fail/*.pyi)
• static acceptance tests (based on numpy/typing/tests/data/{misc,reveal}/*.pyi)
• runtime acceptance tests (based on numpy/typing/tests/data/pass/*.py)
• fancy logo
• github labels
• github issue template
• CONTRIBUTING.md
• README.md (badges, installing, motivation, (non-)goals, roadmap, type-checker support, differences with numpy)

Tooling setup

• uv + hatch
• dependabot
• CI workflow (enable everything, but allow errors where needed)
• release workflow
• enable trusted publishing on PyPI
• ruff (minimal ignores, maximal selected rules, and hierarchically extend when needed)
• libcst (for bulk codemodding, can probably be removed later)
• basedpyright (at least mode="strict")
• basedmypy
  • mypy-compatible config
  • figure out why it's ignoring numpy-stubs when running it locally, and/or work around it (it works when numtype is installed from github)
  • https://github.com/numpy/numtype/pull/18
• pytest (for runtime acceptance tests)
• typos
• markdownlint
• pre-commit
• tox

Static analysis

• ruff
  • fix the >2000 errors, by writing codemods or by hand
  • ruff format (everything)
  • ruff check (everything)
  • enforce in CI
• basedpyright
  • valid /src/numpy-stubs/
  • valid /test/static/
  • valid /test/runtime/
  • valid /tool/
• basedmypy
  • valid /src/numpy-stubs/
  • valid /test/static/
  • valid /test/runtime/
  • valid /tool/
• stubtest
  • generate the allowlist (requires mypy to pass)
  • fix the low-hanging fruit everything (except distutils)
• pytest passes