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

Introduce pytest integration out of the box

Geschlossen
  • Stimmt etwas nicht?
#3,594 12 Kommentare 0 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
30/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
python
Bereich
build-system, testing

Rechercherichtung

Beginne mit der Prüfung des Vorschlags für den standardmäßigen PyPI hub in #2094 sowie der im Issue erwähnten Handhabung von py_test, main_module, dependency declaration und version-marker. Als abgeschlossen gilt die Aufgabe, wenn ein geklärtes Design für Discovery, Dependency-Overrides und Versionen, optionale Dependencies sowie den pytest-Workflow out of the box vorliegt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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?
Vorherrschende Sprache
Starlark
Sterne
687
Forks
726
Ø Merge
1 T. 6 Std.
Gemergte PRs (30 T.)
83

Entwicklungsumgebung

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

Alle Issues in bazel-contrib/rules_python

Ähnliche Issues

Weitere Issues zu Build System

Neue Issues direkt in Ihr Postfach

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