gh-93096: fix test_mimetypes.test_guess_type_conflicting_with_mimetypes
#131408
Conversation
Using `run_python_until_end()` ignores `setUpModule()`. In particular, mocking `mimetypes.knownfiles` has no effect for the CLI tests and leads to issues on platforms defining non-standard MIME types such as macOS or openSUSE.
|
!buildbot macOS |
|
🤖 New build scheduled with the buildbot fleet by @picnixz for commit 62863a0 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131408%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
|
!buildbot macOS |
|
🤖 New build scheduled with the buildbot fleet by @picnixz for commit 7be23f0 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F131408%2Fmerge The command will test the builders whose names match following regular expression: The builders matched are:
|
Lib/mimetypes.py
Outdated
| print(f"error: unknown type {gtype}", file=sys.stderr) | ||
| sys.exit(1) |
There was a problem hiding this comment.
The problem is that sys.exit(msg) raises SystemExit but with its code attribute being the message and not some integer. OTOH, if the parser fails to parse something, it prints on stderr and then uses sys.exit(2). So I would need to handle an integer code coming from a parser error, or a string code coming from there (in which case I would also need to define the error code to be 1 explicitly):
with redirect(...):
try:
main()
except SystemExit as exc:
if isinstance(exc.code, int):
retcodce = exc.code
errmsg = ... # not even sure it's intercepted by the redirection btw
else:
retcode = 1
errmsg = exc.codeAnd then the stream redirections become half-useless.
There was a problem hiding this comment.
These both print to stderr with exit code 1 when running something like ./python.exe -m mimetypes --extension thing:
sys.exit(f"error: unknown type {gtype}")print(f"error: unknown type {gtype}", file=sys.stderr)
sys.exit(1)Let's keep the original.
There was a problem hiding this comment.
sys.exit(f"error: unknown type {gtype}")
Yes, from a CLI perspective, but here we're invoking the main() function directly (we're not using subprocess). The reason we can't use subprocess is because we need to mock the module but with subprocess, the module gets re-imported normally and mocks are lost (or am I missing something obvious?)
There was a problem hiding this comment.
Ah, it was me missing something, you were referring to the tests :)
In that case, I suggest we step back, and refactor to make it easier to test, rather than worrying about specific return code values and stdout/stderr.
Here's a refactor to make it similar to random/test_random, based on https://pythontest.com/testing-argparse-apps/:
This splits out testing of parsing, and CLI output into successful and error cases.
Using
run_python_until_end()ignoressetUpModule(). In particular, mockingmimetypes.knownfileshas no effect for the CLI tests and leads to issues on platforms defining non-standard MIME types such as macOS or openSUSE.I think this was overlooked in #93097 and this may be the reason why finding the correct extension was tedious. Now, all platforms should support the test correctly (previously, the macOS files were still looked up as
mimetypes.knownfileswas not unset for CLI tests).