Updating Tooling Infrastructure

[srivarra]

It would be beneficial to update the DevEx / tooling around this repository. I'm thinking the following would be useful.

• uv: Improved Package managemet.

  • Optional Dependencies + Dependency Groups, where Optional dependencies are user facing (shipping options to users), and Dependency Groups are developer facing (giving options for devs, like docs, test).

• hatch: Build Scripts (moving the make bulid in docs to a build script)

• ruff: Add to pre-commit setup

  • Replaces isort, black, flake, etc...

  • I have found the following rules to be quite useful

    Code	Description
    B	flake8-bugbear
    BLE	flake8-blind-except
    C4	flake8-comprehensions
    D	pydocstyle
    E	Error detected by Pycodestyle
    F	Errors detected by Pyflakes
    I	isort
    RUF	Ruff-specific rules
    TID	flake8-tidy-imports
    UP	pyupgrade
    W	Warning detected by Pycodestyle
    NPY	NumPy-specific rules
    PD	Pandas code
    PTH	pathlib
    PT	Pytest
    PERF	Perflint

• Move from setup.cfg, setup.py to pyproject.toml, Python Packaging User Guide has nice documentation for this. It's now the standard and recommended configuration file for Python packages.

• src Layout in favor of Flat layout

• pytest-xdist: For running tests in parallel (comes "free" with hatch)

  • Tried this locally, ran into some flakey tests, so this can be optional

• Automatic Changelog generation with git-cliff via GH Actions

The following template, cookiecutter-scverse provides us with mostly all of these built in. They have documentation on transitiong an existing repo over to it.

Any thoughts?

[ziw-liu]

My general thoughts:

• Do not fix things until they are obviously broken (i.e. becomes a blocker or is dangerous)
• Reduce developer mental overhead. Keep tooling and style rules to the very minimum so scientists can contribute without becoming experts in software engineering.

[ziw-liu]

Also any repo-wise changes need to wait until we merge #301 to avoid conflicts.

[srivarra]

@ziw-liu I agree, what do you think of just the pyproject.toml for after #301?

[ziw-liu]

@ziw-liu I agree, what do you think of just the pyproject.toml for after #301?

Sounds good! Can you open an issue to track that?

[srivarra]

@ziw-liu Yeah!