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
Description
tests/test_cli.py::test_run_with_command_flagsfails when running the test suite (viatoxorpytest) on macOS.Root cause
The test runs
dotenv run printenv --versionand asserts it exits 0, to verify thatdotenv runforwards flags to the wrapped command instead of parsing them itself (added in #607 / #612).printenvis GNU coreutils' version, which supports--versionand exits 0.printenvis the BSD version, which does not support--versionat all, and exits 1 withprintenv: illegal option -- -.So the test is actually working as intended (
dotenv runcorrectly passes--versionstraight through toprintenvrather than swallowing it), but the assertion only holds on systems with GNUprintenv.Why this hasn't been caught in CI
.github/workflows/test.ymlonly runs the test matrix onubuntu-latestandwindows-latest- there's nomacos-latestjob, so this has never surfaced there.CONTRIBUTING.mdtells contributors to just runtoxorpytest, 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 smallpython -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
toxlocallypytesttoo, since it's just calling the systemprintenv