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:
*essential/standard/builtin/primary/core/base/shared*
The vote should be about 2 things:
1. provider name
2. Regardless of the name we choose, the provider should be under the
common directory (as a result have .common. in its path)
for example if we choose essential then should it be: common.essential
or essential
https://github.com/apache/airflow/tree/main/airflow/providers/common
On Mon, Aug 19, 2024 at 1:21 AM Aritra Basu <aritrabasu1...@gmail.com>
wrote:
> 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, <ja...@potiuk.com> wrote:
>
> > 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
> > > > >
> > > > >
> > > >
> > >
> >
>
