Sounds good
On Fri, 11 Apr 2025 at 16:16, Jarek Potiuk wrote:
> That's a bit of a different topic :) - I was only asking about the minimum
> provider versions.
>
> And I think no-one wants to add new extras - but we do have a bunch of
> them already. What we have now is that (see pyproject-tom
That's a bit of a different topic :) - I was only asking about the minimum
provider versions.
And I think no-one wants to add new extras - but we do have a bunch of
them already. What we have now is that (see pyproject-toml files in both) :
* `apache-airflow-core` has a few of those historicall
Agreed on not having extras apart from providers.
On Fri, 11 Apr 2025 at 13:36, Ash Berlin-Taylor wrote:
> Just checked, no this was in 2.10 releases. NM then.
>
> Still, I think we should not add new extras to `apache-airflow` in
> general, and definitely not for anything other than direct prov
Just checked, no this was in 2.10 releases. NM then.
Still, I think we should not add new extras to `apache-airflow` in general, and
definitely not for anything other than direct provider “short-names”.
-ash
> On 11 Apr 2025, at 09:02, Ash Berlin-Taylor wrote:
>
> Oh hang on wait a moment.
>
Oh hang on wait a moment.
Is aiobotocore a new extra that is not available in 2.10.5 or any early
versions?
If that is the case then I’d instead vote that we don’t add new extras to
`apache-airflow`, and we instead remove it. I grudgingly accept that having
`apache-airflow[amazon]` make sense,
A draft PR here (i will split it as there are few unrelated changes)
https://github.com/apache/airflow/pull/49103 -> but it shows how we can
automatically set the min versions in "apache-airflow" meta-package (with
6-months-old provider versions).
That will quite likely help to get the "Resolution
Actually what I see when I attempted to do it - is that even if we
introduce it - it is not going to be a hard requirement. It is just a soft
limit when installing full apache-airflow[with extras].
It will be more of a default behaviour to limit the providers when extras
are used but will be easy
There absolutely is a downside to the users — “forcing" users to upgrade
providers along with Airflow version makes upgrades a much more daunting
experience.
> On 10 Apr 2025, at 21:31, Maciej Obuchowski wrote:
>
> For OpenLineage we'd definitely like something like this.
> IMO there is no dow
For OpenLineage we'd definitely like something like this.
IMO there is no downside to restricting the providers to the latest
released version.
We could go with the chicken-egg for the next release - that would add at
least one useful
feature authored by Kacper Muda -
https://github.com/apache/airf
Accidentally It turned out - with today's investigation of why RC images
are not building that it is VERY needed. It seems that `pip` resolution
works currently with our meta-package in a very bad way. If in our
pyproject.toml we have just
"amazon' = "apache-airflow-providers-amazon", "google" =
"
I assume this is not necessary when the constraint is already set on the
provider side? For example, FAB provider has a dependency on Airflow 3
(`apache-airflow>=3.0.0` in `providers/fab/pyproject.toml`)
On 2025/04/10 17:22:13 Jarek Potiuk wrote:
> Hello,
>
> TL;DR; Do people who work on some p
11 matches
Mail list logo
