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 <gopidesupa...@gmail.com> wrote: > 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 <kaxiln...@gmail.com> wrote: > > > 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 <t...@astronomer.io.invalid> > > wrote: > > > > > Random idea, how about standard? Like how we can Python’s stock > libraries > > > standard libraries. > > > > > > > > > > On 16 Aug 2024, at 22:19, Elad Kalif <elad...@apache.org> wrote: > > > > > > > > What about primary provider? > > > > > > > > בתאריך יום ו׳, 16 באוג׳ 2024, 16:49, מאת Jarek Potiuk < > > ja...@potiuk.com > > > >: > > > > > > > >> 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 granular (that would be a good name - but for reasons > explained > > > >> above, I think it's better to have "one" such provider with all the > > > basic > > > >> operators). > > > >> > > > >> Speaking of which, how would > > > "*apache-airflow-providers-basic-operators*" > > > >> sound ? I think "Base" is also used in airflow for different things > - > > > >> extendability rather than reusability. > > > >> > > > >> And yes - the extra provider will be pre-installed - so no need to > > > install > > > >> anything extra from the user's point of view.. Main benefit of > having > > > it in > > > >> a separate provider will be that it will be separately upgradeable - > > no > > > >> need to upgrade airflow to get new features of PythonOperator for > > > example. > > > >> > > > >> > > > >> J > > > >> > > > >> On Fri, Aug 16, 2024 at 12:50 PM Ash Berlin-Taylor <a...@apache.org> > > > wrote: > > > >> > > > >>> 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 > > > <b...@astronomer.io.INVALID > > > >>> > > > >>> wrote: > > > >>>> “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 additional provider packages. > > > >>>> > > > >>>> My suggestion is therefore to keep several key operators/sensors, > > e.g. > > > >>> Bash/Python/EmptyOperator, and I'd be fine with putting everything > > else > > > >> in > > > >>> a “common" provider. > > > >>>> > > > >>>> Bas > > > >>>> > > > >>>>> On 16 Aug 2024, at 11:52, Pierre Jeambrun <pierrejb...@gmail.com > > > > > >>> wrote: > > > >>>>> > > > >>>>> I also like core > > > >>>>> > > > >>>>> Le ven. 16 août 2024 à 11:48, rom sharon <rom.sharo...@gmail.com > > > > a > > > >>> écrit : > > > >>>>> > > > >>>>>> +1 for “core” > > > >>>>>> > > > >>>> > > > >>>> > > > >>>> > > --------------------------------------------------------------------- > > > >>>> 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 > > > > > > > > >
