You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Issue with lower case drive names when running tests on Windows #12880
I am attempting to run unit tests as preparation to submitting a PR. There are other problems on Linux, but this issue applies to Windows.
The setup instructions in CONTRIBUTING.md do not work on Windows. Presumably as a result, a large number of unit tests fail. The following instructions would seem to need modification:
1: source venv/bin/activate
Googling probably provides the workaround: define activate.cmd as venv\Scripts\activate, and similarly for deactivate. Ah. Just now I see just now that the venv docs discuss the source command.
hash -r
I have no idea what this means. Googling does not help and "hash" does not appear in venv.html. After:
which hash (Linux) and where hash (Windows) yield nothing (either before and after activate).
Some file searching finds ...mypy\venv\Lib\site-packages\pip\_internal\commands\hash.py, but various invocations of pip hash, such as pip hash -r and pip hash -r . do not work.
I work from the Windows command line, so I usually use "venv/scripts/activate.bat" to activate the virtual environment.
I also spent a while googling the hash -r thing when I first started contributing. I still don't know what it means, and have never succeeded in getting any equivalent command to work on my machine, but it doesn't seem to have affected anything :)
Several mypyc tests fail on my machine. I think maybe a few daemon tests do too -- can't remember. I've never worked on either of those areas, so it's never bothered me too much! (Somebody should probably fix that at some point, though.) If you scroll to the bottom of this page here, there's a README with some advice for running specific parts of the test suite, which is useful (it takes forever to run the whole thing, anyway): https://github.com/python/mypy/tree/master/test-data/unit
The self-type-check also used to fail on Windows before my PR #11909 was merged :)
I'm kinda sorry that you have been able to skip hash -r, because a lot of tests are failing for me on Windows. I suspect that venv isn't insulating the tests from my idiosyncratic environment.
I'll definitely try running just a few tests. And maybe just one test, to dig deeper into why it is failing.
Basically, it clears the shell's internal cache that maps commands to their locations on the search path. I suppose it's there because activating a venv puts new things on the path. If your Windows terminal doesn't have an equivalent cache, there's no need to run the command.
(I'm responsible for this terrible Windows unfriendly documentation) Yes, hash is a shell builtin. It's not there because of the venv activate — venv activate actually calls hash -r itself. It's there because of new console scripts added as part of pip install:
# before pip install, these executables point to some other mypy installation i have
(mypy-wwwl) ~/dev/mypy master λ which mypy
/Users/shantanu/.local/bin/mypy
(mypy-wwwl) ~/dev/mypy master λ which stubtest
/Users/shantanu/.local/bin/stubtest
(mypy-wwwl) ~/dev/mypy master λ pip install -e .
...
# after pip install, these executables still point to some other mypy installation i have
(mypy-wwwl) ~/dev/mypy master λ which mypy
/Users/shantanu/.local/bin/mypy
(mypy-wwwl) ~/dev/mypy master λ which stubtest
/Users/shantanu/.local/bin/stubtest
# rehashing gets things to point to the mypy i just installed editably
(mypy-wwwl) ~/dev/mypy master λ hash -r
(mypy-wwwl) ~/dev/mypy master λ which mypy
/Users/shantanu/.virtualenvs/mypy-wwwl/bin/mypy
(mypy-wwwl) ~/dev/mypy master λ which stubtest
/Users/shantanu/.virtualenvs/mypy-wwwl/bin/stubtest
Would gladly welcome improvements that make things friendly for Windows contributors.
Regarding running the tests: we're also very happy for you to open a draft PR and rely on CI to run tests.
Maybe you could try pasting the output of pytest here? I'm on Windows too and I'm only getting 11 failing mypyc tests, so it should be possible to fix those tests, and someone here might have some insights for the causes.
You could also just use CI to run the tests, especially if they're unrelated to what you're working on, but I'm guessing that's less convenient than running tests locally while developing.
@hauntsaninja :-) It's a pleasure to be part of this community. Writing install documentation is supremely difficult. Saying everything necessary and nothing more is impossible, because readers have different levels of experience. Leo's install docs are far from exemplary.
I'm an interesting combination of experienced dev and newbie as far as venv and linux goes: I haven't (yet) learned what not to do. So I might be an ideal tester for mypy's unit tests. I'm happy to help find glitches in the unit testing process. That might be more important than my PR :-)
You said, "we're also very happy for you to open a draft PR and rely on CI to run tests." What do you mean by CI?
@pranavrajpal Many of the failing tests contain lines like:
E: File "driver.py", line 6, in <module>... A: File "C:\Users\Dev\AppData\Local\Temp\mypy-test-7uzg03ih\tmp\driver.py...
I'm wondering whether the tests should be generalized. Or perhaps my installation is missing an environment var. In that case, venv would seem not to be doing a complete job. What do you think?
@AlexWaygood One last test. I completely reinstalled mypy and reran the tests with pytest:
10 failed, 10096 passed, 380 skipped, 9 xfailed
Not quite the same as before, but close enough.
Finally, C:\Repos\mypy\venv\Lib\site-packages\easy-install.pth still contains "c:" rather than "C:". I don't think mypy needs to be concerned with this weirdness. I'm just including this report for completeness's sake.
@edreamleo I took the liberty to add details tags to collapse your long outputs. The key is put enough blank lines around the opening and closing tags.
Huh, I'm intrigued about why your file paths start with a lowercase c rather than an uppercase C :)
It looks like that's the cause for a lot of the errors.
I think I've managed to come up with a simplified reproduction for that by just using a lowercase drive name in the path passed to pytest. Running pytest e:\Pranav\Github\mypy/mypy/test/testfinegrained.py -n 0 -k testFixingBlockingErrorBringsInAnotherModuleWithBlocker for me gives:
================================================= test session starts =================================================
platform win32 -- Python 3.9.6, pytest-7.1.2, pluggy-1.0.0
rootdir: e:\Pranav\Github\mypy, configfile: pytest.ini
plugins: cov-2.12.1, forked-1.4.0, xdist-2.5.0
collected 668 items / 667 deselected / 1 selected
mypy\test\testfinegrained.py F [100%]
====================================================== FAILURES =======================================================
_______________________________ testFixingBlockingErrorBringsInAnotherModuleWithBlocker _______________________________
data: E:\Pranav\Github\mypy\test-data\unit\fine-grained-blockers.test:474:
e:\pranav\github\mypy\win_venv\lib\site-packages\pluggy\_hooks.py:265: in __call__
return self._hookexec(self.name, self.get_hookimpls(), kwargs, firstresult)
e:\pranav\github\mypy\win_venv\lib\site-packages\pluggy\_manager.py:80: in _hookexec
return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
e:\pranav\github\mypy\win_venv\lib\site-packages\_pytest\runner.py:174: in pytest_runtest_call
raise e
e:\pranav\github\mypy\win_venv\lib\site-packages\_pytest\runner.py:166: in pytest_runtest_call
item.runtest()
E:\Pranav\Github\mypy\mypy\test\data.py:270: in runtest
suite.run_case(self)
E:\Pranav\Github\mypy\mypy\test\testfinegrained.py:133: in run_case
assert_string_arrays_equal(
E AssertionError: Invalid output (E:\Pranav\Github\mypy\test-data\unit\fine-grained-blockers.test, line 474)
------------------------------------------------ Captured stderr call -------------------------------------------------
Expected:
==
a.py:1: error: invalid syntax
==
E:/Pranav/Github/mypy/test-data/unit/lib-stub/blocker.pyi:2: error: invalid syntax (diff)
==
a.py:2: error: "int" not callable
Actual:
==
a.py:1: error: invalid syntax
==
e:/Pranav/Github/mypy/test-data/unit/lib-stub/blocker.pyi:2: error: invalid syntax (diff)
==
a.py:2: error: "int" not callable
Alignment of first line difference:
E: E:/Pranav/Github/mypy/test-data/unit/lib-stub/blocker.pyi:2: error: inva...
A: e:/Pranav/Github/mypy/test-data/unit/lib-stub/blocker.pyi:2: error: inva...
^
=============================================== short test summary info ===============================================
FAILED mypy/test/testfinegrained.py::FineGrainedSuite::fine-grained-blockers.test::testFixingBlockingErrorBringsInAnotherModuleWithBlocker
========================================== 1 failed, 667 deselected in 0.77s ==========================================
changed the title [-]Help please! source and hash do not exist on Windows[/-][+]Issue with lower case drive names when running tests on Windows[/+]on Jun 4, 2022
Retitling this issue to reflect the remaining thing that needs improving here (as I understand it). Ethan's suggestion of os.path.normcase seems like it would be a simple fix, would be great if someone was interested in shipping it!
It might be easier to attract contributors to work on the remaining issue if we closed this issue and created a new one that was specific to the lower case issue. This way contributors wouldn't need to read through the long discussion above.
Activity
AlexWaygood commentedon May 27, 2022
Hi! I'm a mypy contributor on Windows.
I work from the Windows command line, so I usually use
"venv/scripts/activate.bat"to activate the virtual environment.I also spent a while googling the
hash -rthing when I first started contributing. I still don't know what it means, and have never succeeded in getting any equivalent command to work on my machine, but it doesn't seem to have affected anything :)Several mypyc tests fail on my machine. I think maybe a few daemon tests do too -- can't remember. I've never worked on either of those areas, so it's never bothered me too much! (Somebody should probably fix that at some point, though.) If you scroll to the bottom of this page here, there's a README with some advice for running specific parts of the test suite, which is useful (it takes forever to run the whole thing, anyway): https://github.com/python/mypy/tree/master/test-data/unit
The self-type-check also used to fail on Windows before my PR #11909 was merged :)
edreamleo commentedon May 27, 2022
@AlexWaygood Hi Alex. Thanks for your comments!
I'm kinda sorry that you have been able to skip
hash -r, because a lot of tests are failing for me on Windows. I suspect that venv isn't insulating the tests from my idiosyncratic environment.I'll definitely try running just a few tests. And maybe just one test, to dig deeper into why it is failing.
Thanks again. You've given me some hope :-)
JelleZijlstra commentedon May 27, 2022
I got curious about
hashand found this helpful: https://unix.stackexchange.com/questions/86012/what-is-the-purpose-of-the-hash-command (man hashdidn't give me anything useful on either Ubuntu or macOS.)Basically, it clears the shell's internal cache that maps commands to their locations on the search path. I suppose it's there because activating a venv puts new things on the path. If your Windows terminal doesn't have an equivalent cache, there's no need to run the command.
hauntsaninja commentedon May 27, 2022
(I'm responsible for this terrible Windows unfriendly documentation) Yes, hash is a shell builtin. It's not there because of the venv activate — venv activate actually calls
hash -ritself. It's there because of new console scripts added as part ofpip install:Would gladly welcome improvements that make things friendly for Windows contributors.
Regarding running the tests: we're also very happy for you to open a draft PR and rely on CI to run tests.
pranavrajpal commentedon May 28, 2022
Maybe you could try pasting the output of
pytesthere? I'm on Windows too and I'm only getting 11 failing mypyc tests, so it should be possible to fix those tests, and someone here might have some insights for the causes.You could also just use CI to run the tests, especially if they're unrelated to what you're working on, but I'm guessing that's less convenient than running tests locally while developing.
edreamleo commentedon May 28, 2022
@JelleZijlstra Thanks for the info about
hash -r! My guess is that there is no need to run anything like it with Windows Console, which is what I use.edreamleo commentedon May 28, 2022
@hauntsaninja :-) It's a pleasure to be part of this community. Writing install documentation is supremely difficult. Saying everything necessary and nothing more is impossible, because readers have different levels of experience. Leo's install docs are far from exemplary.
I'm an interesting combination of experienced dev and newbie as far as venv and linux goes: I haven't (yet) learned what not to do. So I might be an ideal tester for mypy's unit tests. I'm happy to help find glitches in the unit testing process. That might be more important than my PR :-)
You said, "we're also very happy for you to open a draft PR and rely on CI to run tests." What do you mean by CI?
edreamleo commentedon May 28, 2022
@pranavrajpal Will do, later today. Oh, I think I see. CI means Continuous Integration, right? In other words, don't sweat the tests.
However, I'd like to drive my development with some new tests, so I'm eager to come up to speed on testing.
edreamleo commentedon May 28, 2022
@pranavrajpal Here are the results of running unit tests with pytest:
18 failed, 10081 passed, 380 skipped, 10 xfailed in 441.05s (0:07:21)If these failures look reasonable to you I won't worry about them!
Note: I'd use
<details>, but it makes a mess of the output.Details
AlexWaygood commentedon May 28, 2022
Huh, I'm intrigued about why your file paths start with a lowercase
crather than an uppercaseC:)It looks like that's the cause for a lot of the errors.
edreamleo commentedon May 28, 2022
@pranavrajpal Many of the failing tests contain lines like:
I'm wondering whether the tests should be generalized. Or perhaps my installation is missing an environment var. In that case, venv would seem not to be doing a complete job. What do you think?
edreamleo commentedon May 28, 2022
@AlexWaygood Good catch. This was an issue in another context. Oh yes, now I remember: pylint issue #6476.
edreamleo commentedon May 28, 2022
@AlexWaygood Linux-oriented devs sometimes don't remember how insensitive Windows is to file case.
edreamleo commentedon May 28, 2022
@AlexWaygood Not that remembering makes dealing with filenames any easier!
13 remaining items
edreamleo commentedon May 28, 2022
@AlexWaygood One last test. I completely reinstalled mypy and reran the tests with pytest:
10 failed, 10096 passed, 380 skipped, 9 xfailedNot quite the same as before, but close enough.
Finally, C:\Repos\mypy\venv\Lib\site-packages\easy-install.pth still contains "c:" rather than "C:". I don't think mypy needs to be concerned with this weirdness. I'm just including this report for completeness's sake.
JelleZijlstra commentedon May 28, 2022
@edreamleo I took the liberty to add details tags to collapse your long outputs. The key is put enough blank lines around the opening and closing tags.
edreamleo commentedon May 28, 2022
@JelleZijlstra Thanks! That's a great tip. I'll try to remember it, or at least remember that
<details>can be made to work :-)pranavrajpal commentedon May 29, 2022
I think I've managed to come up with a simplified reproduction for that by just using a lowercase drive name in the path passed to pytest. Running
pytest e:\Pranav\Github\mypy/mypy/test/testfinegrained.py -n 0 -k testFixingBlockingErrorBringsInAnotherModuleWithBlockerfor me gives:edreamleo commentedon May 29, 2022
@pranavrajpal Thanks for pursuing the drive-case letters mystery.
Our joint(?) conclusion: don't use lower-case drive names anywhere, including anywhere in .cmd files or in arguments to commands.
emmatyping commentedon May 29, 2022
I suppose this would work if we called os.path.normcase on the path names when printing file names and testing them?
edreamleo commentedon May 30, 2022
@hauntsaninja Thanks for the improved docs. They look spot on to me: clear, helpful, concise.
hauntsaninja commentedon May 30, 2022
Glad to hear it! But you have Alex to thank :-)
[-]Help please! source and hash do not exist on Windows[/-][+]Issue with lower case drive names when running tests on Windows[/+]hauntsaninja commentedon Jun 4, 2022
Retitling this issue to reflect the remaining thing that needs improving here (as I understand it). Ethan's suggestion of os.path.normcase seems like it would be a simple fix, would be great if someone was interested in shipping it!
JukkaL commentedon Apr 25, 2023
It might be easier to attract contributors to work on the remaining issue if we closed this issue and created a new one that was specific to the lower case issue. This way contributors wouldn't need to read through the long discussion above.
hauntsaninja commentedon Dec 15, 2025
Closing as per above and #18590