That's a very good point about IDE's, I'll double check how PyCharm behaves
(Guessing PyCharm is the most popular one? PyCharm and IntelliJ are the same
engine under the hood, right?)
-a
On Feb 22 2020, at 4:58 pm, Jarek Potiuk <jarek.pot...@polidea.com> wrote:
> > 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
