On Thu, Sep 12, 2024, at 10:43 AM, Stephen Finucane wrote:
o/
Trimming this down as I'm mostly interested in the use of pre-commit.
In recent times, we have been slowly introducing use of the pre-commit tool [1]. Initially this was purely additive, as it's a nice help for users working in a terminal (like me!) and mostly duplicated what was defined in the `pep8` target. This duplication led to issues where pre-commit was doing slightly different things from the `pep8` target, so we have evolved this so that the `pep8` target now simply calls pre-commit. This is pretty easy to do now since most if not all of the linters in common use across OpenStack - flake8, hacking, doc8, bandit, etc. - provides pre-commit hooks. I recommend anyone using pre-commit does the same thing otherwise these thing can drift. For example, your pep8 target can become:
[testenv:pep8] description = Run style checks. skip_install = true deps = pre-commit commands = pre-commit run --all-files --show-diff-on-failure
One of my main concerns with pre-commit is that it didn't operate on tool packages (for example wheels from pypi) but instead with tooling source code and then built them all from source. This has a couple of downsides in a CI environment: it makes caching more difficult (we can't rely on our pypi cache) and you need to ensure you've got build toolchains for all the tools invoked by pre-commit. This is less of a concern when you can install these things once (or infrequently) on your local laptop. Has pre-commit improved on this at all? Quickly skimming the docs it seems that python hook targets must still "hook repository must be installable via pip install . (usually by either setup.py or pyproject.toml)". This is potentially extra problematic when you start adding in tools like Ruff that require a full rust toolchain to build. Suddenly we're replacing python slowness with language runtime bootstrapping and tool compilation time. In the ruff case it looks like they've worked around that not by fixing pre-commit but instead by creating a shim repo that will install the prebuilt wheels: https://github.com/astral-sh/ruff-pre-commit. Whatever works I guess. Just be aware that this is sort of a worst case scenario from an Internet is unreliable standpoint as now we need both GitHub and PyPI to be up and accessible rather than one or the other. This also has the downside of sidestepping constraints, but in the case of linters we've already largely done that so that projects don't have to update in lockstep. This doesn't really change the status quo there.