-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unittest discover fails with namespace packages and builtin modules #61659
Comments
There is a problem with unittest discovering and namespace packages. Given the following folder structure, where a namespace package X lies, the following command fails with the following error: -testbug
C:\>py -3 -m unittest discover flufl
Traceback (most recent call last):
File "C:\Python33\lib\runpy.py", line 160, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "C:\Python33\lib\runpy.py", line 73, in _run_code
exec(code, run_globals)
File "C:\Python33\lib\unittest\__main__.py", line 12, in <module>
main(module=None)
File "C:\Python33\lib\unittest\main.py", line 124, in __init__
self.parseArgs(argv)
File "C:\Python33\lib\unittest\main.py", line 144, in parseArgs
self._do_discovery(argv[2:])
File "C:\Python33\lib\unittest\main.py", line 242, in _do_discovery
self.test = loader.discover(start_dir, pattern, top_level_dir)
File "C:\Python33\lib\unittest\loader.py", line 205, in discover
start_dir = os.path.abspath(os.path.dirname((the_module.__file__)))
AttributeError: 'module' object has no attribute '__file__' This happens because TestLoader.discover assumes that the given dotted package name has the attribute file, which seems to not be true in the case of namespace packages. The same error occurs when giving to |
Thanks for the report and the patch. Good catch! It will need looking over as it's not immediately obvious to me it's correct. In the code that checks the loader path, does it iterate over every member of the namespace path - even directories that aren't in the path being searched? |
Yes, it iterates over every member of the namespace path. The new attached patch fixes this behaviour, by checking that each loader path starts with top_level_dir when set_implicit_top is False (if set_implicit_top is True, top_level_dir is irrelevant, start_dir will be the package name). Also, with the original patch there were other issues:
+ if not tests:
|
Hello. Can I do something to move this issue forward? |
I'd like to review this properly before committing it. I agree it solves a real problem and your new patch looks good. |
Michael, is any chance for this to go into Python 3.4? I would love to make any changes necessary in order for this to happen. |
I left a couple of comments on rietveld. |
Attached new patch, which addresses Ezio's comments on Rietveld. |
I do want to get this into 3.4. The logic is non-trivial though, so I need to understand it before I can add it to discovery. It certainly *looks* good. |
I left a review relative to the use of the _path attribute (which shouldn't be used). |
Eric, thank you for your comment! I modified the patch to check for __path__ instead, is this a safe enough check for this use case? Since ModuleSpec isn't landed yet, I didn't use your __spec__ example. |
Sorry for any confusion, Claudiu. the_module.__path__ only indicates that the module is a package. So until you can take advantage of PEP-451, you're stuck with the _path check (or several other unappealing hack) on line 224 of unittest-17457-3.patch. However, the use of __path__ on line 226 is correct now. :) Thanks for changing that. |
Hello! Attached patch which uses ModuleSpec, tested with http://hg.python.org/features/pep-451/ repo. |
Added patch which addresses Eric's comments. It contains a situation which I'm not so happy, mostly due to not knowing in depth (or at least at a comfortable level) the import mechanics: in the AttributeError except handler, if the spec can't be determined and the module is not built-in, a TypeError is raised to notice the user that discovery can't be done for that particular package. Probably this situation (no __file__, no __spec__ and no built-in) is common, but I can't think right now at another way of solving it. |
I'm going to commit this so we get it in before the feature freeze. It sounds like the remaining issue is minor and we can resolve it in the betas. Note that if we attempt discovery from a namespace package and fail we should create a ModuleImportError test case to report the problem and *not* bomb out of test collection. |
Need doc updates |
New changeset d2e5b74e2d18 by Michael Foord in branch 'default': |
Sorry for the delay. Here's a minimal doc patch. I don't excel at writing documentation, it's not quite my strong point, so feel free to modify anything you seem fit. |
New changeset 57cb8a6e8f10 by R David Murray in branch 'default': |
Can we close this? The feature already landed in Python 3.4. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: