potiuk commented on issue #63:
URL: https://github.com/apache/tooling-docs/issues/63#issuecomment-3591823235
One comment here: while I understand muscle memory for `make` - it's a bit
alien in Python's word. Also `requirements.txt` is already largely abandoned
and everyone but some really **old-style** projects that are not really updated
are following `pyproject.toml` project definition, where `prek` can be added to
`dev` dependency groups - and installed with `uv sync` simply.
I would strongly recommend (and @sbp I think is using it) to use `prek`
instead of pre-commit. It's a fully compatible with `pre-commit` rust
replacement, reimagined for speed, dev UX and functionality.
It has built-in uv integration, has a great auto-completion support and is
generally very useful as the driver - way more usable than any `make` approach
can get. With auto-complete, nice colorful output that drags your attention to
important things it's as good as it can get.
* uv tool install prek -> to have prek installed and available on command
line
* prek install -> installs prek to run automatically with git commit (or
push or whatever options of install you choose)
* prek -> runs check on currently staged changes
* prek --last-commit -> will run pre-commit checks on last commit only
* prek auto-update -> will update all hooks to latest versions
* prek run --from-ref main -> will run prek checks for all changes since you
branched off
* prek run --all-files -> runs checks on all files
All this is heavily optimized for performance - prek's real power is the
"git" integration - i.e. it will figure the minimum set of hooks to be run for
the change in the currently staged changes, or the commit (or range of commits)
that you specify. While on CI it runs with `--all-files` to add a safety net in
case modified files did not trigger the right hooks. And it does it heavily
in-parallel if possible, usually using all available cores and splitting the
file lists into chunks where checks are run in parallel. This way git commit in
even medium size projects takes as little time as possible time when `prek
install` has been run before and it has the benefit that you don't even have to
think of running **anything**. Which I find extremaly good for incrementally
fixing issues when you incrementally commit your changes.
Also `uv` frees you from installing and activating `venv` at all. It uses it
under the hood, but whenever you run `uv run` it will automatically sync your
repo with `pyporject.toml`, insalls upgraded code and regenerates .lock file so
that development environment can be reproducible between different people.
Nobody even has to think (or even need to know) about venv, activation,
installing dependencies, different requirements.txt (dev/prod) etc. etc. This
is a thing of a past with modern tooling. Generally you should be able to do:
* git clone project
* cd project
* uv run pytest
And the venv should be created for you, all necessary packages (including
development packages) will be installed in **exactly** the same version like
last version the last person who committed the code used it, activate the
environment and run pytest for all tests of yours in that environment. And it
will continue working like that - i.e. if tomorrow you pull changes that other
developer added with new requirements and dependencies, you have to do NOTHING.
You just do this:
* uv run pytest
And new dependencies will be installed, outdated dependencies will be
updated, venv will be reinstalled (this usually takes milliseconds) and your
tests will be run in that new environment.
I think - if you want to document setting up an environment, my
recommendation is to teach people modern ways of setting up the environment and
running it that takes seconds, rather than quite "dated" things how python (and
non-python) projects were managed literally years ago.
My 3c.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
