+1
Similar view to Jed. I view this as adding a feature, rather than
breaking compatibility.
On Thu, Aug 4, 2022 at 3:20 PM Jed Cunningham
wrote:
> +1. I view it as adding a feature vs breaking compatibility.
>
> On Thu, Aug 4, 2022 at 4:15 PM Ferruzzi, Dennis
> wrote:
>
>> I definitely like
+1. I view it as adding a feature vs breaking compatibility.
On Thu, Aug 4, 2022 at 4:15 PM Ferruzzi, Dennis
wrote:
> I definitely like it, I love reducing boilerplate code like that.
>
>
> --
> *From:* Ash Berlin-Taylor
> *Sent:* Tuesday, August 2, 2022 3:43 AM
>
I definitely like it, I love reducing boilerplate code like that.
From: Ash Berlin-Taylor
Sent: Tuesday, August 2, 2022 3:43 AM
To: dev@airflow.apache.org
Subject: [EXTERNAL] Auto-registering of DAGs in DAG file? (no `as dag` needed?)
CAUTION: This email
Less is more. I like the lack of "as dag".
I think it's not really a breaking change.
We can easily argue we are adding functionality rather than introducing a
breaking change. I think the only reason why someone would create a DAG in
a function is to return it and eventually add it to
Ah I should have checked your PR, sorry. I was looking at the first example. In
general I like the idea of removing the `as dag` in the context manager syntax.
Best,Felix
Sent with [Proton Mail](https://proton.me/) secure email.
--- Original Message ---
On Tuesday, August 2nd, 2022 at
Will this impact DAG file processing time?
If we consider to include the change, we might also need to consider
informing the user that such functions need to be lightweight inline with
what we've here for top-level-code best practices:
For me having to add “as dag” is somewhat non-evident. Also, it’s a few less
boilerplate characters you have to write which I think is a good thing in this
case.
Curious on the edge cases in DAG generation as mentioned by Felix, but I like
the idea so +1 for me.
Bas
> On 2 Aug 2022, at
Hey Ash,
I personally don't like it, because it is not obvious to me.
Also what happens if you return the `dag_2` variable and set the return value
in the global context to `dag_2` as well? This is how I used to do it when
generating DAGs - and in my opinion this is pythonic way of doing it
Hello all,
I'm on a bit of a kick thinking about developer (specifically DAG
author) experience and if there is anything we can
Some time ago there was a previous conversation about if we
should/could "autoregister" DAGs, rather than just looking at the
objects in the top level (globals())
