DR: Choose ownership and layout of tool definitions and pins

Aperta
  • Qualcosa non va?
#213 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
bash, docker
Ambito
build-system, devops

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Shell
Stelle
5
Fork
10
Merge medio
23h 5m
PR unite (30g)
29

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-score/devcontainer

Tutte le issue di eclipse-score/devcontainer

Issue simili

Altre issue su Shell/Bash

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.