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 > > > > >
