jscheffl commented on PR #65513:
URL: https://github.com/apache/airflow/pull/65513#issuecomment-4373168336
Args, static checks fail in
```
╭─────────────────────────────────── New airflow.utils module rejected
────────────────────────────────────╮
│ New top-level module(s) detected under airflow-core/src/airflow/utils/:
│
│
│
│ + daemon
│
│ + pidfile
│
│
│
│ Adding new modules under this directory is discouraged. Prefer placing
the code in one of: │
│ - shared/ (when shared across distributions)
│
│ - airflow-core/src/airflow/<module-dir>/ (a dedicated sub-package
alongside the feature it belongs to) │
│ - task-sdk/ (when used by Dag authoring or task execution)
│
│
│
│ If the addition is intentional and has been agreed with the maintainers,
regenerate the allowlist with: │
│
│
│ uv run ./scripts/ci/prek/check_no_new_airflow_core_utils_modules.py
--generate │
│
│
│ and commit the updated
scripts/ci/prek/known_airflow_core_utils_modules.txt.
│
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────╯
```
... which totally makes sense.
Just asking into the round, this does not fall into the "shared" category,
also not into "task-sdk" and for two modules opening another sub-module looks
over-engineered. Would it be okay to add these to exceptions-list for utils?
(Same question posted in Slack for maintainer feedback in
https://apache-airflow.slack.com/archives/C06K9Q5G2UA/p1777916468610069)
--
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]
