Those are valid points. Thank you for sharing your insights.
IIUC, triggering pre-commit via tox might be a good compromise. In that case, I think the change I pushed few seconds ago might do the trick.
Triggering the linting locally (DEV environment) will be:tox -e pro-commit

WDYT?

To me, this still shifts a bit too much towards pre-commit (as we see with removing the requirements). If we could keep these things in pure python we can later make use of proper lockfiles to always ensure reproducible behavior.

Is there any way to tell pre-commit to run its python-based hooks with the current python environment and installed dependencies, instead of tracking its own? That would be ideal.

If it's too much work, I'd maybe remove the duplicates from the pre-commit config instead, and only run the commit message linter from there and any other hooks that do not exist in tox. Then we can instruct contributors to run tox before push, perhaps in a default PR template. Sorry for the detours here.

To me, this still shifts a bit too much towards pre-commit (as we see with removing the requirements). If we could keep these things in pure python we can later make use of proper lockfiles to always ensure reproducible behavior.

I see eye to eye with you on this. Reproduciable build (behavior) is a must have requirement in CI platform. My quetion would be, whether pinning the project revision (with arev key) isn't already achieving this requirement? And another question, what do you mean by stateing "pure python"?

Is there any way to tell pre-commit to run its python-based hooks with the current python environment and installed dependencies, instead of tracking its own? That would be ideal.

Not sure about that. What if the project revision from the pre-commit config file produces conflict between what needs to be in the environment and what is already installed?

If it's too much work, I'd maybe remove the duplicates from the pre-commit config instead, and only run the commit message linter from there and any other hooks that do not exist in tox. Then we can instruct contributors to run tox before push, perhaps in a default PR template. Sorry for the detours here.

The effort of implementing this option is not significant. I woner though, what would be the user expriance. The user is a project contributor. How frictionless will it be to maintain linting/formatting checks split into two frameworks?

Would switching totox while droppingpre-commit is a valid option?

And another question, what do you mean by stateing "pure python"?

Sorry, I meant something that we can manage fully using whatever dependency management we already use for our project, whether that ispip freeze all our requirements, poetry, hatch, flit etc.

But I'm ok with just a simple solution. We can drop pre-commit and do everything in tox, IMO, as it'll be more lightweight. We just need to add some clear docs to run selected tox environments before pushing.

The drawback will be a lot of people will have broken commits and will probably struggle locally to rebase interactively, but that's kind of already the case.

Sounds like a good compromise! So@lmilbaum I just wouldnt duplicate the runs in CI then. So we'd keep tox in CI and have the hooks for local use.

Keep in mind the pre-commit step in CI was initially made more to test that the pre-commit hooks actually work, not to run them on every PR. Maybe that was a source of confusion on why both were there. Hence these CI rules:

So we might need to take some of the standalone checks out or rework a bit.

The benefit to me of havingpre-commit run in CI is that we are testing it. So that way users who do runpre-commit are fairly sure it will work.

And now I see@nejch said that 🙂

Good discussion :-). Thanks for the engagement. Appologies for nit picking. As a DevOps practioner, this topic is in my core system.
Let me summarize what I understood so far:

The list of requirements:

1. Having linting/formatting quality gates applied on every code contribution
2. The linting/formatting quality gates is a dynamic list
3. Those quality gates should be able to run in DEV and CI environments
4. It is valueable to validate the quality gates code in CI
5. Reproducable build - ability to reproduce the exact quality gate run in a DEV environment as it was executed in CI and vice versa
6. A good contriibutor expriance - DRY (Don't repeat yourself), automatically nvoking those quality gates pre pushing the code shortens the feedback loop

What we have now:

1. The linting/formatting quality gates maintained in two lists (.pre-commit-config.yaml and tox.ini)
2. There are quality gates whcih are maintained in one list but not in the other one and vice versa (non liniting/formatting quality gates are excluded from the discussion)
3. Dependencies are matianed (maually and by renovate) in three or more files: .pre-commit-config.yaml, tox.ini and requrements-*.txt
4. There could be a mis-alignment between the dependencies used by pre-commit and by tox. Therefor, a pre-commit successful run in DEV can provide a good approximation of succelssful CI run but not 100%.
5. pre-commit has a built-in capability to be triggered on every commit while tox not
6. tox has a built-in capability to execute quality gates on multiple environments while pre-commit not - the question would be whether this capability is required for linting/formatting quality gates.
7. A contributor would invoke two different commands for a complete list of quality gates if two frameworks are used - the question would be whether those can be consolidated to one command.

Hoping this summary covers all what we know. LMK if I missed something.

With that summary, are we good to go with the approach suggested by@nejch

Sounds good to me! So de-duplicate, and I'm ok to add a tox env that doespre-commit run <lint-only-available-in-pre-commit> to bridge the gap.