I also started to use VSCode in parallel on my Chromebook as this is the
best way to get devenv running there (and I believe it's now THE most
popular IDE - including for Python developers). I can check it there as
well.
On Sat, Feb 22, 2020 at 6:33 PM Jarek Potiuk <jarek.pot...@polidea.com>
wrote:
> Right -> the same. Happy to double check with your POC :)
>
> On Sat, Feb 22, 2020 at 6:16 PM Ash Berlin-Taylor <a...@apache.org> wrote:
> >
> > 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
>
>
>
> --
>
> Jarek Potiuk
> Polidea | Principal Software Engineer
>
> M: +48 660 796 129
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
