DR: Choose ownership and layout of tool definitions and pins

Abierto
  • ¿Algo no está bien?
#213 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Refactorización
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
bash, docker
Área
build-system, devops

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Shell
Estrellas
5
Forks
10
Merge medio
23 h 5 min
PR fusionados (30 d)
29

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-score/devcontainer

Todos los issues de eclipse-score/devcontainer

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.