kaxil commented on PR #53149:
URL: https://github.com/apache/airflow/pull/53149#issuecomment-3090513420
@potiuk I appreciate the analysis of the nested `_shared` approach, but I
think it breaks down quickly with real-world examples that we will encounter
with 3.1. Let me illustrate with a concrete scenario:
Consider this realistic structure:
```
shared/
├── config/
├── logging/
├── timezone/
└── serialization/
```
### Natural Dependencies:
- `config` needs `timezone` (for timestamp parsing in config files)
- `logging` needs `config` (to read logging configuration)
- `logging` needs `timezone` (for log timestamps)
- `serialization` needs `timezone` (for datetime serialization)
This creates a **diamond dependency** that's completely natural:
```
config ----\
/ \ \
timezone logging serialization
\ / /
\ / /
\/-------/
```
### With Nested Approach:
1. **Where do we put timezone?** It's needed by everyone
2. **Import paths become nightmarish:**
```python
# In logging module:
from ._shared.config._shared.timezone import utc_now # If timezone is
under config
# OR
from ._shared.timezone import utc_now # If timezone is top-level
from ._shared.config import get_setting # But config also needs timezone!
```
3. **Forced artificial hierarchy:** You'd have to pick an arbitrary "parent"
for timezone, even though it's used by multiple modules at the same level.
4. **Maintenance nightmare:** Developers need to memorize which modules are
nested where, and imports become increasingly complex.
### With Vendoring:
```python
# Clean, predictable imports in any shared module:
from ._vendor.timezone import utc_now
from ._vendor.config import get_setting
from ._vendor.serialization import serialize_datetime
```
Your approach tries to solve cross-module imports by enforcing a strict
hierarchy, but **shared utility code is inherently non-hierarchical**
especially for project like ours imo and this can't be forced into a tree
structure without significant architectural compromises imo.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
