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

Introduce pytest integration out of the box

Aperta
#3,594 12 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
30/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
python

Direzione di ricerca

Inizia esaminando la proposta dell’hub PyPI predefinito in #2094 e la gestione esistente di py_test, main_module, dependency declaration e version-marker menzionata nell’issue. Il lavoro è completato quando è stato definito un design per la discovery, gli override delle dipendenze e delle versioni, le dipendenze opzionali e il workflow pytest out of the box.

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

Descrizione

Currently users need to know about pytest-bazel or other ways to integrate rules_python with bazel.

Ideally the discovery and onboarding of new users should be as easy as we can make it to be without making rules_python unclude everything and the kitchen sink.

Some ideas how we could do this:

  • Implement the default pypi hub idea #2094
  • pre-declare the pytest and pytest-bazel dependencies, where we would generate entries in the hub repo with aliases. Maybe we could define a particular default version for everything to work out of the box.
  • create a pytest_test rule where we are using the declared deps.
  • the users can override the pytest and other included deps.
  • use the main_module attribute to launch pytest-bazel. If pytest is not there users would get an error that it could not be imported.

Open questions:

  • can we default to pytest-bazel in all py_test invocations if there is no main or main_module defined?
  • Is "pypi" a good name to reserve as the default hub repo? How does the predeclaring work? We just accept the same args as whl_library but all optional?
  • Who can pre-declare deps and if multiple versions are declared, which one do we chose? We have version marker parsing in rules_python and we can even do resolution based on version ranges, e.g. users declare that they need pytest 7.1 or above and we get the lowest available version that satisfies the conditions. We can also do this by python version since we have marker expression evaluation support.
  • How to handle sharding related optional dependencies?
  • How to handle other features that may require extra plugins?

Design goals

  • no overhead in the number of targets, hence usage of main_module.
  • little maintenance in rules_python.
  • better out of the box experience. How would the users discover the feature?
Lingua principale
Starlark
Stelle
690
Fork
722
Merge medio
1g 55m
PR unite (30g)
38

Guida per i contributori

Apri la 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 bazel-contrib/rules_python

Tutte le issue di bazel-contrib/rules_python

Issue simili

Altre issue su Build System

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.