case sensitive file path comparison in Importer.sameModule() can cause modules to be loaded twice on Windows

[GoogleCodeExporter]

What steps will reproduce the problem?

1. create a new virtualenv on Windows.  MAKE SURE there is an uppercase letter 
in the path.
2. checkout this package: https://bitbucket.org/rsyring/nose-import-bug-example
3. Activiate venv
4. python setup.py develop
5. cd bwimpt
6. nosetests -s tests/test_import.py 

On Linux, you will see something like the following:

id from app 31207560
from test 31207560
id from app 31207560

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK

On Windows, you will see that the app ids are not the same and will get an 
assertion error.

What version of the product are you using? On what operating system?

Versions: both 0.11.4 and tip as of 11/22/10
OS: Linux & Windows, but the problem only shows up on Windows

Please provide any additional information below.

If you use a fix for issue #293 and use the --first-package-wins option, this 
bug disappears.

I believe I have tracked the problem down to the code in importer.py that 
replaces modules.  It uses Importer.sameModule() which is using a comparison of 
file paths that is case sensitive.

My fix is here: https://bitbucket.org/rsyring/blaze-nose/changeset/703767dd9288

FWIW, IMO, this is a pretty significant bug.  The result in my application 
during testing was that 'import foo.bar' would fail with the message that 
module foo did not have an attribute bar.  But we knew the paths were correct 
b/c the same code worked in production and during testing when using Linux 
systems.  Whats worse was that it just didn't make sense...it took us several 
days to finally minimalize the test case enough to figure out it was a bug in 
Nose.

Thanks for your work on this project, I have really gotten into unit & 
functional testing since I came into contact with nose and have appreciated its 
flexibility and utility.

Original issue reported on code.google.com by rsyr...@gmail.com on 23 Nov 2010 at 6:53

[GoogleCodeExporter]

A little more explanation here: 
http://groups.google.com/group/nose-users/browse_thread/thread/47f1593643754940

Original comment by rsyr...@gmail.com on 23 Nov 2010 at 6:41

[GoogleCodeExporter]

Well, it seems my "fix" has broken directory based test discovery...I am 
looking into that now.

Original comment by rsyr...@gmail.com on 23 Nov 2010 at 7:56

[GoogleCodeExporter]

ok, sorry I can't be more help at this point, but I am lost.  If you use a fix 
for issue #293 and use the --first-package-wins option, on windows, directory 
based discovery of tests stops working.  Same if you try the fix I provided, 
directory based discovery of tests no longer works.

Using --first-package-wins option on linux doesn't seem to break test discovery.

so, this doesn't work:

cd mymodule
nosetests

using module based discovery works fine:

nosetests mymodule

Original comment by rsyr...@gmail.com on 23 Nov 2010 at 9:55

[GoogleCodeExporter]

Just wondering if I can encourage some movement on this bug.  It makes Windows 
testing annoying when doing things manually, but is now causing some further 
grief with multi-platform configurations w/ Jenkins.

Thanks.

Original comment by rsyr...@gmail.com on 17 Jun 2011 at 6:43

[GoogleCodeExporter]

btw I integrated the fix for Issue 293

As for this one, if you can turn the test suite above into an automated test 
and submit a patch then it would speed things along.  Details are in 
DEVELOPERS.txt

Original comment by kumar.mcmillan on 17 Jun 2011 at 7:45