[v3-0-test] Switch pre-commit to prek (#54258) #54585
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
potiuk
requested review from
Fokko,
amoghrajesh,
ashb,
bolkedebruin,
eladkal,
gopidesupavan,
hussein-awala,
jason810496,
jedcunningham,
jscheffl,
kaxil,
mik-laj,
mobuchowski,
pierrejeambrun and
vincbeck
as code owners
boring-cyborg
bot
added
area:dev-tools
area:production-image
boring-cyborg
bot
added
the
backport-to-v3-1-test
potiuk
requested review from
bugraoz93,
rawwar and
shubhamraj-git
as code owners
potiuk
requested review from
aritra24,
gopidesupavan and
shahar1
and removed request for
eladkal,
gopidesupavan,
hussein-awala,
jason810496,
jedcunningham,
josh-fell,
kaxil,
mik-laj,
mobuchowski,
o-nikolas,
pierrejeambrun,
rawwar,
shubhamraj-git and
vincbeck
Member
Author
|
@jscheffl -> Was not that bad. I had to sync breeze with latest main (not diffocult) and bring back a few Python 3.9 construncts in that code, but other than that, it was rather painless. Let's see if the CI agrees as well. |
potiuk
force-pushed
the
backport-3442d81-v3-0-test
branch
from
4035854 to
a80f403
Compare
Member
Author
|
Few breeze unit tests, but should be fixed now. |
aritra24
approved these changes
Aug 17, 2025
Collaborator
aritra24
left a comment
aritra24
left a comment
There was a problem hiding this comment.
Mostly nits, can be merged other than them
The pre-commit is a fantastic tool, and we heavily used it for years, but generally the tool stagnated and is not showing a sign of adapting to our needs. For years we tried to convince pre-commit maintainers that things like autocomplete are necessary - but it met with pretty much resistance (if not hostility) from the maintainer. Also there was no chance for them to accept expectations of bigger projects like ours, where we have a huge monorepo and not only multiple needs but also different parts of the repo needing different language support (golang, typescript soon) - and apparenty the maintainer of pre-commit does not think monorepo is a good thing at all. Similarly - they did not recognize the raise of `uv` and the only way to use `uv` with pre-commit is to patch it by installing `pre-comit-uv` that essentialy patches pre-commit with uv support. This is not really sustainable and the tool lags behind many of our needs. Luckily - we have new project in town - prek - which rewrites pre-commit that is 100% compatible (now), 10x faster (because rust), uses `uv` natively, supports auto-complete already and they have very friendly maintainer who is not only supporting us but also very happily works on improving `prek` to close all the gaps, and plans to implement (with our support of course and cooperation) monorepo support - that will allow us to modularise our pre-commits. This PR switches our pre-commit support to use prek exclusively: * breeze static checks command is completely removed * custom auto-complete code in breeze as well * instructions are updated to setup prek instead of precommit * CI is updated to run prek instead of pre-commmit * documentation for static checks is reviewed and new features that prek enables are added (cherry picked from commit 3442d81)
potiuk
force-pushed
the
backport-3442d81-v3-0-test
branch
from
a80f403 to
4c99ecc
Compare
Member
Author
|
Thanks @aritra24 ! addressed all. |
jscheffl
reviewed
Aug 17, 2025
jscheffl
approved these changes
Aug 17, 2025
Contributor
jscheffl
left a comment
jscheffl
left a comment
There was a problem hiding this comment.
Did not find/see another typo, LGTM!
kaxil
pushed a commit
that referenced
this pull request
Aug 18, 2025
The pre-commit is a fantastic tool, and we heavily used it for years, but generally the tool stagnated and is not showing a sign of adapting to our needs. For years we tried to convince pre-commit maintainers that things like autocomplete are necessary - but it met with pretty much resistance (if not hostility) from the maintainer. Also there was no chance for them to accept expectations of bigger projects like ours, where we have a huge monorepo and not only multiple needs but also different parts of the repo needing different language support (golang, typescript soon) - and apparenty the maintainer of pre-commit does not think monorepo is a good thing at all. Similarly - they did not recognize the raise of `uv` and the only way to use `uv` with pre-commit is to patch it by installing `pre-comit-uv` that essentialy patches pre-commit with uv support. This is not really sustainable and the tool lags behind many of our needs. Luckily - we have new project in town - prek - which rewrites pre-commit that is 100% compatible (now), 10x faster (because rust), uses `uv` natively, supports auto-complete already and they have very friendly maintainer who is not only supporting us but also very happily works on improving `prek` to close all the gaps, and plans to implement (with our support of course and cooperation) monorepo support - that will allow us to modularise our pre-commits. This PR switches our pre-commit support to use prek exclusively: * breeze static checks command is completely removed * custom auto-complete code in breeze as well * instructions are updated to setup prek instead of precommit * CI is updated to run prek instead of pre-commmit * documentation for static checks is reviewed and new features that prek enables are added
37 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The pre-commit is a fantastic tool, and we heavily used it for years, but generally the tool stagnated and is not showing a sign of adapting to our needs. For years we tried to convince pre-commit maintainers that things like autocomplete are necessary - but it met with pretty much resistance (if not hostility) from the maintainer. Also there was no chance for them to accept expectations of bigger projects like ours, where we have a huge monorepo and not only multiple needs but also different parts of the repo needing different language support (golang, typescript soon) - and apparenty the maintainer of pre-commit does not think monorepo is a good thing at all. Similarly - they did not recognize the raise of
uvand the only way to useuvwith pre-commit is to patch it by installingpre-comit-uvthat essentialy patches pre-commit with uv support. This is not really sustainable and the tool lags behind many of our needs.Luckily - we have new project in town - prek - which rewrites pre-commit that is 100% compatible (now), 10x faster (because rust), uses
uvnatively, supports auto-complete already and they have very friendly maintainer who is not only supporting us but also very happily works on improvingprekto close all the gaps, and plans to implement (with our support of course and cooperation) monorepo support - that will allow us to modularise our pre-commits.This PR switches our pre-commit support to use prek exclusively:
(cherry picked from commit 3442d81)
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named
{pr_number}.significant.rstor{issue_number}.significant.rst, in airflow-core/newsfragments.