I was expecting that type checking simply wouldn't happen for editable installs.
Ah good point. I am also curious how many folks really expect editable installs to be type checked, given tht type checking already happens on the original source.
I'm not clear from your comment whether `.pth` support already exists in type checkers, or would need to be added
The support varies from type checker to type checker. According to Eric, `pyright` already supports it (https://github.com/microsoft/pylance-release/issues/2114#issuecomment-107520...). Pyre doesn't at the moment, but it should not be too difficult to add.
it would be interesting to know what a type checker might want to see from an installed package (that included some source code that's delivered by, let's say "nefarious means" :-)) to let it correctly type check the names it can't see from simply scanning the normal `sys.path` locations.
I think at the end of the day, if `sys.path` cannot include everything, then what we want to see is what other (statically-determinable) paths we need to search for imports. But if I understand correctly, the point Eric brought up earlier was less about the technical difficulty of adding more places/mechanisms to look for imports -- as long as we agree on a standardized approach, that's always doable. His real concern was about the necessity and sustainability of such a proposal: why not just include "other paths we need to search for imports" into `sys.path` directly (e.g. with `pth` files)? Would it be nice if we could always maintain the assumption that `sys.path` is all-encompassing and all we need to resolve all imports, as opposed to introducing new tweaks every now and then, which forces type checkers to play this catch-up game every time the aforementioned assumption gets broken? - Jia