Re: Naming things: What should the imports in dag files for DAG etc. be?

Chiming in here mostly from the DAG author perspective! I like `airflow.sdk` best. It makes it super clear what the user is supposed to interact with and what Airflow’s “public” interface is. Importing from `airflow.models` has always felt weird because it feels like you’re going into Airflow’s

What to expect from FAB provider after AIP-79

Hey everyone, I have started work on AIP-79 and would like to share what using the FAB provider would be like for users after the changes are released. In Airflow 3, FAB will have DB reset, migrate, and downgrade commands similar to Airflow DB commands. Contributors can add migrations to FAB, a

Re: What to expect from FAB provider after AIP-79

I think that is a good compromise between "full" integration and "optional integration". And as long as we document and explain it with some example scenarios ("what to do if you upgrade the FAB provider separately") - this should be fine. It will likely work fine if we do some "consistency check"

Re: Naming things: What should the imports in dag files for DAG etc. be?

To add another DAG Author perspective, I'd vote for: #1 (from airflow ...) but without side-effects or #2 (from airflow.sdk ...). To compare with other X-as-code tools: - Luigi has top-level *Luigi.task* (is class-based) - Prefect has top-level *from prefect import flow, task* (and seems to refer

[ANNOUNCE] Apache Airflow Newsletter August 2024

Hey All, The August Issue of the Apache Airflow Newsletter is out! Please read it here Or subscribe here to get it directly in your inbox < https://apache.us14.list-manage.com/subscribe?u=fe7ef7a8dbb32933f30a10466&id=65cb5665fa > -- B

Re: What to expect from FAB provider after AIP-79

One thing to keep in mind is that this sets the precedent for providers managing their own db "stuff". So while it may be rare for FAB, we should look at this from a general "provider with db stuff" perspective. And other use cases could have more frequent changes. Overall I also think this strike

Re: What to expect from FAB provider after AIP-79

+1 from my side. But compared to expose explicit CLI for migrations for providers I'd prever to have DB stuff upgrade and downgrade implicitly called/executed/delegated to the provider package. Would it not be good to "just register" the DB created/upgrade/downgrade/reset" hooks for each provider

Re: [VOTE] Release Airflow 2.10.1 from 2.10.1rc1

+1 (binding) - tested reproducibility, checksums, signatures, licences, ran a few DAGs with it. Did not see any issues. Can confirm the fixes/changes I contributed are in: - Reporting of Scarf in buckets (#41898/#41898) - Deprecation of warnings in Plugins Manager (#4173/#41793) - Bump of Micr