Use pre-built hooks in pre commit

[paulgessinger]

This PR updates pre-commit to

• Install ruff through pre-commit. pre-commit already ships with venv management, this way it just installs it on the fly
• Use pre-compiled clang-format from PyPI. There's a PyPI repository that has static binaries of clang-format, and there's a pre-commit configuration that uses them. This has the benefit that pre-commit will install exactly the right clang-format version on the fly (we've had great success with this in ACTS).
• Change the pre-commit script for the README links from python XXX to python3 XXX, as this is the default name of the python binary on most (all?) systems nowadays.

I tried to update the CI config to correctly run this, but let's see.

BEGINRELEASENOTES

• Updated pre-commit configuration

ENDRELEASENOTES

[m-fila]

Hi, I think we have local hooks on purpose as there was a preference in key4hep repos to get the dependencies from cvmfs rather than pip when possible.
The action could be probably updated to use different stack and remove pip

[paulgessinger]

@m-fila I see the point. The benefit of using pre-commit to install hooks is that the setup on a local machine is ~ trivial, as you don't have to install anything beyond pre-commit. To that point, ruff already comes from pip, and you'll probablly be getting pre-commit from pip also, so I don't see a huge benefit of taking clang-format from cvmfs.

But it's your call in the end, of course.

[tmadlener]

As @m-fila has already said. The original idea behind running this on top of the Key4hep environment was that people were a bit less likely to run into potential issues, specifically around clang-format that sometimes changes its opinions on formatting for different versions. If we switch to pre-packaged hooks, we open the door for version mismatches and a bit more maintenance burden. On the other hand, I see the benefits of being able to run this without having the complete environment (especially for EDM4hep).

[paulgessinger]

@tmadlener I would argue that you completely remove the possibility of version mismatches, because pre-commit will always install and use exactly the correct clang-format version. As long as the format check is run with pre-commit (which it already is), there should be no need to match versions.

[tmadlener]

I would argue that you completely remove the possibility of version mismatches, because pre-commit will always install and use exactly the correct clang-format version.

pre-commit will, but other tools that pick up clang-tooling from elsewhere might not, so there is a chance that the auto-format hook of editors / IDEs disgaree with what is done in pre-commit. But presumably the clang-format hook also auto-fixes like other formatting hooks? In that case it might not be the biggest issue.

[paulgessinger]

It does apply the fix when you try to commit only.

So you're worried that if someone sets up their IDE from inside key4hep they get a different clang-format and then get fighting if the versions are not compatible?

I guess that can happen, but seems somewhat rare to me.

The options you'd have would be:

1. get clang-format from pip with the right version. It's statically linked and works pretty much anywhere.
2. don't install the pre-commit hook. You can still run pre-commit manually, and and skip the clang-format check.

[tmadlener]

(Ab)using this for a support style question: Does clang-tidy also have a hook and do you have any experience with it? In the end we would like to have this consistent over all of Key4hep and on some of the repos we also run clang-tidy in pre-commit.

[paulgessinger]

Since clang-tidy depends on much more of the clang compiler toolchain, I believe there are no precompiled static binaries like there are for clang-format, which only has to ship the parser.

We don't run clang-tidy in pre-commit, although I wanted to explore that at some point.

Btw is macOS at all a consideration in this? I don't think I can easily access the key4hep stack from macOS, so sort of requiring it in pre-commit would be a bit inconvenient.

[tmadlener]

Right. Now that you say that, I think clang-tidy was one of the reasons we switched to this kind of workflow. From experience with podio, it works quite well in CI, but is way to slow for an actual git hook.