Very very cool!

First error from the "beta test deck":

```

(airflow) jscheffl@hp860g9:~/Workspace/airflow$ git commit -m "Prevent problems with weaviate-client==4.16.7"
Installing rst-backticks
⠙ Installing hooks...
error: Failed to install hook `rst-backticks`
  caused by: command `pip install uv` exited with an error:

[status]
exit status: 1

```

On 12.08.25 10:04, Jarek Potiuk wrote:
A little update. We are getting very close and I kindly ask for those (a
little) brave ones who would like to test the current version.

Feel free to already try prek 0.0.24 - it already **almost** has
everything needed and It's definitely ready for those who are not afraid to
hit some small glitches maybe. It can be use now **instead** of pre-commit
and has pretty much 100% compatibility (+ already a number of useful
features that makes it already way better than pre-commit ever was IMHO).

I updated all the documentation and instructions in
https://github.com/apache/airflow/pull/54258 - but here short info:

* Installation: uv tool install prek

* Replace pre-commit with prek as your commit "auto commit":
     pre-commit uninstall
     prek install

* autocomplete (works as of yesterday and 0.0.24) - implemented in hours by
a contributor, where in pre-commit we asked for it years ago and proposed
to implement it and it took weeks to discuss with pre-commit author who
rejected it:

add `eval "$(COMPLETE=zsh prek)"` to your .zshrc

(or bash, or fish - whatever your shell is).

You can run `prek run <TAB>` and run individual prek hooks as you will -
including multiple prek hooks (finally! we've been waiting for it for
years!)
I would love it if more than a few people install it and report if there
are any issues/problems (or maybe even success stories :).

J.

On Sun, Aug 10, 2025 at 10:31 PM Jarek Potiuk <ja...@potiuk.com> wrote:

I have updated my draft PR to switch to prek from pre-commit.. And I found
the name actually very good.

Previously all over the docs we used "pre-commits" as a synonym for
"pre-commit hooks" - because "pre-commit hooks" was too long and
"pre-commits" were kinda ok.

But it was quite ambiguous as well. Technically speaking, "pre-commit" is
the name of the git hook stage. We could configure our hooks to be run as a
"pre-push" hook, and then the "pre-commit" was not really "correct".
With prefligit, I initially renamed all those places in the docs to be
"prefligits" instead of "pre-commits". Which was less ambiguous but also a
somewhat strange name.
With `prek` - in all those places, we. use "prek hooks". Which is **best
name ever** :). - It's short enough, and very correct - because those are
the hooks managed and run by prek - regardless if they are configured to
run on as pre-commit git or pre-push git hook.
I think "prek hooks" is a really nicer way to describe our 170+ hooks. -
much nicer than "pre-commits".

There are still few small last things to implement (namely - the way how
to initialize autocomplete, adding option to list all hooks, and
implementing pygrep hooks by the author of prek). But draft PR (just
converted it to prek and rebased) is here -
https://github.com/apache/airflow/pull/54258

I think that if "prek" implements all autocomplete etc. using `breeze
static-checks` can be completely dropped. We can also consider leaving
`breeze static-checks` to simply run `prek` and pass all the args - without
auto-complete capability, but I would rather switch completely to `prek`.
One can still use `pre-commit run` if they need - but removing it from
`breeze static checks` will generally force people to learn about prek I
think, which is a good thing possibly.
J.

On Fri, Aug 8, 2025 at 6:52 PM Jarek Potiuk <ja...@potiuk.com> wrote:

It's kind of what it is - kindergarten for PRs to grow up :D

On Fri, Aug 8, 2025 at 6:28 PM Daniel Standish
<daniel.stand...@astronomer.io.invalid> wrote:

oh boy, from prefligit to pre-k 🤦

On Fri, Aug 8, 2025 at 8:55 AM Jarek Potiuk <ja...@potiuk.com> wrote:

Way better name - we will have to get used to it, but it does the job.

On Fri, Aug 8, 2025 at 5:17 PM Damian Shaw <
ds...@striketechnologies.com>
wrote:

FYI the author is changing the name to prek:


https://github.com/apache/airflow/issues/44995#issuecomment-3168227314
https://github.com/j178/prek/pull/402

-----Original Message-----
From: Daniel Standish <daniel.stand...@astronomer.io.INVALID>
Sent: Friday, August 8, 2025 9:51 AM
To: dev@airflow.apache.org
Subject: Re: [DISCUSS] Upcoming pre-commit -> prefligit change

Yeah I thought of the typosquatting issue too.  It's just one
character
off and worse, a word that when you see `prefligit`, your brain
assumes
it's supposed to be preflight (cus prefligit is not a word, and cus
preflight makes a ton of sense conceptually).

Not my bailiwick, but feels like they will have to change the name.

On Fri, Aug 8, 2025 at 2:05 AM Jarek Potiuk <ja...@potiuk.com>
wrote:
We could indeed potentially release "airflow-pre-commit" or
"airlflow-preflight" package and use it in the docs everywhere -
that
might be the "cleanest" solution eventually and prevent
typosquatting.
On Fri, Aug 8, 2025 at 10:58 AM Ash Berlin-Taylor <a...@apache.org>
wrote:
And a clash on crates.io <http://crates.io/> too
https://crates.io/search?q=preflight

On 8 Aug 2025, at 09:52, Tzu-ping Chung
<t...@astronomer.io.INVALID>
wrote:
Already taken https://pypi.org/project/preflight/

Technically they could even issue a takedown request on the
ground
of
potential confusion attack…
Changing the name now wouldn’t be a bad idea IMO. But it’s not
my
project so whatever.
TP



On Aug 8, 2025, at 17:31, Ash Berlin-Taylor <a...@apache.org>
wrote:
One of us could also release a separate package on pypi just
creates
convenience shims of `preflight` and even `pre-commit` to invoke
prefligit
if we wanted.

On 8 Aug 2025, at 08:25, Wei Lee <weilee...@gmail.com>
wrote:
I also thought it was preflight 🤦‍♂️ Will need some time to
try
it
out. But I’m glad to see the new tools being applied.
I prefer to keep the `breeze static-check` wrapper (even
though
I
usually just invoke pre-commit directly). This might ease our
transition
if
we want to do something similar in the future.
Best,
Wei

On Aug 8, 2025, at 3:04 PM, Pavankumar Gopidesu <
gopidesupa...@gmail.com> wrote:
Indeed nice tool.

agree its bit hard to manipulate monorepo with breeze, i am
fine
with
to
drop breeze static-check.


yeah naming bit confused me, i thought same preflight and
searched
in
google, it got me flight related iternary and checks :) haha



On Fri, 8 Aug 2025 at 07:28, Jarek Potiuk <ja...@potiuk.com
wrote:
Plus if we get to monorepo - we would have to also
implement
complexity of
that in breeze :(

On Fri, Aug 8, 2025 at 8:25 AM Jarek Potiuk <
ja...@potiuk.com>
wrote:
In terms of installation, are we looking at `uv tool
install
prefligit`
or are we looking to
do binary installation?

I think it does not matter - it just will need to be
installed -
but in
our docs I think we should recommend `uv tool` as we
anyhow
require
uv
and
then it's easy to manage all installed tools `uv tool
upgrade
--all` for
example.

keep`breeze static-checks` as a thin wrapper around the
new
prefligit
commands.

The problem with that (as soon as autocomplete is merged
for
prefligit)
is
that we would have to somehow keep the autocomplete of
breeze
in
sync
with
it, which I would like to avoid (I prefer to remove all
the
code
handling
it if possible :)). The nice thing with prefligit
autocomplete is
that it
is fast and nice (once merged) - see example here:

https://github.com/j178/prefligit/pull/380#issuecomment-3163508993
and
trying to get this in breeze will require to leave all the
code we
use
now
to generate the list and use it for breeze's autocomplete
(and
it's
generally visibly slower due to python/click limitations -
not
bad,
but
that's about few 100 lines of code we could remove if we
switch
everyone
to
use prefligit. But if others would like to keep the
"static-checks"
command
- I am also fine with it.

What do others think?

J.



On Fri, Aug 8, 2025 at 7:54 AM Amogh Desai
<amoghde...@apache.org
wrote:
I am really excited for this one and kept reading it as
"preflight"
until
pointed out.

The fact that it is 10x faster + built in `uv` support +
separate pre-commit per directory
(upcoming) is really cool!

In terms of installation, are we looking at `uv tool
install
prefligit`
or
are we looking to
do binary installation? Would prefer the latter.
Regardless,
it
would be
great to keep
`breeze static-checks` as a thin wrapper around the new
prefligit commands.
That way,
contributors stay insulated from tooling details, and if
we
ever
switch
tools the wrapper
can remain unchanged.

All in all, this looks like a solid improvement and I’m
looking
forward
to
using it.

Thanks & Regards,
Amogh Desai


On Fri, Aug 8, 2025 at 10:46 AM Aritra Basu <
aritrabasu1...@gmail.com>
wrote:

I do think the closeness of the name warrants making it
obvious
the
difference in docs. I had a few moments of confusion
myself.
--
Regards,
Aritra Basu

On Fri, 8 Aug 2025, 9:02 am Jarek Potiuk,
<ja...@potiuk.com>
wrote:
Yes. Initially I thought the same ("odd choice").

That's a good point and something that we will have to
all
learn
:). I
even
thought that we should maybe leave `breeze
static-checks`
as
wrapper -
only
because `prefligit` is not something that one would
easily
use.
However -
as most of us use autocomplete, this is something that
is
super
easy
to
not
even think about (at least that's my experience after I
tried
it)
I do not think we use

https://www.npmjs.com/package/@applitools/preflight-cli
for
anything
now
-
and it requires separate account settings in
"applitools"
-
this
is
the
only "popular" preflight CLI I have found.

Does it bother anyone that it's easy to mix the two?

We could stress it in the docs that it's NOT
`preflight`
or we
could
also
leave the breeze "static-checks" wrapper - just to
handle
that
(but
I
think
it's not really necessary and we want to get rid of our
custom auto-complete code.

J.

On Fri, Aug 8, 2025 at 1:04 AM Tzu-ping Chung
<t...@astronomer.io.invalid>
wrote:

I didn’t even realise the name is NOT preflight before
you
pointed
it
out,
Daniel…

TP

--
Sent from my iPhone

On 8 Aug 2025, at 07:11, Daniel Standish
<daniel.stand...@astronomer.io.invalid> wrote:
I thought `prefligit` was a typo of `preflight`

bit of an odd choice in name

but, i guess it's probably not that bad of a choice
to
avoid
collisions
with `preflight`

On Thu, Aug 7, 2025 at 12:28 PM Jarek Potiuk <
ja...@potiuk.com
wrote:
Indeed! Jo is amazing :)

On Thu, Aug 7, 2025 at 8:24 PM Damian Shaw <
ds...@striketechnologies.com>
wrote:

Already fixed and released!

-----Original Message-----
From: Damian Shaw <ds...@striketechnologies.com>
Sent: Thursday, August 7, 2025 12:28 PM
To: dev@airflow.apache.org
Subject: RE: [DISCUSS] Upcoming pre-commit ->
prefligit
change
FYI I found two small issues trying to use it as a
drop-in
replacement
for
my work environment:

https://github.com/j178/prefligit/issues/387
https://github.com/j178/prefligit/issues/388

But my otherwise quite complicated
.pre-commit-config.yaml
(which
uses
anchors and aliases and remote and local
environments)
ran
fine.
Damian

-----Original Message-----
From: Aritra Basu <aritrabasu1...@gmail.com>
Sent: Thursday, August 7, 2025 12:08 PM
To: dev@airflow.apache.org
Subject: Re: [DISCUSS] Upcoming pre-commit ->
prefligit
change
Definitely agree with both of you, will be trying
this
out
myself
as
well.
Definitely looking forward to seeing alternatives
in
the
space!
--
Regards,
Aritra Basu

On Thu, 7 Aug 2025, 9:2 pm Jarek Potiuk, <
ja...@potiuk.com>
wrote:
Pre-commit is great for its stability but is
really
failing
in
terms
of
innovation, the project itself does not allow any
discussion
of
using
new standards.

Had my fair share of those discussions in the past
and I
quite
agree.
There is huge difference between "stability" and
"stagnation/stubbornness".
On Thu, Aug 7, 2025 at 5:39 PM Damian Shaw
<ds...@striketechnologies.com>
wrote:

I just want to say I am very excited to see
innovation in
this
space!
Pre-commit is great for its stability but is
really
failing
in
terms
of innovation, the project itself does not allow
any
discussion
of
using new standards.

I will be testing it out in my own environments
and
then
promoting
it widely.

Damian

-----Original Message-----
From: Jarek Potiuk <ja...@potiuk.com>
Sent: Thursday, August 7, 2025 10:01 AM
To: dev@airflow.apache.org
Subject: [DISCUSS] Upcoming pre-commit ->
prefligit
change
Hello everyone,

Early warning about upcoming pre-commit/prefligit
change......
Together with Ash and creator of the prefligit:
https://github.com/j178/prefligit - we are
testing
and
helping
to
close the gaps between prefligit and pre-commit
(and
later
we
hope
we will be able to improve our prefligit
integrations
with
upcoming
monorepo support especially - which would help
us to
modularise
our
pre-fligits (that's
the
name we will likely start using ;) ..

It seems we are very close so I wanted to make a
short
"upcoming
change"
note so that you are aware:

* *breeze static-checks *will hopefully be gone
and
replaced
by
`prefligit` command - the author of prefligit is
super-receptive
to
things
like `--last-commit` flags and autocomplete
including our
hook
names
-
so I
think we will be able to remove the whole
`static-check`
machinery
from breeze that added what we needed

* *prefiligit* uses *uv* by default - no more `uv
tool
install
pre-commit --with pre-commit-uv` needed to
enable it
(again
the
author of prefligit
is
way more receptive to the needs of users and
there
will
be
no
need
to
patch
pre-commit to use `uv` (which effectively `--with
pre-commit-uv`
does)

That's another step of simplifying our dev env
setup
where
existing
tooling finally catches up with what we need and
we
can
remove
some
of
our
custom
(breeze) code that does it (which makes me super
happy).
More about it soon, when we get a new release of
prefligit
that
will
solve
all the remaining (small) issues and have
auto-complete
merged
(contributed
by someone based on our issue
https://github.com/j178/prefligit/pull/380
:).

If there are any concerns or doubts - feel free
to
raise
them
:)
J.
________________________________ Strike
Technologies, LLC (“Strike”) is part of the GTS
family
of
companies. Strike is a technology solutions
provider, and
is
not
a
broker or dealer and does not transact any
securities
related
business directly whatsoever. This communication
is
the
property
of
Strike and its affiliates, and does not
constitute
an
offer
to
sell
or the solicitation
of
an offer to buy any security in any
jurisdiction. It
is
intended
only for the person to whom it is addressed and
may
contain
information that is privileged, confidential, or
otherwise
protected
from disclosure.
Distribution or copying of this communication, or
the
information
contained
herein, by anyone other than the intended
recipient
is
prohibited.
If you have received this communication in error,
please
immediately
notify
Strike
at i...@striketechnologies.com, and delete and
destroy
any
copies
hereof.
________________________________

CONFIDENTIALITY / PRIVILEGE NOTICE: This
transmission and
any
attachments are intended solely for the
addressee.
This
transmission
is covered by
the
Electronic Communications Privacy Act, 18 U.S.C
''2510-2521.
The
information contained in this transmission is
confidential
in
nature
and protected from further use or disclosure
under
U.S.
Pub.
L.
106-102, 113 U.S. Stat. 1338 (1999), and may be
subject
to
attorney-client or other legal privilege. Your
use
or
disclosure
of
this information for any
purpose
other than that intended by its transmittal is
strictly
prohibited,
and
may
subject you to fines and/or penalties under
federal
and
state
law.
If you are not the intended recipient of this
transmission,
please
DESTROY ALL COPIES RECEIVED and confirm
destruction
to
the
sender
via return transmittal.

________________________________ Strike
Technologies,
LLC (“Strike”) is part of the GTS
family
of
companies. Strike is a technology solutions
provider,
and
is
not a
broker
or dealer and does not transact any securities
related
business
directly
whatsoever. This communication is the property of
Strike
and
its
affiliates, and does not constitute an offer to
sell
or the
solicitation
of
an offer to buy any security in any jurisdiction.
It
is
intended
only
for
the person to whom it is addressed and may contain
information
that
is
privileged, confidential, or otherwise protected
from
disclosure.
Distribution or copying of this communication, or
the
information
contained
herein, by anyone other than the intended
recipient is
prohibited.
If
you
have received this communication in error, please
immediately
notify
Strike
at i...@striketechnologies.com, and delete and
destroy
any
copies
hereof.
________________________________

CONFIDENTIALITY / PRIVILEGE NOTICE: This
transmission
and
any
attachments
are intended solely for the addressee. This
transmission is
covered
by
the
Electronic Communications Privacy Act, 18 U.S.C
''2510-2521.
The
information contained in this transmission is
confidential
in
nature
and
protected from further use or disclosure under U.S.
Pub.
L.
106-102,
113
U.S. Stat. 1338 (1999), and may be subject to
attorney-client
or
other
legal privilege. Your use or disclosure of this
information
for
any
purpose
other than that intended by its transmittal is
strictly
prohibited,
and
may
subject you to fines and/or penalties under federal
and
state
law.
If
you
are not the intended recipient of this
transmission,
please
DESTROY
ALL
COPIES RECEIVED and confirm destruction to the
sender
via
return
transmittal.
B
KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
CB
[  X  ܚX K  K[XZ[
] ][  X  ܚX P Z\    ˘\ X  K ܙ B  ܈ Y  ] [ۘ[    [X[
  K[XZ[
] Z [   Z\    ˘\ X  K ܙ B
________________________________ Strike
Technologies,
LLC (“Strike”) is part of the GTS
family
of
companies. Strike is a technology solutions
provider,
and
is
not a
broker
or dealer and does not transact any securities
related
business
directly
whatsoever. This communication is the property of
Strike
and
its
affiliates, and does not constitute an offer to
sell
or the
solicitation
of
an offer to buy any security in any jurisdiction.
It
is
intended
only
for
the person to whom it is addressed and may contain
information
that
is
privileged, confidential, or otherwise protected
from
disclosure.
Distribution or copying of this communication, or
the
information
contained
herein, by anyone other than the intended
recipient is
prohibited.
If
you
have received this communication in error, please
immediately
notify
Strike
at i...@striketechnologies.com, and delete and
destroy
any
copies
hereof.
________________________________

CONFIDENTIALITY / PRIVILEGE NOTICE: This
transmission
and
any
attachments
are intended solely for the addressee. This
transmission is
covered
by
the
Electronic Communications Privacy Act, 18 U.S.C
''2510-2521.
The
information contained in this transmission is
confidential
in
nature
and
protected from further use or disclosure under U.S.
Pub.
L.
106-102,
113
U.S. Stat. 1338 (1999), and may be subject to
attorney-client
or
other
legal privilege. Your use or disclosure of this
information
for
any
purpose
other than that intended by its transmittal is
strictly
prohibited,
and
may
subject you to fines and/or penalties under federal
and
state
law.
If
you
are not the intended recipient of this
transmission,
please
DESTROY
ALL
COPIES RECEIVED and confirm destruction to the
sender
via
return
transmittal.


--------------------------------------------------------------------
-
To unsubscribe, e-mail:
dev-unsubscr...@airflow.apache.org
For additional commands, e-mail:
dev-h...@airflow.apache.org

--------------------------------------------------------------------
-
To unsubscribe, e-mail:
dev-unsubscr...@airflow.apache.org
For additional commands, e-mail:
dev-h...@airflow.apache.org




----------------------------------------------------------------
----- To unsubscribe, e-mail:
dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org



-----------------------------------------------------------------
---- To unsubscribe, e-mail:
dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org


________________________________
  Strike Technologies, LLC (“Strike”) is part of the GTS family of
companies. Strike is a technology solutions provider, and is not a
broker
or dealer and does not transact any securities related business
directly
whatsoever. This communication is the property of Strike and its
affiliates, and does not constitute an offer to sell or the
solicitation
of
an offer to buy any security in any jurisdiction. It is intended
only for
the person to whom it is addressed and may contain information that
is
privileged, confidential, or otherwise protected from disclosure.
Distribution or copying of this communication, or the information
contained
herein, by anyone other than the intended recipient is prohibited.
If you
have received this communication in error, please immediately notify
Strike
at i...@striketechnologies.com, and delete and destroy any copies
hereof.
________________________________

CONFIDENTIALITY / PRIVILEGE NOTICE: This transmission and any
attachments
are intended solely for the addressee. This transmission is covered
by
the
Electronic Communications Privacy Act, 18 U.S.C ''2510-2521. The
information contained in this transmission is confidential in nature
and
protected from further use or disclosure under U.S. Pub. L. 106-102,
113
U.S. Stat. 1338 (1999), and may be subject to attorney-client or
other
legal privilege. Your use or disclosure of this information for any
purpose
other than that intended by its transmittal is strictly prohibited,
and
may
subject you to fines and/or penalties under federal and state law.
If you
are not the intended recipient of this transmission, please DESTROY
ALL
COPIES RECEIVED and confirm destruction to the sender via return
transmittal.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org
For additional commands, e-mail: dev-h...@airflow.apache.org

Reply via email to