Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

UX for constraining build-time and runtime dependencies

Offen
  • Stimmt etwas nicht?
#29 79 Kommentare 4 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Veraltet
Tech-Stack
numpy, python
Bereich
build-system

Rechercherichtung

Beginne damit, die vorgeschlagene Konfiguration in pyproject.toml und die im Issue beschriebene mesonpy-Unterstützung zu prüfen. Verfolge, wie sich Build-Zeit-Abhängigkeiten, runtime_pinnings und Abhängigkeitsänderungen im Release-Branch gegenseitig auswirken würden; im Bericht werden keine Quelldateien oder Tests genannt. Als abgeschlossen gilt die Definition und Implementierung des Pinning-Verhaltens für NumPy, nur Bugfix-Versionen und exakte Laufzeitabhängigkeiten einschließlich der Abdeckung von Release-Builds.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
Python
Sterne
180
Forks
93
Ø Merge
20 Std. 58 Min.
Gemergte PRs (30 T.)
22

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus mesonbuild/meson-python

Alle Issues in mesonbuild/meson-python

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.