Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

UX for constraining build-time and runtime dependencies

Ouverte
#29 79 commentaires 4 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
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
numpy, python
Domaine
build-system

Piste de recherche

Commencez par examiner la configuration proposée dans pyproject.toml et la prise en charge de mesonpy décrite dans l’issue. Analysez comment les dépendances de build, runtime_pinnings et les modifications des dépendances de la branche de release interagiraient ; aucun fichier source ni test n’est mentionné dans le rapport. Le travail est considéré comme terminé lorsque le comportement de pinning pour NumPy, les versions limitées aux corrections de bugs et les dépendances d’exécution exactes est défini et implémenté, avec une couverture pour les builds de release.

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

Description

enhancement question

There is a practical UX problem with pyproject.toml that we need to solve. A short description would be:

  • Any project that builds against the numpy C API has to deal with API and ABI compatibility (see the numpy docs on that for details).
  • as a consequence, the dependency specification for local development is different from the one needed for uploading an sdist to PyPI:
    • for local development, you want loose dependencies, e.g. numpy >= 1.19.5 (both a build and runtime dep)
    • in sdist released to PyPI you want: oldest-supported-numpy (build dep metapackage, contains == pins per platform) and numpy>='buildtime_dep,<1.25.0' # should be N+3whereN is current minor version.

That is obviously a complex set of dependencies to express in pyproject.toml, and we can't have two sets in there at the same time. The solution @FFY00 and I just discussed is:

  1. On the main branch, use the loose development dependencies (numpy>=1.19.5)
  2. In the CI job(s) that produce artifacts for release to PyPI, ensure that the lowest supported dependencies (which may be platform-dependent) are installed.
  3. In the release branch, replace the dependencies with the build-time deps needed for uploading to PyPI.
  4. Have support in mesonpy for the various kinds of pinnings people need for releases and API/ABI compatibility.

A rough sketch of how (4) could look:

[build-system]
requires = [
  "numpy >= 1.19.5",  # replace with (e.g.) `oldest-supported-numpy` in a release branch
]

[tool.mesonpy]
runtime_pinnings = [
  # if build version detected is 1.20.3, replace with `>=1.20.3` (while preserving the upper bound,
  # so end result would be for example `'>=1.20.3,<1.25.0')
  "numpy = 'pin_compatible'",
  "pythran = 'bugfix_only'",  # if build version detected is 0.10.0, override the build dependency with `'>=0.10.0,<0.11.0'`
  "torch = 'exact'",  # runtime version must equal build-time version (PyTorch has no ABI stability guarantees)
]

Note that this feature is needed for some other packages than just NumPy too (basically every package offering a C/C++ API has to deal with this), but NumPy alone is important enough - every package containing even a single Cython extension which uses NumPy has to deal with this. However, it's probably still a bit too specific to want native support in pyproject.toml via a standard that all tools must implement. Hence the choice to put this in mesonpy.

Langage dominant
Python
Étoiles
181
Forks
96
Merge moyen
18 h 23 min
PR mergées (30 j)
12

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

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 mesonbuild/meson-python

Toutes les issues de mesonbuild/meson-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

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