Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

UX for constraining build-time and runtime dependencies

Aperta
#29 79 commenti 4 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
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
numpy, python
Ambito
build-system

Direzione di ricerca

Inizia esaminando la configurazione proposta in pyproject.toml e il supporto a mesonpy descritto nell’issue. Analizza come interagirebbero le dipendenze di build, runtime_pinnings e le modifiche alle dipendenze del ramo di release; nel report non sono indicati file sorgente o test. Il lavoro è completato quando vengono definiti e implementati i comportamenti di pinning per NumPy, per le sole correzioni di bug e per le dipendenze runtime esatte, con la copertura delle build di release.

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

Descrizione

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.

Lingua principale
Python
Stelle
180
Fork
93
Merge medio
20h 58m
PR unite (30g)
22

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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

Tutte le issue di mesonbuild/meson-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.