;> On 2025/03/04 21:13:47 "Oliveira, Niko" wrote:
>>> > +1 to devel-common from me
>>> >
>>> > ____
>>> > From: Ferruzzi, Dennis
>>> > Sent: Tuesday, March 4, 2025 11:21:20 AM
>>> > To:
to me
>>
>> On 2025/03/04 21:13:47 "Oliveira, Niko" wrote:
>> > +1 to devel-common from me
>> >
>> >
>> > From: Ferruzzi, Dennis
>> > Sent: Tuesday, March 4, 2025 11:21:20 AM
>> > To: dev@air
devel-common sounds reasonable
- ferruzzi
From: Jarek Potiuk
Sent: Tuesday, March 4, 2025 10:53 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Turn "tests_common" into separate distribution for
development
CAUTION: This email origi
iko" wrote:
> > +1 to devel-common from me
> >
> >
> > From: Ferruzzi, Dennis
> > Sent: Tuesday, March 4, 2025 11:21:20 AM
> > To: dev@airflow.apache.org
> > Subject: RE: [EXT] [DISCUSS] Turn "tests_common&quo
e aucun risque.
>
>
>
> devel-common sounds reasonable
>
>
> - ferruzzi
>
>
>
> From: Jarek Potiuk
> Sent: Tuesday, March 4, 2025 10:53 AM
> To: dev@airflow.apache.org
> Subject: RE: [EXT] [DISCUSS] Turn "tests_common" into separate distr
+1 for devel-common
On 04.03.25 20:21, Ferruzzi, Dennis wrote:
devel-common sounds reasonable
- ferruzzi
From: Jarek Potiuk
Sent: Tuesday, March 4, 2025 10:53 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Turn "tests_common" int
+1 to devel-common from me
From: Ferruzzi, Dennis
Sent: Tuesday, March 4, 2025 11:21:20 AM
To: dev@airflow.apache.org
Subject: RE: [EXT] [DISCUSS] Turn "tests_common" into separate distribution for
development
CAUTION: This email originated from outs
I am doing a bit more cleanup, and I have found that the easier way to fix
some of the remaining issues will be to clean-up (and remove) the remaining
editable devel dependencies and incorporate them all in the "tests-common"
package.
You can take a look at the PR: https://github.com/apache/airfl
Hello everyone.
I created the PR for that https://github.com/apache/airflow/pull/47281.
It's even nicer than I anticipated. I love the new super-simple workflows
this restructuring finally enabled.
With `uv` and workspace, and the new structure of tests, developing and
running tests for provide
I like this approach, lets do it!
> On 25 Feb 2025, at 16:02, Jarek Potiuk wrote:
>
> airflow-core
> task-sdk
> tests-common
And we could do the same with others:
airflow-core
task-sdk
tests-common
That would guarantee that those will be pure folders and not accidentally
turn into python packages.
For example now we have this:
task_sdk
\__init_.py
src
\ - airflow
\ sdk
An
Actually - after experiencing unrelated error in my PR for "legacy"
namespace packages -
https://github.com/apache/airflow/actions/runs/13524796336/job/37793501020?pr=47064#step:6:36
I have a way better idea:
```
tests-common <- folder
\pyproject.toml
\src
\tes
Yeah, but why would we confuse things more by putting it in the already messy
airflow namespace? That feels like a step backwards to me.
> On 25 Feb 2025, at 15:23, Jarek Potiuk wrote:
>
>> This is the only bit I’m confused about — what the `airflow.` prefix?
>
> Precisely to avoid that `from
> This is the only bit I’m confused about — what the `airflow.` prefix?
Precisely to avoid that `from tests_common" will be used from the root of
the project (commonly added to PYTHONPATH).
The whole discussion is about how to avoid this.
J.
On Tue, Feb 25, 2025 at 3:22 PM Ash Berlin-Taylor
This is the only bit I’m confused about — what the `airflow.` prefix?
> On 25 Feb 2025, at 13:40, Jarek Potiuk wrote:
>
> from airflow.tests_common
Ok. I described a bit more in slack discussions why repeating the folders
is not a good idea (it's prone to tooling that might have different ways of
handling PYTHONPATH for development).
But yeah - having the same name, for distribution and package makes sense.
-> so maybe this will be a good str
BTW. After reading the proposed structure again python-subfolder -> that is
the biggest point to discuss it, and I would rather (at least now) first
move airflow_core to a sub-directory, not necessarily move all "python"
projects to a sub-folder. There is very little value in such grouping, and
eve
> One thing I would like to avoid is having the `[test]` extra show up in
the released packages though (it’s not important, just would be nice if we
can avoid that)
That is already not happening (and won't, all those devel extras in
dependencies (e is gone at the moment I added hatchling, it handl
One thing I would like to avoid is having the `[test]` extra show up in the
released packages though (it’s not important, just would be nice if we can
avoid that)
I wonder if now is also the time to move all the python code under a sub-folder
So something like this
Python_modules/
Airflow_co
+1 to this idea overall.
A bit torn on naming it "common_test_code" -- no strong reason for it but
names like: `airflow_test_utils` or
`airflow_test_shared` sound better to me. No strong objection though.
Thanks & Regards,
Amogh Desai
On Mon, Feb 17, 2025 at 11:16 PM Jarek Potiuk wrote:
> Mai
Main reason is that this might avoid duplication and remove ambiguity of
what is being imported. If we keep the same name, we will have to have
something like that:
a) folder where project is
b) python package we import
So ...if we do tests_common, we will have to do:
tests_common <- folder
Overall +1 on this one. Regarding the naming, why not keeping "tests_common"
instead of "common_test_code"? I am not a big fan of "common_test_code" but it
is obviously just a personal opinion (as it is always with naming :))
On 2025/02/16 13:30:09 Jarek Potiuk wrote:
> > Just wondernig... would
> Just wondernig... would an optional dependency not be the right place to
describe that apache-airflow-providers-google[tests] would have an
dependency to the common_tests subproject?
> Would mean you would need to install via
> pip install -e . -e ./task_sdk[tests] -e. ./providers/google[tests]
> I would love to see some airflow_testing package which will be useful for
testing airflow-related projects and involve independently.
> Certainly, it's not a good thing to have tests import something from
tests.
New packages as projects are cheap and provide more flexibility and are
useful from
+1
Just wondernig... would an optional dependency not be the right place to
describe that apache-airflow-providers-google[tests] would have an
dependency to the common_tests subproject?
Would mean you would need to install via
pip install -e . -e ./task_sdk[tests] -e. ./providers/google[tests]
I would love to see some airflow_testing package which will be useful for
testing airflow-related projects and involve independently.
Certainly, it's not a good thing to have tests import something from tests.
New packages as projects are cheap and provide more flexibility and are
useful from outs
Hello here,
Next phase of the cleanup - it's been sped up by the comment from @kxepal
- https://github.com/apache/airflow/pull/46801#issuecomment-2661415731 - I
have planned to do it a bit later this week, but maybe indeed it's a good
idea to start a discussion now so that people are not confuse
27 matches
Mail list logo
