Skip to content
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

Directories ending in ".py" crash nose #526

Closed
brcooley opened this issue Jul 10, 2012 · 5 comments
Closed

Directories ending in ".py" crash nose #526

brcooley opened this issue Jul 10, 2012 · 5 comments

Comments

@brcooley
Copy link

Windows 7-x64, Python 3.2.3

When running nosetests-3.2.exe in a directory that ends in ".py", nose can't find any tests, and throws an ImportError saying that it can't find a module with the name of the directory. This occurs whether there is a python file with the same name or not.

REPRO:
Create directory ending in .py
cd into directory, create test__.py file with at least one test__ function
Run nosetests-3.2.exe

EXPECTED OUTPUT:
.
----------------------------------------------------------------------
Ran 1 test in 0.001s

I've also have a full log, but the problem seems to lie in importer.py

@brcooley
Copy link
Author

This might be related to #19, I've linked it there as well

@madisona
Copy link

@brcooley try any directory with a period... I think it is the period that is truly crashing node, not necessarily ending in ".py"

Let me know if you find any workarounds... this is an unfortunate issue for me

@brcooley
Copy link
Author

@madisona I don't seem to have any issues when I use something like "dotted.dir" for my directory name, even with a file "dotted.dir.py". What seems to cause it is that nose looks for files ending in .py, and then tries to import them for test discovery. I think a simple rename as you suggest in issue 19 is the best bet for the time being.

@wiggin15
Copy link
Contributor

I looked a little bit into this.
This happens on both Windows and Unix.
It only happens on directories that end with .py - not on any directory with a dot in it.
It is not related to #19.

Apparently loader.py calls importer.py to try to load the directory as if it was a source file that contains tests.
For example, if the path to the test file is /tmp/test.py/test_a.py, then loader tries to load test.py from /tmp first, which fails.
This is traced back to the class TestAddress (initialized in loadTestsFromName in loader.py), which has an attribute named 'module'. This attribute is initialized to None for regular directory paths, but to 'test' if the given directory is '/tmp/test.py' - which causes loader.py to try to import it as a module (but of course it isn't).
Looking further, the culprit appears to be the function getpackage in util.py. This function normally receives file names and tries to parse them, and it filters out directories by checking if the names end with '.py'. Obviously when a directory ends with .py it will not filter it. This function should filter filenames that are paths to directories. I will submit a patch.

wiggin15 added a commit to Infinidat/nose that referenced this issue Feb 18, 2013
…rectories that end with .py but are not Python packages should not be parsed as if they are modules. Fixes nose-devs#526
@brcooley
Copy link
Author

Sounds good, closing in favor of #625

wiggin15 added a commit to Infinidat/nose that referenced this issue Mar 17, 2013
Directories that end with .py but are not Python packages should not be
parsed as if they are modules.
getpackage now verifies that the path is either a .py file or a package.
This fixes nose-devs#526
wiggin15 added a commit to Infinidat/nose that referenced this issue Mar 17, 2013
Directories that end with .py but are not Python packages should not be
parsed as if they are modules.
getpackage now verifies that the path is either a .py file or a package.
This fixes nose-devs#526
jszakmeister added a commit that referenced this issue Apr 7, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants