> My proposal here:
> Add in a _getattr_ based lazy import for DAG to airflow/__init__.py module
I am all for it - if we can do it in this way, then it is indeed
better for the users.
>
> 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.
I would only be for it if the PEP-562 change works fine with IDE
support. Many of our users use IDEs to write their DAGsand they can
get confused where to import the DAGs from. If the PEP-562 works fine
with the IDEs, and they are smart enough to figure this out, I am ok
with that.
On a related note - I fully agree with the "clear API" approach for
DAG developers. We did not have clear rules for that so far.
Eventually (I think 2.0 is good time for that) we should have a clear
statement what really the API is for DAG writers. We should issue at
first a deprecation warning and then error if someone tries to use
something not explicitly allowed from the DAG. It should not be a
convention ("from airflow.* is allowed in documentation"). It should
be enforcement. We can do it in scheduler - as we are parsing the DAGs
on our own and we can find out what imports the users are using. We
could even think about adding those deprecations in 2.0. There are not
that many things that should be importable from 'airflow.*'. And that
should be rather easy - I am playing now with AST parser and it is
rather straightforward - we just need to generate list of "allowed"
imports .
> (I'm less worried about the internal API airflow users internally, so
> airflow.models.TaskInstance vs airflow.models.task_instance.TaskInstance is
> okay for me. I find the later uglier but if it doesn't affect users I don't
> mind it)
>
> Ash
--
Jarek Potiuk
Polidea | Principal Software Engineer
M: +48 660 796 129
