Re: [DISCUSS] New provider Common.time

Since we are all aligned on the need to migrate all operators/sensors to dedicated providers and we are left only with the naming issue lets focus on that. Rom can you please open a vote thread for the naming of the provider? These are the options raised in the threads and we should vote on: *essen

Re: [DISCUSS] New provider Common.time

Yeah, I think essential sounds pretty good as well. Good suggestion Pavan -- Regards, Aritra Basu On Mon, 19 Aug 2024, 3:09 am Jarek Potiuk, wrote: > I like "essential" - how about "apache-airflow-provider-essentials" - that > will not limit it to only operators, we could add mixins, triggers,

Re: [DISCUSS] New provider Common.time

I like "essential" - how about "apache-airflow-provider-essentials" - that will not limit it to only operators, we could add mixins, triggers, hooks (BaseHook) and everything else that falls into "essentials" category. On Sat, Aug 17, 2024 at 2:43 AM Pavankumar Gopidesu wrote: > Also like core,

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

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

Re: [DISCUSS] New provider Common.time

“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

Re: [DISCUSS] New provider Common.time

I also like core Le ven. 16 août 2024 à 11:48, rom sharon a écrit : > +1 for “core” >

Re: [DISCUSS] New provider Common.time

+1 for “core”

Re: [DISCUSS] New provider Common.time

how about calling them "core providers"? Or does that feel like an >> oxymoron since we always make a distinction between 'core" and "provider"? >> I also like Amogh's suggestion of "foundation". >> >> - ferruzzi >

Re: [DISCUSS] New provider Common.time

an > oxymoron since we always make a distinction between 'core" and "provider"? > I also like Amogh's suggestion of "foundation". > > - ferruzzi > > > > From: Amogh Desai > Sent: Thursday, August 15,

Re: [DISCUSS] New provider Common.time

7;s suggestion of "foundation". - ferruzzi From: Amogh Desai Sent: Thursday, August 15, 2024 4:17 AM To: dev@airflow.apache.org Subject: RE: [EXT] [DISCUSS] New provider Common.time CAUTION: This email originated from outside of the organization. Do not clic

Re: [DISCUSS] New provider Common.time

4, 2024 at 7:42 PM Ferruzzi, Dennis > >> wrote: > >> > >>> I like it. > >>> > >>> - ferruzzi > >>> > >>> > >>> > >>> From: Ash Berlin-Taylor > >>> Sent:

Re: [DISCUSS] New provider Common.time

;> >> On Wed, Aug 14, 2024 at 7:42 PM Ferruzzi, Dennis >> wrote: >> >>> I like it. >>> >>> - ferruzzi >>> >>> >>> ________ >>> From: Ash Berlin-Taylor >>> Sent: Wednesday, August 14, 202

Re: [DISCUSS] New provider Common.time

ruzzi > > > > > > > > From: Ash Berlin-Taylor > > Sent: Wednesday, August 14, 2024 7:50 AM > > To: dev@airflow.apache.org > > Subject: RE: [EXT] [DISCUSS] New provider Common.time > > > > CAUTION: This email ori

Re: [DISCUSS] New provider Common.time

, Aug 14, 2024 at 7:42 PM Ferruzzi, Dennis wrote: > I like it. > > - ferruzzi > > > > From: Ash Berlin-Taylor > Sent: Wednesday, August 14, 2024 7:50 AM > To: dev@airflow.apache.org > Subject: RE: [EXT] [DISCUSS] New provider Common.t

Re: [DISCUSS] New provider Common.time

I like it. - ferruzzi From: Ash Berlin-Taylor Sent: Wednesday, August 14, 2024 7:50 AM To: dev@airflow.apache.org Subject: RE: [EXT] [DISCUSS] New provider Common.time CAUTION: This email originated from outside of the organization. Do not click links or open

Re: [DISCUSS] New provider Common.time

> On 14 Aug 2024, at 15:11, Vincent Beck wrote: > > "common" can refer to "common use cases" or "common usage" which makes sense > (at least to me). It can mean multiple things, but I’d like it if we used it to mean one thing in Airflow :)

Re: [DISCUSS] New provider Common.time

+1 - and following the above comments - I also think it might make sense to bring all operators/triggers/sensors from airlfow package to a single provider package (rather than having separate "time", "python", "branch" (or whatever we choose for all the other operators). This is mainly because th

Re: [DISCUSS] New provider Common.time

I like that idea too! +1. The name does not bother me either, "common" can refer to "common use cases" or "common usage" which makes sense (at least to me). On 2024/08/14 13:23:26 Elad Kalif wrote: > Thanks for owning it Rom! > +1 from me > > The common is needed because we have convention wher

Re: [DISCUSS] New provider Common.time

Thanks for owning it Rom! +1 from me The common is needed because we have convention where the providers are packed under entity https://github.com/apache/airflow/tree/main/airflow/providers Common isnt new. We already have common.compat, common.io, common.sql Personally I don't mind about the n

Re: [DISCUSS] New provider Common.time

I like the idea, and you beat me to proposing this since in my prototyping of AIP-72 I realised it would be much much better if 100% of operators et al were providers. One thing in this case though: we shouldn't have `common` in the name as that should be a convention of saying "this provider i

[DISCUSS] New provider Common.time

Hi, I would like to propose a new provider. *Background* As noted in the comment on this PR , several operators and sensors related to time are currently located in the core of Airflow: BranchDayOfWeekOperator, BranchDateTimeOperator, DateTimeSensor,