Finalize release v1.0.0

[henri-hulski]

No description provided.

[henri-hulski]

@Daverball Can you take a look?

[Daverball]

Looks good to me overall, although I'm not sure about dropping pre-commit, there's pre-commit hooks for ruff check and ruff format, so it's still useful to have. You could also switch to prek, which uses the same configuration, but is written in rust and uses uv for managing the python based hooks.

[henri-hulski]

Yeah I actually just looked into it.
I don't like that pre-commit is so invasive. With auto-update, external repos and separate github aoo. For what? Only to get a pre-commit hook?
I love Husky in JS. It's just a super thin layer over git hooks. 2 kB and that's all what's needed.

Not sure about prek. If we would move entirely to uv that could make sense.
Actually I would prefer pdm which actually has experimental support for uv as the resolver and installer.

[Daverball]

From my experience prek is blazing fast, even more so if ruff is going to be the only hook. Since uv installs these hooks into separate global virtual environments, it doesn't really matter whether or not you use uv throughout, it'll be isolated either way.

I do agree however that keeping the pre-commit hooks updated can be a bit of a chore, but then again, so are github actions. There's always the option of relying on system hooks if you want to just use whichever version of ruff is already installed, if you don't want to have to update the hook periodically.

[henri-hulski]

I don't understand why it cannot use ruff which is installed in the active venv.
I meen I can write a custom hook under .githooks/pre-commit which would be under version control to do exactly this. The only problem is that every developer needs to configure git to use this directory for hooks with git config core.hooksPath .githooks.

[Daverball]

I don't understand why it cannot use ruff which is installed in the active venv.

It can do that and I do that for running mypy as a pre-commit hook, because there it's a nightmare to keep the dependencies in sync, example:

  - repo: local
    hooks:
      - id: system
        name: mypy
        entry: ./mypy.sh
        language: system

It is however discouraged. The main idea behind pre-commit is that as long as the yaml is the same you always get the same result, whether it's run on your CI or locally. The result can't suddenly change because the version of ruff you have installed is different from the version of ruff that the CI installs. So it helps with reproducibility.

Of course you can achieve similar results with uv or other modern package managers with a lock file. And it can be more coherent, since now your editor integration for the same tools can use the same lock file as your pre-commit hooks, so the lock file cannot desync from the pre-commit hook. At that point it would be totally fine to only have local system hooks in your pre-commit config and only use pre-commit as a convenient way to bootstrap the hook with git via pre-commit install/prek install. Although with prek you could use slightly more hooks without having to worry about updating versions, since prek statically implements some of the basic hooks like stripping trailing whitespace or detecting debug statements in rust, so they're compiled into the prek binary.

[henri-hulski]

We could just pin rust in the optional lint dependencies to a version.

This would be used by tox in the CI and also when installing the development requirements locally. So they would be in sync.

Actually we have the same problem with mypy and pyright. If they are not pinned to a version the result locally and on CI can be different.

On the other hand it makes sense to have the tools up to date. So if we see that we got an error on the CI we can just update the dependencies locally.

What do you think would be the better option?

[Daverball]

For smaller projects with infrequent updates, few dependencies and few outside contributions I honestly don't think it matters too much. I tend to use tox-uv and prek in all of those smaller projects and don't worry about version pinning too much (I rely solely on tox in the CI, I don't rely on pre-commit there), since there probably won't be more than two updates a year anyways. I like having prek mostly so I don't accidentally commit unlinted/unformatted code, I also find it useful for catching debug code I forgot to remove. I got into the habit of adding a nocheckin comment on throwaway code and using a simple pygrep pre-commit hook that looks for files that contain nocheckin to catch them.

Once managing versions becomes a chore having lock files and using something like renovate to periodically update them all automatically can make sense (rather than using the pre-commit ci autoupdate action, which just handles pre-commit pins), but it's probably not worth doing here, even if you lower the frequency of renovate it can get annoying to validate and merge those pull requests, when nothing else has changed.

[henri-hulski]

@Daverball Can you check this pre-commit hook approach. Would it work for you?

[Daverball]

Sure, that's fine.

[faassen]

🥳