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

Comments

Projects
None yet
3 participants
@brcooley

brcooley commented Jul 10, 2012

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

This comment has been minimized.

brcooley commented Jul 10, 2012

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

@madisona

This comment has been minimized.

madisona commented Jul 12, 2012

@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

This comment has been minimized.

brcooley commented Jul 12, 2012

@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

This comment has been minimized.

Contributor

wiggin15 commented Feb 18, 2013

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

Ignore directories that are not packages in getpackage in util.py. Di…
…rectories that end with .py but are not Python packages should not be parsed as if they are modules. Fixes nose-devs#526
@brcooley

This comment has been minimized.

brcooley commented Feb 19, 2013

Sounds good, closing in favor of #625

@brcooley brcooley closed this Feb 19, 2013

wiggin15 added a commit to Infinidat/nose that referenced this issue Mar 17, 2013

getpackage in util.py should only parse files and packages
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

getpackage in util.py should only parse files and packages
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