Add ability to directly reference dependecy libraries from same DAB for Databricks Applications

Offen
  • Stimmt etwas nicht?
#5,094 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Ruhig
Tech-Stack
python
Bereich
cli, cloud

Rechercherichtung

Beginne damit nachzuverfolgen, wie Abhängigkeiten von Anwendungs-YAML und Abhängigkeiten von Bundle-Jobs in databricks-cli behandelt werden, und vergleiche dieses Verhalten anschließend mit der im Issue gezeigten uv-Workspace-Konfiguration. Lege die gewünschte Bereitstellungsreihenfolge und die Auflösung der Abhängigkeiten für eine Anwendung fest, die auf dieselbe Bundle-LIB verweist, einschließlich dessen, was den Package-Feed- oder Volume-Workaround ersetzen soll.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

DABs Enhancement

I have following setup for bundle:

  • Shared library (LIB) which contain set of pandera DataFrameModels (uv-based dependency management, python) which getting build into whl
  • Job (JOB), which uses DataFrameModels from LIB. Job yaml declares LIB as a dependency
  • Databricks App (APP), which also want to use DataFrameModels from that LIB.

Since I can`t declare app dependencies from bundle itself, I either forced to use package feed or put that LIB into volume, so I can reference it in my requirements/pyproject.toml. It itself creates little bit inconsistency, since then I need somehow handle local development with that dependency or run uv build/run where volume is not available.
However, because of the #1958 I also cannot have that library and volume in one package.

So in such setup, DABs force me to have at least two bundles, first with volume, second - with app and library. In addition to it, I am not sure, will app be deployed first and if I will use lifecycle events (lifecycle.started from #4672 what will happen first - whl gets into the volume, or app will restart/redeploy.

In addition, since JOB is referencing LIB whl as a dependency, it means that it is actually delivered to the Databricks. So its there - in the cloud, but app have no any ability to reference it.

I think if application YAML will support dependency declaration from bundle - it will help.
Other way around - better support uv tooling. In my setup I have uv workspaces in place, so can reference dependency from bundle by using it:

dependencies = [
    "LIB",
]

[tool.uv.sources]
LIB = { workspace = true }

Maybe then databricks-cli can do something about that.

Vorherrschende Sprache
Go
Sterne
427
Forks
267
Ø Merge
2 T. 1 Std.
Gemergte PRs (30 T.)
233

Entwicklungsumgebung

  • Enthält ein Dockerfile oder eine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus databricks/cli

Alle Issues in databricks/cli

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.