gh-80958: Restore unittest discovery support for namespace packages as start directory #123820

jacobtylerwalls · 2024-09-07T18:30:19Z

Restore unittest discovery support for PEP 420 namespace packages as start directory (-s).

Rationale

There are two flavors of failures related to unittest discovery of namespace packages:

not specified explicitly (user error): fails silently unittest does not discover tests in PEP420 packages #90022
specified explicitly: fails with cryptic error: unittest discover throws TypeError on namespace packages #80958

The silent failure ticket was marked as a duplicate of #68070, which was closed by a commit that removed support for namespace package discovery, but that solved neither issue. We still have a silent failure for user error (which I suppose is fine) and we still have a cryptic failure if a user attempts to provide it specifically (which is now user error according to the 3.11 revert).

We should do better than the cryptic error. But in looking into it, it seems a shame to give up so quickly when all the patch for #80958 needed to do was to cope with __name__ being None and __loader__ being set.

Notes

Re: the comment about this code being too hard to maintain: I think this regressed because of the heavy use of mocking in test_discovery.py. With real types this would have been caught by the existing test.

Issue: unittest discover throws TypeError on namespace packages #80958

📚 Documentation preview 📚: https://cpython-previews--123820.org.readthedocs.build/

…thonGH-29745)" This reverts commit 0b2b9d2.

picnixz · 2024-09-07T18:50:08Z

@ericvsmith, you said in #68070 (comment):

As the author of PEP-420, I think having test discovery support namespace packages is a mistake, at least in the sense of pretending every directory is a namespace package.

Had your stance changed since then? do we revert it and make it work? or should we just only focus on improving the error message?

jacobtylerwalls · 2024-09-07T18:58:19Z

I'm eager to hear Eric's view also. I'll just note that when the directory is provided explicitly as described in #80958, that strikes me as importantly distinct from an apporach that assumes every directory is/could be a namespace package.

The revert (and subsequent fix) here only solves the explicit discovery issue, not the implicit discovery issue which is still a silent user error either way.

Doc/library/unittest.rst

Doc/whatsnew/3.11.rst

…e packages Improve discovery

methane

start_dir can be namespace package. But it must not affect how treat subdirs.

Lib/unittest/loader.py

methane · 2024-09-08T16:44:03Z

Would you add a test case?

$ find foo
foo
foo/noop
foo/noop/test_noop.py
foo/noop/no2
foo/noop/no2/__init__.py
foo/noop/no2/test_no2.py
foo/test_foo.py
foo/bar
foo/bar/__init__.py
foo/bar/test_bar.py

when unittest discover foo is executed, only test_foo and test_bar are discovered.

jacobtylerwalls · 2024-10-23T03:19:40Z

Doc/library/unittest.rst

+   To avoid scanning directories unrelated to Python,
+   tests are not searched in subdirectories that do not contain ``__init__.py``.


Thanks, this is great 👍

… start directory (python#123820)

jacobtylerwalls added 2 commits September 7, 2024 13:19

Revert "bpo-23882: unittest: Drop PEP 420 support from discovery. (py…

7315af0

…thonGH-29745)" This reverts commit 0b2b9d2.

pythongh-80958: Restore unittest discovery of PEP 420 namespace packages

8344889

bedevere-app bot added the awaiting review label Sep 7, 2024

jacobtylerwalls mentioned this pull request Sep 7, 2024

unittest discover throws TypeError on namespace packages #80958

Closed

Attempt to address WASI failure

525c5bc