Open henryiii opened 3 days ago
Oh, wow! First, I'm super appreciative of the offer!
Some initial thoughts:
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.
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.
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.
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
setuptools.build_meta
PyProject
Must have a
[tool.pytest.ini_options]
configuration section in pyproject.toml. If you must have it somewhere else (such as to supportpytest<6
), ignore this check.GitHub Actions
At least one workflow should auto-cancel.
All projects should have a
.github/dependabot.yml
file to support at least GitHub Actions regular updates. Something like this:Pre-commit
Must have
https://github.com/adamchainz/blacken-docs
in.pre-commit-config.yaml
Must have
https://github.com/pre-commit/mirrors-mypy
in.pre-commit-config.yaml
Must have
https://github.com/pre-commit/pygrep-hooks
in.pre-commit-config.yaml
Must have one of
https://github.com/executablebooks/mdformat
,https://github.com/rbubley/mirrors-prettier
in.pre-commit-config.yaml
Must have
https://github.com/astral-sh/ruff-pre-commit
in.pre-commit-config.yaml
Should have something like this in
.pre-commit-config.yaml
:MyPy
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.Must have
"ignore-without-code"
inenable_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.Must have
"redundant-expr"
inenable_error_code = [...]
. This helps catch useless lines of code, like checking the same condition twice.Must have
"truthy-bool"
inenable_error_code = []
. This catches mistakes in using a value as truthy if it cannot be falsy.Ruff
Must have
[tool.ruff]
section inpyproject.toml
orruff.toml
/.ruff.toml
.Documentation