Provide centrally pinned Python CLI tools through uv without requiring a container or Bazel

Aperta
  • Qualcosa non va?
#189 0 commenti 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
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, shell
Ambito
build-system, developer-experience, tooling

Direzione di ricerca

Start by locating the shared tool catalog and tracing how the existing container and Bazel delivery paths consume it. Then assess how a Python package invoked through uv could use those same definitions while preserving the single version authority; done means the uv path works for a pinned DevContainer release and the existing delivery paths remain intact.

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

Descrizione

Use case

As a repository maintainer, I want local development and CI to use the same centrally maintained tool versions without requiring developers or lightweight CI jobs to run a DevContainer or install Bazel. For example, our shared PR workflow runs pre-commit through uvx pre-commit, while developers use the version installed in the DevContainer. This recently meant that CI used pre-commit 4.7.0 while local checks used 4.5.1, allowing an incompatible hook configuration to pass locally and fail in CI.

I want to select one DevContainer release and run its pre-commit version through uv. I should not have to copy individual tool pins into every consuming repository or maintain another requirements file independently of the existing tool catalog.

Proposed solution

Provide a Python package in this repository that can be run through uvx from a pinned Git release, without requiring publication to PyPI. The package should expose a runner for the Python CLI tools defined in the shared catalog, resolve the selected tool to its centrally pinned package version and entrypoint, and execute it in an isolated uv-managed environment. Consumers supply the DevContainer release reference, tool name, and arguments; uv handles installation and caching. A compatible uv installation is a prerequisite and is not bootstrapped or version-pinned by this runner.

The DevContainer repository must remain the central version authority for all three delivery paths: container, uv, and Bazel. Package the existing catalog with the runner and have every delivery path consume the same tool definitions. Do not introduce separately maintained tool versions in Python package metadata, generated consumer wrappers, or downstream repositories. Existing container and Bazel delivery should continue alongside the new uv path. This initial scope covers Python CLI tools such as pre-commit; it does not require uv delivery for every native tool in the catalog.

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.