I also added this when you try to run `breeze static-checks`:
[image: Screenshot 2025-08-15 at 08.36.30.png]
https://ibb.co/yBXsFKB6 - if you don't see the image.
J.
On Thu, Aug 14, 2025 at 9:09 PM Ferruzzi, Dennis
wrote:
> I agree with all those points except loving the name `prek`. The
Airflow core 3.0.5rc2: +1 (binding) - Checked SVN, Reproducible package
build, Licenses, Signatures
Task SDK 1.0.5rc2: +1 (binding) - Checked SVN, Reproducible package
build, Licenses, Signatures
I tested 3.0.5rc2 via breeze using EdgeExecutor (built from main) with
the Integration Test Dag
Hey fellow Airflowers,
The release candidates for *Apache Airflow 3.0.5rc2 *and *Task SDK
1.0.5rc2* are
now available for testing!
This email is calling for a vote on the release, which will last at least
until *19th Aug* and until 3 binding +1 votes have been received.
Consider this my +1 bindi
I agree with all those points except loving the name `prek`. The name will
grow on me, or I'll get used to it; either way it's certainly not a blocker.
It's always nice to see custom tooling getting replaced by more generalized
tools that do the same job, sometimes even better.
- ferruzzi
Honestly - I think there is absolutely no need to have the shim after
rename (and prek name grew on me a lot - it's short, convenient, memorable,
relevant... all you need). And no typosquatting issues.
I am also quite strong on removing `breeze static-checks` altogether.
People will still be able
Good... Was just about to start testing :)
On Thu, Aug 14, 2025 at 8:13 PM Kaxil Naik wrote:
> Cancelling this vote to get https://github.com/apache/airflow/pull/54508
> in
> with rc2 later today
>
> On Wed, 13 Aug 2025 at 17:45, Kaxil Naik wrote:
>
> > Hey fellow Airflowers,
> >
> > The releas
Cancelling this vote to get https://github.com/apache/airflow/pull/54508 in
with rc2 later today
On Wed, 13 Aug 2025 at 17:45, Kaxil Naik wrote:
> Hey fellow Airflowers,
>
> The release candidates for *Apache Airflow 3.0.5rc1 *and *Task SDK
> 1.0.5rc1* are now available for testing!
>
> This ema
This is really neat, looking forward to it. Faster is gooder!
Did we decide not to bother with the airflow-prek/airflow-pre-commit shim
package, or are we just waiting a bit to see how things land? I'm indifferent,
just curious.
- ferruzzi
From: Jarek Poti
Also if we try to break the pattern, the ripple effect on our CI would be
quite huge. Handling that exception is not going to be easy. So IMHO -
either [redis] installs redis provider or we have no redis provider, and
then redis can do whatever.
On Thu, Aug 14, 2025 at 7:52 PM Jarek Potiuk wrote:
Ah.. Yes. Sorry - thanks Jed - you are right. I mis-read it..
What my proposal would be is to keep redis to do what it does but have
optional `[redis]' (alongside ['rabbitmq'' on celery provider:
"apache-airflow-providers-celery[redis]` - and it would **not** install
redis but install redis as de
It feels like a slippery slope to depart from the "apache-airflow[x]" ->
"apache-airflow-providers-x" pattern when x is a valid provider name. Right
now it's easy to know what it'll do before you run, but if we did this
you'd either have to look it up or try it.
Quite agree. much snappier in general.
On Thu, Aug 14, 2025 at 5:59 PM Daniel Standish
wrote:
> Anecdotally, it does seem faster.
>
> Autocomplete is nice and all, but nicer is that you don't need to run a
> specific pre-commit because you can just run the whole shebang, because
> it's faster.
>
Anecdotally, it does seem faster.
Autocomplete is nice and all, but nicer is that you don't need to run a
specific pre-commit because you can just run the whole shebang, because
it's faster.
I agree
On Thu, Aug 14, 2025 at 1:16 PM Jarek Potiuk wrote:
> Good idea.
>
> On Thu, Aug 14, 2025 at 12:03 PM Ash Berlin-Taylor wrote:
>
> > Starting a separate discussion from the discussion about valkey
> > support/provider.
> >
> > Currently if you install `apache-airflow[celery,redis]` you
Just to clarify - for the "Open Governance" argument part - it is important
to me, mostly because there is no single entity that can exclusively
benefit from us maintaining the provider. So I simply do not buy the
argument that "some 3rd party provider can release it". I just think this
argument co
Good idea.
On Thu, Aug 14, 2025 at 12:03 PM Ash Berlin-Taylor wrote:
> Starting a separate discussion from the discussion about valkey
> support/provider.
>
> Currently if you install `apache-airflow[celery,redis]` you get the celery
> and redis providers installed.
>
> My hypothesis is that 99%
Starting a separate discussion from the discussion about valkey
support/provider.
Currently if you install `apache-airflow[celery,redis]` you get the celery and
redis providers installed.
My hypothesis is that 99% of people doing this don’t use the redis provider,
and actually only want the `r
I’m with Elad on this, -1. The open nature/source/core or not of the project
isn’t the key aspect for this, but simply the usefulness of it at all
1. Do we need a separate provider for it? It already bugs me that we have
separate ElasticSearch and OpenSearch providers and this feels like the sa
He he - I saw it was already fixed by Joe...
He is likely subscribed and listening to that conversation :)
This is bringing the "maintainership" to a higher level - solving issues
even BEFORE they are raised :)
On Thu, Aug 14, 2025 at 10:25 AM Amogh Desai wrote:
> Went ahead and created an is
Went ahead and created an issue for that:
https://github.com/j178/prek/issues/452
Thanks & Regards,
Amogh Desai
On Wed, Aug 13, 2025 at 12:43 PM Jarek Potiuk wrote:
> Cool. I also involved the ASF infra / tooling people who use pre-commit a
> lot - they are also excited and trying it and foun
20 matches
Mail list logo
