Remove lock generation from pre-commit

[SeanMooney]

Summary

• remove lock-file regeneration from the pre-commit hook set
• remove the staged-file detection wrapper used only by that hook
• retain tox -e update-lockfiles -- <targets> as the explicit interface

Rationale

Lock generation can clone external repositories and rewrite many tracked files. It is network-dependent maintenance work rather than a fast, predictable commit-time hygiene check.

Validation

• uvx --python 3.13 tox c -e update-lockfiles
• uvx --python 3.13 tox -e linters -- check-yaml
• git diff --check
• verified no tracked references to update-lockfiles-checker remain

The complete linter environment could not install hadolint because its binary download was rejected by the local proxy with HTTP 403. The configuration's YAML hook passes independently.

[rebtoor]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rebtoor

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [rebtoor]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[amoralej]

As agreed in last meeting, I'm implementing a update-lockfiles which will not clone anything. Instead of using the requirements.txt from packages in sources.txt + extra deps from pythondeps.txt and pythonbuilddeps.txt as entry for the pip-compile, it will use the existing requirements.lock + pythondeps.txt and pythonbuilddeps.txt and using the existing upper-constraints.txt as constraints file. That's exactly what we need when we just want to adjust dependencies in bindeps, pythondeps, etc...

With this new implementation, would it be appropiate to keep the update-lockfiles as pre-commit?. It will be a much lighter script that would ensure that update-lockfiles is not forgotten.

[SeanMooney]

in general i would avoid pre-commit hooks iwht network sideeffect its a lot more resonable if its updated like that but still not ideal. you can skip hook when they cause issues but would that approch need to hit pypi or similar to resolve things?

[amoralej]

in general i would avoid pre-commit hooks iwht network sideeffect its a lot more resonable if its updated like that but still not ideal. you can skip hook when they cause issues but would that approch need to hit pypi or similar to resolve things?

Sent in #71

It doesn't access the network directly but pip-compile and pybuild-deps do to resolve deps.

Yep, I tend to agree that it's probably good to remove it from pre-commit and add a new gha job to run tox -e update-lockfiles and fail if anything changed.

[SeanMooney]

in general i would avoid pre-commit hooks iwht network sideeffect its a lot more resonable if its updated like that but still not ideal. you can skip hook when they cause issues but would that approch need to hit pypi or similar to resolve things?

Sent in #71

It doesn't access the network directly but pip-compile and pybuild-deps do to resolve deps.

Yep, I tend to agree that it's probably good to remove it from pre-commit and add a new gha job to run tox -e update-lockfiles and fail if anything changed.

ya that would be my approch, you can run it locally via tox if you want too but ci can actully enforce it outside of pre-commit