I like "core” to include these commonly used operators. I also love "shared",
but it might mean we need to change "common" to "shared". I'm not sure if it's
worth the effort, though.
Best,
Wei
> On Aug 16, 2024, at 4:50 AM, Kaxil Naik wrote:
>
> Yeah I would favour a single "core provider":
+1 for “core”
I also like core
Le ven. 16 août 2024 à 11:48, rom sharon a écrit :
> +1 for “core”
>
“core” sounds conflicting to me because a providers package is not part of the
core. I understand the desire to strip out more operators/sensor from the core
Airflow package for maintainability purposes, but would prefer to be able to
run a bare minimum example DAG without having to install addi
Oh yes 100%. Such a core/base/whatever provider would be a dependency of
apache-airflow, much like the http provider is today, so no extra deps would
need to be specified by the users.
On 16 August 2024 11:28:18 BST, Bas Harenslak
wrote:
>“core” sounds conflicting to me because a providers pac
I also think "core" is not the best one as we are using "airflow core" as a
different meaning already (that's another example of Ash's "one thing
to mean in Airflow") . I still think "common.operators" would be a good
name, but I am not insisting on "common", still I think "providers.time"
is too
Yes. Agree with Ash that when we have "sdk" that will be all-but-guaranteed
(or at least intended to be) backwards compatible and no DB access from
workers, or DAG processor, then yes we can change the rules for Airflow 3
going forward, but Airflow 2 support question remains.
Basically it boils do
What about primary provider?
בתאריך יום ו׳, 16 באוג׳ 2024, 16:49, מאת Jarek Potiuk :
> I also think "core" is not the best one as we are using "airflow core" as a
> different meaning already (that's another example of Ash's "one thing
> to mean in Airflow") . I still think "common.operators" wou
Random idea, how about standard? Like how we can Python’s stock libraries
standard libraries.
> On 16 Aug 2024, at 22:19, Elad Kalif wrote:
>
> What about primary provider?
>
> בתאריך יום ו׳, 16 באוג׳ 2024, 16:49, מאת Jarek Potiuk :
>
>> I also think "core" is not the best one as we are usi
Looking for thoughts on the idea of adding a new TriggerRule which will never
fire. The use case I have in mind is system tests. Airflow docs pages harvest
code snippets from the system tests and on occasion I have run into a situation
where the snippet can't run in the context of the test (ru
It doesn't really sound right to include the task in the system test dag,
purely for the purpose of getting it into the docs. Why just put it in the
docs as an inline example?
If you want to conditionally run certain tasks, one option is to raise
AirflowSkipException
Kaxil,
Thanks for capturing all the notes here.
It's good to see the resolution on AIP-80 captured in the meeting notes.
I know several people are glad to see the "backwards compatibility"
included.
To be very specific, keeping the Airflow 2 templating behavior in Airflow
3.
Vikram
On Thu, Aug
Yeah “standard” or “builtin” are other options.
But tbh I feel a “core provider” is different than “Airflow core” as it
will be a Provider I feel. Don’t have a strong opinion on it though —
naming is hard
On Fri, 16 Aug 2024 at 16:22, Tzu-ping Chung
wrote:
> Random idea, how about standard? Lik
Also like core, How about essential or essentials?
"apache-airflow-providers-essentail-operators"
Regards,
Pavan Kumar
On Sat, Aug 17, 2024, 01:15 Kaxil Naik wrote:
> Yeah “standard” or “builtin” are other options.
>
> But tbh I feel a “core provider” is different than “Airflow core” as it
14 matches
Mail list logo
