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

Ouverte
  • Quelque chose ne va pas ?
#189 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
python, shell
Domaine
build-system, developer-experience, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Shell
Étoiles
5
Forks
10
Merge moyen
23 h 5 min
PR mergées (30 j)
29

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Aucun Dockerfile ni fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de eclipse-score/devcontainer

Toutes les issues de eclipse-score/devcontainer

Issues similaires

Plus d'issues Shell/Bash

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.