Great discussion! Joining delayed. We have this usage in airflowctl too
where AirflowException is the main one even though it isn't imported from
core.
I agree with the consensus. Great idea to make it backward compatible.
Maybe would be good to define a migration calendar roughly.
While we should
Hi Fortytwoo,
thanks for the translation offer. I assume a Simplified Chinese
translation would make much sense. I don't know how large the user base
is but potentially large. Thanks for offering translation and the PR I
saw as well. Without looking at the content technically this looks OK.
Reviewed the proposal.
I'll share some thoughts below.
But one general thing I want to emphasize as we work towards implementation
of the AIP is, this is not going to be easy. Airflow has a lot of
complexity at this point and a lot of interacting interfaces. Dags, tasks,
assets, watchers, asset
Dear Jens and Airflow community,
Thank you for your thoughtful response. I'd like to share my motivation for
this contribution:
Airflow has become an industry standard and provides incredible value in daily
operations. However, I've noticed that many potential users, especially those
in operat
Hi Constance.
the airflow CLI is still needed for some admin commands which arequire
DB access as well is used to start the server components.
One example is DB migration, DB Cleaning utils. This can not be a remote
command (chicken and egg problem).
But all (admin) commands which can be ru
Hi Constance and Jens,
Thanks for the question! The case is exactly as Jens mentioned. Thanks for
the details, Jens.
Yes Jens, you are right. We agreed that the remote command changes will
replace the airflow CLI commands with the airflowctl ones. Since we decided
to eliminate the dedicated versio
Hi Hussein,
Thanks for creating this. @Daniel Standish
, @Tzu-ping
Chung and I (well, mostly them :) ) will take a look. We
have started defining an implementation plan, but it's still early so
perfect timing.
Constance
On Sun, Aug 31, 2025 at 6:23 PM Hussein Awala wrote:
> Hi all,
>
> I’m no
Just to share a little bit of battle-stories.
We discovered some ... interesting ... issues ... This was really a bit of
a puzzle why virtualenvs created in the ARM image of Python 3.11 did not
have SSL support :D.
Just to repeat: *main Python was working*, *ONLY*(!) venvs created in the
image, *
> “If you name it, you can own it
Yep. 100%. Precisely what Ash wrote. I am actually quite happy that many
people say "this is something that is not correct". In a way it makes it a
perfect candidate to pick someone we can "own" - because nobody owns it yet
in the minds of people.
The fact that we
Also - maybe simply someone from our community that we know already can
join you voluntarily - even if you do not know anyone - so anyone who is
willing to join Fortywoo is welcome to raise their hand here :)
One of the conditions we have for a new language is that there is someone
who is already
“If you name it, you can own it”
+1 for Dag, it can be an airflow term, much more so than DAG as an acronym can
be.
> On 2 Sep 2025, at 08:03, Ankit Chaurasia wrote:
>
> I totally agree that "Dag" - it is neither a proper class nor a proper
> variable naming pattern.
>
> "DAG" can be used wh
Generally agree with this too.
`AirflowException` is literally being overused almost to an extent that it
has
become like a dumping ground (along the lines of what `utils` has become)
I would be in favour of removing it too and addressing backcompat concerns
for user facing / custom provider / ho
I totally agree that "Dag" - it is neither a proper class nor a proper
variable naming pattern.
"DAG" can be used when referring directly to the class.
"dag" makes the most sense as it aligns with Python’s snake_case for
identifiers.
*Ankit Chaurasia*
On Mon, Sep 1, 2025 at 11:23 PM Sumit
13 matches
Mail list logo
