Ash what is your recommendation for the users should we follow your suggestion? This means that the big big big joy of using airflow constraints and getting a working environment with all required providers will be no more. So users will get a working "Vanilla" Airflow and then will need to figure out how they are going to tackle independent providers that may not be able to coexist one with another. This means that users will need to create their own constraints mechanism and maintain it.
>From my perspective this increases the complexity of getting Airflow to be production ready. I know that we say providers vs core but I think that from users perspective providers are an integral part of Airflow. Having the best scheduler and the best UI is not enough. Providers are a crucial part that complete the set. Maybe eventually there should be something like a provider store where there can be official providers and 3rd party providers. This may be even greater discussion than what we are having here. It feels more like Airflow as a product vs Airflow as an ecosystem. On Thu, Apr 7, 2022 at 12:27 AM Collin McNulty <col...@astronomer.io.invalid> wrote: > I agree with Ash and Tomasz. If it were not for the history, I think in an > ideal world even the providers currently part of the Airflow repo would be > managed separately. (I'm not actually suggesting removing any providers.) I > don't think it's a matter of gatekeeping, I just think it's actually kind > of odd to have providers in the same repo as core Airflow, and it increases > confusion about Airflow versions vs provider package versions. > > Collin McNulty > > On Wed, Apr 6, 2022 at 4:21 PM Tomasz Urbaszek <turbas...@apache.org> > wrote: > >> I’m leaning toward Ash approach. Having providers maintaining the >> packages may streamline many aspects for providers/companies. >> >> 1. They are owners so they can merge and release whenever they need. >> 2. It’s easier for them to add E2E tests and manage the resources needed >> for running them. >> 3. The development of the package can be incorporated into their company >> processes - not every company is used to OSS mode. >> >> Whatever way we go - we should have some basics guidelines and >> requirements (for example to brand a provider as “recommended by community” >> or something). >> >> Cheers, >> Tomsk >> >
