Open edreamleo opened 2 years ago
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 -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 https://github.com/python/mypy/pull/11909 was merged :)
@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 :-)
I got curious about hash
and found this helpful: https://unix.stackexchange.com/questions/86012/what-is-the-purpose-of-the-hash-command (man hash
didn'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.
(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.
a lot of tests are failing for me on Windows
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.
@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.
@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 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.
@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.
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.
@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 Good catch. This was an issue in another context. Oh yes, now I remember: pylint issue #6476.
@AlexWaygood Linux-oriented devs sometimes don't remember how insensitive Windows is to file case.
@AlexWaygood Not that remembering makes dealing with filenames any easier!
@AlexWaygood I think I see what is going on.
Outside of mypy
C:\Repos\leo-editor>C:\Python\Python3.10\python.exe
Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for z in sys.path: print(z)
...
C:\Python\Python3.10\python310.zip
C:\Python\Python3.10\DLLs
C:\Python\Python3.10\lib
C:\Python\Python3.10
C:\Python\Python3.10\lib\site-packages
c:\repos\ekr-pylint
C:\Python\Python3.10\lib\site-packages\win32
C:\Python\Python3.10\lib\site-packages\win32\lib
C:\Python\Python3.10\lib\site-packages\Pythonwin
>>> ^Z
All looks good, except for ekr-pylint, a clone of the pylint repo.
Sheesh. Now I remember: C:\Python\Python3.10\Lib\site-packages\easy-install.pth contains:
c:\repos\ekr-pylint
So pylint's unit tests will be hosed if they depend on the case of "c:". This is, I'm pretty sure, a pylint install problem, though naturally the pylint devs weren't aware of easy-install.pth!
Inside mypy
c:\Repos\mypy>activate
(venv) c:\Repos\mypy>python
Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for z in sys.path: print(z)
...
C:\Python\Python3.10\python310.zip
C:\Python\Python3.10\DLLs
C:\Python\Python3.10\lib
C:\Python\Python3.10
c:\Repos\mypy\venv
c:\Repos\mypy\venv\lib\site-packages
c:\repos\mypy
>>>
Oops.
And lookie here: C:\Repos\mypy\venv\Lib\site-packages\easy-install.pth
contains:
c:\repos\mypy
So once again the culprit is an easy-install.pth file that none of us knows about :-)
BTW, the free version of FileLocator Pro is the only way to search on Windows. It's about 100 times faster than searching with the default Windows tools.
So once again the culprit is an easy-install.pth file that none of us knows about :-)
Okay, but I'm confused: do you think the fix need to happen on mypy's end, your end, or whoever/whatever created that .pth
file?
@AlexWaygood I'm confused too. I'm sure that I didn't do anything to the .pth
file, but perhaps changing that file (on my end) is a temporary workaround.
Imo, venv is not likely the culprit because the pylint problems did not (apparently) depend on venv. So my guess is that there is a problem with setuptools, or whatever pip depends on.
In any case, making mypy unit tests robust against the case of filenames (Windows only) might be something worth considering. But such changes would likely be ugly.
@AlexWaygood On second thought, it's likely that some part of the python standard library is creating the .pth
file. So one could argue that the contents of .pth
files simply can not change, because the standard library can't change.
This question might be worth discussing with Guido or other python guru, but for now I'm afraid that mypy (and pylint) might be stuck with .pth
files as they are.
@AlexWaygood However, I'm going to change the case of my local .pth
file and see what happens. I'll let you know.
@AlexWaygood On second thought, it's likely that some part of the python standard library is creating the
.pth
file. So one could argue that the contents of.pth
files simply can not change, because the standard library can't change.
I'm fairly sure the standard library wouldn't create an easy-install.pth
file. Most likely it's setuptools.
Not much joy: 18 failed, 10081 passed, 380 skipped, 10 xfailed
I changed mypy\venv\site-packages\easy-install.py
as follows:
### EKR: Change case from c: to C:
### c:\repos\mypy
C:\repos\mypy
The results were different, but still the tests fail. But wait a minute. There's probably not a big reason to show the failures, because sys.path still contains lower-case drive letters:
(venv) c:\Repos\mypy>python
Python 3.10.4 (tags/v3.10.4:9d38120, Mar 23 2022, 23:13:41) [MSC v.1929 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> for z in sys.path: print(z)
...
C:\Python\Python3.10\python310.zip
C:\Python\Python3.10\DLLs
C:\Python\Python3.10\lib
C:\Python\Python3.10
c:\Repos\mypy\venv
c:\Repos\mypy\venv\lib\site-packages
C:\repos\mypy
>>>
Ouch!
@AlexWaygood Oh, what the heck. Here are the new failures. Note --cache-clear.
I'm sorry, I have no idea why your paths start with a lowercase "c" :)
This has never happened to me, though, so I doubt mypy, the Windows operating system, or the stdlib are the direct cause of this.
The mypyc errors, on the other hand, I can reproduce on my Windows machine, so we should probably fix those.
@JelleZijlstra Hmm. No, setuptools isn't part of the standard library. But does that help?
Sheesh again. Hacking the contents of the .pth
file seem even uglier! This seems like one of those problems for which no good solution exists. Let's hope I'm wrong.
@AlexWaygood I'm stumped. I can well believe that something on my end is to blame. But what could it be?
@AlexWaygood @JelleZijlstra @pranavrajpal @hauntsaninja
Thanks for all your sympathetic help. I feel confident that a) something is weird on my end and, b) that I can ignore the weirdness for now.
@AlexWaygood Wow. It looks like the lower-case drive letter comes from cd statements in .cmd files! After changing the case only the expected failures remain (I think):
10 failed, 10089 passed, 380 skipped, 10 xfailed
I'm shaking my head in disbelief.
@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.
@JelleZijlstra Thanks! That's a great tip. I'll try to remember it, or at least remember that <details>
can be made to work :-)
Huh, I'm intrigued about why your file paths start with a lowercase
c
rather than an uppercaseC
:)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 ==========================================
@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.
I suppose this would work if we called os.path.normcase on the path names when printing file names and testing them?
@hauntsaninja Thanks for the improved docs. They look spot on to me: clear, helpful, concise.
Glad to hear it! But you have Alex to thank :-)
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.
Documentation
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 thesource
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) andwhere 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 ofpip hash
, such aspip hash -r
andpip hash -r .
do not work.Any help would be appreciated. Thanks.