Re: [VOTE] January 2024 PR of the Month

+1 for #37058 On Tue, Feb 27, 2024 at 9:06 PM Scheffler Jens (XC-AS/EAE-ADA-T) wrote: > Oh I totally missed #36797 - I was eagerly waiting for this and for sure > would like to spend my +1 for this! Great work! > > Sent from Outlook for

Re: [VOTE] January 2024 PR of the Month

Oh I totally missed #36797 - I was eagerly waiting for this and for sure would like to spend my +1 for this! Great work! Sent from Outlook for iOS From: Tzu-ping Chung Sent: Tuesday, February 27, 2024 6:18:41 AM To: dev@airflow.apache.org

Updated pandas constraints for Airflow 2.8.2 (pandas==2.1.4)

Hey here, We've just solved a teething problem with Airflow 2.8.2 pandas dependency that aa-mathias (thanks Mattthias!) reported to us (Andrey fixed it in main already by adding < 2.2 requirement for pandas). The problem is that Pandas 2.2.1 has a problem with sqlalchemy 1.4 compatibility

Re: [DISCUSS] Considering trying out uv for our CI workflows

One more update - I am still looking at it and fine-tuning stuff and will have a few more things coming I found out that we were still using `pip` for `pip constraints generation` (those are the constraints that our users use). I switched that one to `uv` and it's now 30 seconds instead of more

Re: [DISCUSS] Considering trying out uv for our CI workflows

Fantastic results! > It also means that if you've been using breeze and were sometimes afraid to > hit "y" to rebuild the image, being afraid that it will take 20 minutes or > so - not any more. It should be WAY faster now. I'm very excited about this speed up as well as our CI :)

[DISCUSS] DYNAMIC DAG RUNS WITH TASK PRIORITY

Hi, My name is Alvaro and I am a junior developer who is writing his FMP (Final master project) about a project which uses Apache Airflow. I am interested in developing a new feature for Airflow which I think many people could use. MOTIVATION I really think this is a very useful feature to add.

Re: [VOTE] January 2024 PR of the Month

+1 on #36797 On Tue, Feb 27, 2024 at 2:39 AM Jarek Potiuk wrote: > Thanks TP, for bringing it :) > > If I can split my vote between #37101 and #36797 - > that would be it > > On Tue, Feb 27, 2024 at 6:19 AM Tzu-ping Chung > wrote: > > > I want to

Re: Bad mixing of decorated and classic operators (users shooting themselves in their foot)

I can't see which problem is solved by allowing running one operator inside another. *Propagate templated fields?* In most cases it could be changed for a particular task or entire operator by monkey patching, which in this case more safe rather than run operator in operator. Or even available

Re: [DISCUSS] Considering trying out uv for our CI workflows

Summarising where we are: After ~24 hrs of operations, it looks really cool and fulfills (and actually exceeds) all my expectations. * Multiple PRs succeeded, we got quite a few constraints updated automatically after successful canary runs:

Re: Bad mixing of decorated and classic operators (users shooting themselves in their foot)

Yeah. I kinda like (and see it emerging from the discussion) that we can (which I love) have cake and eat it too :). Means - I think we can have both 1) and 2) ... 1) We should raise an error if someone uses AnOperator in task context (the way TP described it would work nicely) - making calling

Re: Bad mixing of decorated and classic operators (users shooting themselves in their foot)

I think manually using *execute*, *poke*, *choose_branch* and etc. should be considered as an antipattern, these methods only should be invoked by Airflow Worker. You never know what should be done before, especially if it about deferrable operator or sensors in reschedule mode On Tue, 27 Feb

Re: Bad mixing of decorated and classic operators (users shooting themselves in their foot)

Interesting! Jarek and I had a bit of a discussion on slack a couple of months ago in the context of Operators Need to Die (if I recall correctly). The idea behind Operators is that you have a vetted way of executing a certain logic apart from the boilerplate (i.e. execute, post_execute) that