Cool!
On Mon, Feb 24, 2020 at 3:58 PM Ash Berlin-Taylor wrote:
> https://github.com/apache/airflow/pull/7517 has been merged now, so we
> have kept airflow.DAG working, just lazily loaded.
>
> -a
> On Feb 23 2020, at 10:53 pm, Kaxil Naik wrote:
> > Yay !! Nice suggestion Kamil, good work Ash
>
https://github.com/apache/airflow/pull/7517 has been merged now, so we have
kept airflow.DAG working, just lazily loaded.
-a
On Feb 23 2020, at 10:53 pm, Kaxil Naik wrote:
> Yay !! Nice suggestion Kamil, good work Ash
> ᐧ
>
> On Sun, Feb 23, 2020 at 10:51 PM Ash Berlin-Taylor wrote:
> > Thanks
Yay !! Nice suggestion Kamil, good work Ash
ᐧ
On Sun, Feb 23, 2020 at 10:51 PM Ash Berlin-Taylor wrote:
> Thanks Kamil! You rock
>
> https://github.com/apache/airflow/pull/7517
> On Feb 23 2020, at 10:36 pm, Ash Berlin-Taylor wrote:
> > Yeah both Pycharm and VSCode are perfectly happy with
Thanks Kamil! You rock
https://github.com/apache/airflow/pull/7517
On Feb 23 2020, at 10:36 pm, Ash Berlin-Taylor wrote:
> Yeah both Pycharm and VSCode are perfectly happy with that (and jump to
> impl/defintion works right which is better than the type stub version too)
>
> PR incoming. I
Yeah both Pycharm and VSCode are perfectly happy with that (and jump to
impl/defintion works right which is better than the type stub version too)
PR incoming. I don't think we need to worry about the method Celery is going to
as (I think) Py3.6 supports PEP-562 natively.
-ash
On Feb 23 2020,
Ahha, I was wondering if there was something like typing.TYPE_CHECKING but for
static analyzers/IDEs. I like that approach. Testing it out now.
On Feb 23 2020, at 10:28 pm, Kamil Breguła wrote:
> Hello,
>
> I admit that I do not follow the subject closely, but I think that
> here is the answer.
Hello,
I admit that I do not follow the subject closely, but I think that
here is the answer.
https://github.com/celery/celery/blob/master/celery/__init__.py#L63-L78
We can also create a module with lazy-loaded attributes:
https://github.com/celery/celery/blob/master/celery/__init__.py#L158-L184
I've managed to get type stubs working in VSCode (and intellij), so that may be
an option.
TBH I think I'm leaning somewhat towards 5 -- after all that would then go some
way to clarify the distinction between DAG and DagModel (i.e. DAG doesn't
belong in models, it's not a DB model)
On Feb 23
1. Just have a deprecation warning (which it's not even clear if PEP-562
style will show a nice (!) warning in IDEs or just at run time
2. I learn to live with from airflow.models.dag import DAG
3. After we change airflow.models to not import all the sub-modules
automatically, go
Gah not only that, vscode also ignores __all__ settings which is really bad
form.
Pycharm at least does respect __all__ for what to show in the module, and also
respects type stub files (.pyi) when completing constructor args etc.
In short IDEs are terrible at dynamic languages, but it is what
I tried an example with PEP-562 but the autocomplete didn't work in Pycharm
and still showed the deprecated function.
I agree we should have a deprecation warning before we should have changed
it. How about we introduce a deprecation warning in the next version
(1.10.10) ?
Regards,
Kaxil
ᐧ
On
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
wrote:
> Right -> the same.
Right -> the same. Happy to double check with your POC :)
On Sat, Feb 22, 2020 at 6:16 PM Ash Berlin-Taylor 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
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 wrote:
> > My proposal here:
> > Add in a _getattr_ based lazy
> 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
To duplicate/re-iterate my comments from that PR.:
I've just realised that PR will remove the from airflow import DAG which means
that (almost) every single dag in existince will need to be updated else it
will be 100% broken. I can not stress just how much that is a non-starter for
me.
So.. In the meantime our new contributor Matt implemented the move and we
are merging it https://github.com/apache/airflow/pull/7456 as we have
already several approvals. I hope it will help us to move faster a bit :)
We might have another discussions on the models __init__.py stuff removal
and
I'm totally fine with that.
Cheers, Fokko
Op di 18 feb. 2020 om 13:46 schreef Jarek Potiuk :
> I believe this is one of the cases where we can just go with the consensus
> indeed :).
>
> J.
>
> On Tue, Feb 18, 2020 at 12:51 PM Ash Berlin-Taylor wrote:
>
> > Do we need to have a vote on it? I'm
I believe this is one of the cases where we can just go with the consensus
indeed :).
J.
On Tue, Feb 18, 2020 at 12:51 PM Ash Berlin-Taylor wrote:
> Do we need to have a vote on it? I'm mostly interested in answering the
> question about vote in general terms rather than this specific case)
>
Do we need to have a vote on it? I'm mostly interested in answering the
question about vote in general terms rather than this specific case)
What do we need votes on, and when is "yeah no one complained, let's do it"
enough?
For example if someone had created a PR for this and had appropriate
All right. I turn it into vote then :)
On Tue, Feb 18, 2020 at 7:45 AM Driesprong, Fokko
wrote:
> I don't have any objection, however, this isn't a [VOTE] right? ;)
>
> Op di 18 feb. 2020 om 00:08 schreef Jarek Potiuk >:
>
> > I see that it's quite welcome change, so I think if no-one else
I don't have any objection, however, this isn't a [VOTE] right? ;)
Op di 18 feb. 2020 om 00:08 schreef Jarek Potiuk :
> I see that it's quite welcome change, so I think if no-one else objects
> within three days, I consider that a lazy consensus (not that lazy in fact)
> :)
I see that it's quite welcome change, so I think if no-one else objects
within three days, I consider that a lazy consensus (not that lazy in fact)
:) https://www.apache.org/foundation/voting.html
On Mon, Feb 17, 2020 at 6:14 PM Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:
> +1
>
> On
+1
On Mon, Feb 17, 2020 at 7:32 AM Daniel Imberman
wrote:
> +1 on my end!
>
> via Newton Mail
> [
> https://cloudmagic.com/k/d/mailapp?ct=dx=10.0.32=10.14.6=email_footer_2
> ]
> On Mon, Feb 17, 2020 at 12:30 AM, Driesprong, Fokko
>
> wrote:
> I like this as well. It will hopefully also reduce
+1 on my end!
via Newton Mail
[https://cloudmagic.com/k/d/mailapp?ct=dx=10.0.32=10.14.6=email_footer_2]
On Mon, Feb 17, 2020 at 12:30 AM, Driesprong, Fokko
wrote:
I like this as well. It will hopefully also reduce the memory footprint of
Airflow.
The only thing I can think of is that it
I like this as well. It will hopefully also reduce the memory footprint of
Airflow.
The only thing I can think of is that it will reduce the test coverage, but
that's a vanity metric anyway :-)
Cheers, Fokko
Op za 15 feb. 2020 om 13:37 schreef Ash Berlin-Taylor :
> I'm massively in favour of
I'm massively in favour of this. And as a side effect it would solve an issue a
reports almost two years ago https://issues.apache.org/jira/browse/AIRFLOW-1931
(https://issues.apache.org/jira/browse/AIRFLOW-1931?jql=project%20%3D%20AIRFLOW%20AND%20text%20~%20%22logging%20import%22)
The one
TL;DR; I would like to ask the community for opinion about reducing (or
even removing) the number of automated imports we have in
`airflow/__init__.py` for Airflow 2.0.
This issue is plaguing us for quite a while already and I think we have a
perfect opportunity to solve it in AIrflow 2.0.
28 matches
Mail list logo
