GitHub user uplsh580 edited a comment on the discussion: [Question]
Bundle-specific Python Path Isolation in Airflow 3.x Git Bundles
Update: I found the solution!
The issue was caused by the subdir parameter in my Git Bundle configuration.
The Root Cause:
In my initial configuration, I had the subdir argument set to "dags":
```json
{
"name": "TESTBED2",
"classpath": "airflow.providers.git.bundles.git.GitDagBundle",
"kwargs": {
"git_conn_id": "GITHUB__airflow-testbed2",
"subdir": "dags", // This was the culprit
"tracking_ref": "AIRFLOW-DEPLOY/develop",
"refresh_interval": 60
}
}
```
When `subdir` is specified in the Git Bundle configuration, Airflow treats that
specific subdirectory as the root for DAG discovery and, crucially, adds only
that subdirectory to the `sys.path`.
Since my internal library `airflow_lib/` was located at the same level as the
`dags/` folder (siblings), it was excluded from the Python path. This led to
the `ModuleNotFoundError` during both DAG parsing and task execution.
**The Fix:**
By removing the `subdir` parameter (or setting it to the root of the
repository), Airflow now recognizes the `{user_code_root}` as the primary
source root. This allows the Python interpreter to correctly resolve the
airflow_lib package while still being able to find the DAGs within the `dags/`
directory.
**Key Takeaway:**
If you have internal packages or utilities at the root of your repository that
are shared across DAGs, do not set the subdir parameter to your DAGs folder in
the bundle configuration. Keep the bundle root as the source root to ensure
sibling packages are importable.
GitHub link:
https://github.com/apache/airflow/discussions/61901#discussioncomment-15803981
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to: [email protected]
