Packaging and linting updates?

[henryiii]

Just curious, would you like me to modernize the packaging a bit? I think flit-core makes more sense for a very simple package like this (we are using it for all our foundational libraries to minimize bootstrapping requires), ruff could replace most of the slow individual checks, and the CI probably could be sped up with tox-uv (or nox, I'm a big fan of nox), things like that. But that's up to you, don't know if you started from an old template, or if you like certain things, etc. Everyone's a bit different in their preferences. :)

You can see my preferences at https://learn.scientific-python.org/development/guides/, and this is the current sp-repo-review report (live WASM version):

General

• Detected build backend: setuptools.build_meta

?	Name	Description
✅	PY001	Has a pyproject.toml
✅	PY002	Has a README.(md|rst) file
✅	PY003	Has a LICENSE* file
✅	PY004	Has docs folder
✅	PY005	Has tests folder
✅	PY006	Has pre-commit config
✅	PY007	Supports an easy task runner (nox or tox)

PyProject

?	Name	Description
✅	PP002	Has a proper build-system table
✅	PP003	Does not list wheel as a build-dep
❌	PP301	Has pytest in pyproject Must have a [tool.pytest.ini_options] configuration section in pyproject.toml. If you must have it somewhere else (such as to support pytest<6), ignore this check.
⚠️	PP302	Sets a minimum pytest to at least 6
⚠️	PP303	Sets the test paths
⚠️	PP304	Sets the log level in pytest
⚠️	PP305	Specifies xfail_strict
⚠️	PP306	Specifies strict config
⚠️	PP307	Specifies strict markers
⚠️	PP308	Specifies useful pytest summary
⚠️	PP309	Filter warnings specified

GitHub Actions

?	Name	Description
✅	GH100	Has GitHub Actions config
✅	GH101	Has nice names
❌	GH102	Auto-cancel on repeated PRs At least one workflow should auto-cancel. concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true
✅	GH103	At least one workflow with manual dispatch trigger
✅	GH104	Use unique names for upload-artifact
❌	GH200	Maintained by Dependabot All projects should have a .github/dependabot.yml file to support at least GitHub Actions regular updates. Something like this: version: 2 updates: # Maintain dependencies for GitHub Actions - package-ecosystem: "github-actions" directory: "/" schedule: interval: "weekly"
⚠️	GH210	Maintains the GitHub action versions with Dependabot
⚠️	GH211	Do not pin core actions as major versions
⚠️	GH212	Require GHA update grouping

Pre-commit

?	Name	Description
✅	PC100	Has pre-commit-hooks
✅	PC110	Uses black or ruff-format
❌	PC111	Uses blacken-docs Must have https://github.com/adamchainz/blacken-docs in .pre-commit-config.yaml
❌	PC140	Uses a type checker Must have https://github.com/pre-commit/mirrors-mypy in .pre-commit-config.yaml
✅	PC160	Uses a spell checker
❌	PC170	Uses PyGrep hooks (only needed if rST present) Must have https://github.com/pre-commit/pygrep-hooks in .pre-commit-config.yaml
❌	PC180	Uses a markdown formatter Must have one of https://github.com/executablebooks/mdformat, https://github.com/rbubley/mirrors-prettier in .pre-commit-config.yaml
❌	PC190	Uses Ruff Must have https://github.com/astral-sh/ruff-pre-commit in .pre-commit-config.yaml
⚠️	PC191	Ruff show fixes if fixes enabled
❌	PC901	Custom pre-commit CI message Should have something like this in .pre-commit-config.yaml: ci: autoupdate_commit_msg: 'chore: update pre-commit hooks'

MyPy

?	Name	Description
✅	MY100	Uses MyPy (pyproject config)
✅	MY101	MyPy strict mode
✅	MY102	MyPy show_error_codes deprecated
❌	MY103	MyPy warn unreachable Must have warn_unreachable (true/false) to pass this check. There are occasionally false positives (often due to platform or Python version static checks), so it's okay to set it to false if you need to. But try it first - it can catch real bugs too. [tool.mypy] warn_unreachable = true
❌	MY104	MyPy enables ignore-without-code Must have "ignore-without-code" in enable_error_code = [...]. This will force all skips in your project to include the error code, which makes them more readable, and avoids skipping something unintended. [tool.mypy] enable_error_code = ["ignore-without-code", "redundant-expr", "truthy-bool"]
❌	MY105	MyPy enables redundant-expr Must have "redundant-expr" in enable_error_code = [...]. This helps catch useless lines of code, like checking the same condition twice. [tool.mypy] enable_error_code = ["ignore-without-code", "redundant-expr", "truthy-bool"]
❌	MY106	MyPy enables truthy-bool Must have "truthy-bool" in enable_error_code = []. This catches mistakes in using a value as truthy if it cannot be falsy. [tool.mypy] enable_error_code = ["ignore-without-code", "redundant-expr", "truthy-bool"]

Ruff

?	Name	Description
❌	RF001	Has Ruff config Must have [tool.ruff] section in pyproject.toml or ruff.toml/.ruff.toml.
⚠️	RF002	Target version must be set
⚠️	RF003	src directory doesn't need to be specified anymore (0.6+)
⚠️	RF101	Bugbear must be selected
⚠️	RF102	isort must be selected
⚠️	RF103	pyupgrade must be selected
⚠️	RF201	Avoid using deprecated config settings
⚠️	RF202	Use (new) lint config section

Documentation

?	Name	Description
✅	RTD100	Uses ReadTheDocs (pyproject config)
✅	RTD101	You have to set the RTD version number to 2
✅	RTD102	You have to set the RTD build image
✅	RTD103	You have to set the RTD python version

[sirosen]

Oh, wow! First, I'm super appreciative of the offer!

Some initial thoughts:

• I think switching to flit is a good idea / good fit. Most of my work is still on setuptools, but I've used flit a bit -- no complaints -- and have considered using it more.
• ruff is something I'll decline for now, though I might come back around on it. Before I start using it, I need to check some corner cases to make sure that my custom fixer is compatible.
• tox-uv is interesting -- I'm a big tox user -- but I wonder if I should learn to use uv more before pursuing it?

I want to look at this report though, it's super-interesting and at least one of these is something I didn't know about at all -- that GitHub option to cancel concurrent matching workflows.

[henryiii]

Do you have a link to your custom fixer? What does it do? Edit: ahh, it must be slyp.

There's also moving the tox config to TOML, but I haven't learned the TOML interface for it yet.

[henryiii]

I wonder if I should learn to use uv more before pursuing it?

Depends. tox-uv is just a dep that you install that makes tox use uv to install packages. So it's just a dep you add to make CI faster. As for learning uv, it doesn't have separate environments and tasks yet, but you can actually avoid most by using PEP 723 scripts and selecting groups (via --group/--only-group/--no-group). So it's not a replacement for nox/tox/hatch quite yet, but it might actually be close enough for smaller projects.

I'm really enjoying uv run <cmd>, which creates .venv, installs the project editably, and installs the dev group, then runs the command. It's a great way to quickly run pytest or python or a console script (or -m) without any setup. I've been supplementing nox/tox with it, with the nox/tox jobs being "run everything", and uv run pytest ... being a quick way to debug and such.