moomindani commented on issue #22330: URL: https://github.com/apache/airflow/issues/22330#issuecomment-4552870876
Thanks for the ping @eladkal — looking at this from the Databricks side after going through both prior PRs (#22331, #48738). As I read the original issue, the motivation in 2022 seemed to be around hosting notebooks in an Airflow repo and getting the benefits of Jinja templating, git version control, and orchestration around them. In 2026 the actual needs there look largely covered by what the provider ships today: | Original need (as I read it) | What now solves it | |---|---| | git-versioned notebooks | **Git Folders** — already supported in this provider via `create_repo` / `update_repo` / `get_repo_by_path`. Typical pattern: `update_repo` to refresh, then `DatabricksRunNowOperator` against a notebook in that folder. | | runtime parameterization | Notebook **widgets** + `base_parameters` on `DatabricksRunNowOperator` / `DatabricksSubmitRunOperator`. This covers the vast majority of what people reach for Jinja-on-notebooks to do. | | end-to-end from Airflow | Git Folders + existing operators is end-to-end. | What's left is a narrow gap — dynamically authoring/uploading notebook content from a DAG, or importing `HTML` / `DBC` / `JUPYTER` artifacts — but in practice that's not a workflow I see much in the field, and users who genuinely need it can call `databricks-sdk`'s `WorkspaceClient.workspace.import_()` directly from a PythonOperator. Given that, and given two stalled attempts already, I'd lean toward **closing this as won't fix** and pointing users at Git Folders + widgets. Happy to revisit if a concrete use case shows up that the alternatives genuinely don't cover. -- 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]
