DR: Choose ownership and layout of tool definitions and pins

Offen
  • Stimmt etwas nicht?
#213 1 Kommentar 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
35/100
Issue-Typ
Refactoring
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
bash, docker
Bereich
build-system, devops

Rechercherichtung

Read tools/lockfiles/*.lock.json, tools/providers.json, and the review discussion on #209 first; compare how each handles Python, native archives, release .deb packages, and APT policies. Decide which option best supports adding, updating, and removing tools while maintaining one pin and preserving container and Bazel delivery paths. Record the chosen ownership, alternatives, and migration steps in small follow-up issues.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Decision to make

Where should tool definitions, selected versions and artifact checksums be authored, and which files should be derived from them? This issue records an open design decision; no layout has been chosen.

Native tool pins currently live in tools/lockfiles/*.lock.json, which Bazel/rules_multitool and the container installer consume. Python pins, APT policies and special release/setup metadata live in tools/providers.json. Each tool should retain one authoritative version choice while we make ownership and automated updates consistent across these provider types.

The discussion started in the review of #209. It is a bounded follow-up to #155 and #190; the choice to consolidate our own provisioning in #190 remains in place.

Options

  • One authored catalog: move native artifact definitions into providers.json and derive the lockfile inputs needed by Bazel. This puts each tool's provider and pin together, but adds generation/adaptation.
  • Provider definitions plus lock data: keep installation/provider metadata separate from concrete versions and artifacts, using appropriate lock data for each provider. This separates responsibilities, but spreads a tool's information across files.
  • Retain the current split: clarify ownership and automate updates in the existing locations. This minimizes migration and adapters, but keeps different metadata locations for native and other tools.

Compare these against ordinary operations: adding a tool, updating its version and removing it. Include Python, native archives, release .deb packages such as Dive and bazel-compile-commands, and APT policies. Distinguish exact artifact pins from distribution constraints; a version field alone does not lock transitive dependencies.

Constraints and outcome

  • Maintain each pin once and preserve the existing container and supported Bazel delivery paths.
  • Justify any additional generation, adapters or schema machinery by the maintenance they save.
  • Record the chosen ownership/layout, alternatives and migration steps in small follow-ups. No universal format or Bazel packaging for every tool is required.

APT snapshotting/transitive locking, uv delivery (#189) and a GitHub Pages overview are separate work.

Work that can proceed

  • #210 fixes incomplete native artifact refreshes using the current metadata contract.
  • #211 expands Renovate discovery over the current native and Python pins. It neither moves metadata nor establishes the final catalog layout; extraction rules can be adapted after this decision.

Neither PR depends on choosing an option here. Release/setup providers such as Dive and bazel-compile-commands remain outside those PRs' update automation.

Vorherrschende Sprache
Shell
Sterne
5
Forks
10
Ø Merge
23 Std. 5 Min.
Gemergte PRs (30 T.)
29

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Keine 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 eclipse-score/devcontainer

Alle Issues in eclipse-score/devcontainer

Ähnliche Issues

Weitere Issues zu Shell/Bash

Neue Issues direkt in Ihr Postfach

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