No such file or directory error when installing types with mypy about mypy HOT 5 OPEN

It seemed that my previous pipeline jobs that were succeeding started failing so I look at the versions of the typing packages being installed and noticed these were updated since (working versions are below):

types-protobuf = "4.24.0.4"
types-pyopenssl = "23.3.0.0"
types-redis = "4.6.0.11"

Locking the versions to the versions listed above fixed the error. I'm not sure what the issue is with the new typing packages, but it seems either mypy is pulling in incompatible versions or the there is a bug in latest version of one of the packages.

from mypy.

@getim thanks for looking into it! While typeshed will need to be fixed, let's remove trailing slash in exists_case — seems less of a sharp edge and matches os.path.exists better. Interested in opening a PR?

from mypy.

@jakecyr thanks for your comment! it helped a lot.

waiting until this is fixed now python/typeshed#11254

from mypy.

We ran into this as well and I drilled down into mypy since yesterday:

• It looks like the logic here assumes that there's more than 1 component in the import path being resolved. However, when that's not the case just (e.g. just google), dir_chain is empty. From there runtime_path calculated here contains a trailing slash.
• Later on, this path gets used as the prefix in exists_case. The trailing slash breaks the startswith check because something like foo doesn't start with foo/. That means exists_case ends up returning True for something like site-packages//google while it doesn't exist.

I'm just laying this out here because I'm now unsure which component is wrong exactly. The runtime_path assignment can check if dir_chain is empty? Should exists_case be fixed to correctly handle the trailing slash? Both seem to fix the issue from my tests.

Edit: I guess my comment is more about the fact that mypy could handle this better, even if the linked typeshed issue gets fixed.

from mypy.

@hauntsaninja Sounds good, see here

from mypy.