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