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

test_run_with_command_flags fails on macOS (BSD printenv doesn't support --version)

Geschlossen Anfängerfreundlich
#708 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
88/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
python
Bereich
cli, testing

Rechercherichtung

Beginne mit tests/test_cli.py::test_run_with_command_flags und untersuche, wie dort dotenv run printenv --version aufgerufen wird. Ersetze den betriebssystemspezifischen Sentinel durch den vorgeschlagenen Python-Befehl, der argv ausgibt, und führe diesen Test mit pytest oder tox auf macOS aus. Bestätige, dass die Assertion zur Weiterleitung der Flags erfolgreich ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Description

tests/test_cli.py::test_run_with_command_flags fails when running the test suite (via tox or pytest) on macOS.

tests/test_cli.py::test_run_with_command_flags FAILED

AssertionError: Unexpected exit code 1 (expected 0)
stdout:

stderr:
printenv: illegal option -- -
usage: printenv [name]

assert 1 == 0

Root cause

The test runs dotenv run printenv --version and asserts it exits 0, to verify that dotenv run forwards flags to the wrapped command instead of parsing them itself (added in #607 / #612).

  • On Linux, printenv is GNU coreutils' version, which supports --version and exits 0.
  • On macOS, printenv is the BSD version, which does not support --version at all, and exits 1 with printenv: illegal option -- -.

So the test is actually working as intended (dotenv run correctly passes --version straight through to printenv rather than swallowing it), but the assertion only holds on systems with GNU printenv.

Why this hasn't been caught in CI

.github/workflows/test.yml only runs the test matrix on ubuntu-latest and windows-latest - there's no macos-latest job, so this has never surfaced there.

CONTRIBUTING.md tells contributors to just run tox or pytest, with no mention that the suite assumes a GNU userland / Linux, so a macOS contributor following the documented steps hits this with no explanation.

Suggested fix

Replace the OS-specific sentinel command (printenv --version) with something that behaves identically across GNU/BSD/Windows, e.g. a small python -c "..." snippet that just echoes its argv, so the test only cares about flag-forwarding behavior rather than a specific external tool's flag parsing.

Environment

  • macOS (Darwin), tested via tox locally
  • Reproducible with plain pytest too, since it's just calling the system printenv
Vorherrschende Sprache
Python
Sterne
8.9k
Forks
600
Ø Merge
4 T. 23 Std.
Gemergte PRs (30 T.)
4

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 theskumar/python-dotenv

Alle Issues in theskumar/python-dotenv

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

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