Support extras for `tasks.libraries.whl` on classic clusters (follow-up to #1602)

Offen
  • Stimmt etwas nicht?
#7,256 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
55/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
go, python
Bereich
backend, cli

Rechercherichtung

Start by tracing how the CLI resolves tasks.libraries.whl paths during deployment and how it passes wheel library references to classic job clusters; compare that flow with the serverless dependencies handling cited in the issue. The report gives no source files or tests, so first locate those entry points and their tests. Done means a wheel reference with [my-extra] deploys and installs the extra on a classic cluster, while plain wheel references still work.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

DABs Enhancement

Hi, this is a follow-up to #1602. Extras on local wheels work now for serverless environment dependencies (#6291), which is great, but they dont work for tasks.libraries.whl, so jobs on classic job clusters cant use them.

We split our wheel into extras per domain, because we dont want every job to install libraries it does not need, and we want one pin in pyproject.toml instead of a second pin in the job config.

What we see:

  • whl: ./dist/*.whl[my-extra] fails at deploy with no files match pattern: dist/*.whl[my-extra]
  • whl: /Workspace/.../my_package-0.1.0-py3-none-any.whl[my-extra] deploys, but the library install on the cluster fails with "The library file does not exist or the user does not have permission to read the library file"
  • the same absolute path without [my-extra] installs fine, so it looks like the suffix is read as part of the file name

Minimal config:

artifacts:
  my_package:
    type: whl
    build: uv build --wheel
    path: .

resources:
  jobs:
    my_job:
      tasks:
        - task_key: main
          spark_python_task:
            python_file: ./main.py
          libraries:
            - whl: ./dist/*.whl[my-extra]
          new_cluster:
            spark_version: 18.0.x-scala2.13
            node_type_id: <any>
            num_workers: 0

Expected: the wheel installs with the extra, the same as ./dist/*.whl[my-extra] in environment dependencies on serverless.

Workarounds we know: move the job to serverless, or pin the extra libraries again as pypi libraries on the task, which brings back the 2 pins that drift.

If the second part is on the cluster library side and not the CLI, can u route it please?

CLI version: 1.21.0

Vorherrschende Sprache
Go
Sterne
424
Forks
261
Ø Merge
1 T. 21 Std.
Gemergte PRs (30 T.)
210

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.