Conversation
BenjaminPelletier
left a comment
BenjaminPelletier
left a comment
There was a problem hiding this comment.
It makes me nervous having two different methods of code evaluation; can we change the GitHub Action to match the client-side evaluation added in this PR?
CONTRIBUTING.md
Outdated
|
|
||
| Formating and typing is verified by a CI job, however if you want to automaticaly check your code on each commit, this projet use [pre-commit](https://pre-commit.com/) | ||
|
|
||
| Install the tool as you want/your operating system want and run `pre-commit install` to add it to your local git hooks. |
There was a problem hiding this comment.
I think it's important to be able to evaluate on-demand without installing as a git hook; is the below correct?
| Install the tool as you want/your operating system want and run `pre-commit install` to add it to your local git hooks. | |
| Install the tool as you want/your operating system wants and run `pre-commit install` to add it to your local git hooks, or run `pre-commit run --all-files` to run without installing as a git hook. |
There was a problem hiding this comment.
Yes, but I as more seeing pre-commit as a "shield" for commits, when you want to run it "normally", I would suggest to use usual uv run commands (that are not documented).
Having different methods of invocation shouldn't be an issue except for version management (updated in lock file but not in pre-commits). So would it be better with a make file like others projects and pre-commits running it? It's more 'heavily', but we can version (and tooling) guaranteed :)
There was a problem hiding this comment.
I removed everything from pyproject and switched to a pure pre-commit approach :)
Co-authored-by: Benjamin Pelletier <BenjaminPelletier@users.noreply.github.com>
the-glu
force-pushed
the
precommits
branch
4 times, most recently
from
346706b to
cfc1957
Compare
2 participants
Should simply development as thoses are quick and since there are no Makefile helpers ;)