ashb commented on issue #7456: [AIRFLOW-6817] - Move airflow __init__.py imports to sub-packages URL: https://github.com/apache/airflow/pull/7456#issuecomment-589969717 I've thought about this a bit more, and I'm coming at this from a different point of view than simple migration - that of user facing API and what we should expose to them. Also the easier we make the migration the more likely it is to not leave users behind. So if they _can_ run old dags with new Airflow so much the better. Lets take a lesson from Django here, they've thought long and hard about how to do migrations and upgrades. In summary: If code works in one version without warnings, it MUST work in the next version but can issue deprecation warnings, and can only be removed in the release after that. Also to me, `from airflow import DAG` is nicer -- why should the DAG authors have to care about the exact internal implementation of where we've chosen to move this class to now?. Airflow and DAGS go hand in hand -- with PEP-562 we can have lazily imported classes but still present a nice interface to users. And plus we can then re-arrange things later under the hood without having to affect our users. After all, what is the harm if the importing everything is solved? My proposal here: - Add in a `_getattr_` based lazy import for DAG to airflow/__init__.py module - Do _NOT_ issue a deprecation warning for this - Revert the change to all the imports in example dags etc so that those do `from airflow import DAG`.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
