On Mon, 2 May 2022 at 16:23, Jia Chen via Typing-sig <typing-sig@python.org> wrote:
Hi Bernat and Paul,
Apologies for the late response. And thank you so much for bringing up this issue onto the typing-sig mailing list!
As one of the maintainers of the Pyre type checker, I agree with Eric's statement that import hooks are way too dynamic for static analyzers to handle.
Thanks. I agree - it seems self-evident to me that static checkers are unlikely to ever be able to handle import hooks. While I can't speak for Bernát, I personally never expected that - I was expecting that type checking simply wouldn't happen for editable installs (that used import hooks), and that would be fine. It may be that this isn't the case, though - to be honest, I have no visibility of how many people/projects are using import hook based editable installs, or how many of those people are inconvenienced by the current state of affairs. Ideally, we should survey the community to find out how much of a problem this really is, but I'm not sure there's a good way to do that, so we may have to rely on the traditional approach of guessing and expecting the worst ;-)
The alternative solution, i.e. emitting a static project layout where we explicitly specify how to get the source content for each and every module, would be much better for us than the dynamic import approach. But even supporting this approach would be tricky.
That's interesting to me, as I'd be disappointed if we ended up spending time implementing a solution that didn't actually help. The "static layout" proposal is more Bernát's idea, I don't really know what specifically he thinks is possible to include here. But we should certainly discuss the format of any such static layout file before making changes.
This is not impossible to do, but it also requires tons of engineering to get right, and I am skeptical on whether such engineering effort is worth it, given that the vast majority of Python users do not need to grab sources from anywhere other than the filesystem.
I would expect that any solution would restrict itself to pointing at other locations in the filesystem. For the editable install use case, I don't imagine anyone is contemplating having package sources anywhere other than in the filesystem (the whole point of an editable install, after all, is to make available the live project source, and for that to be editable it would need to be on the filesystem). I *do* imagine that outside of editable installs, people might use import hooks to load modules from non-filesystem locations. The zipimport module is an obvious example, which I understand type checkers special-case for. That seems like a reasonable "practicality beats purity" workaround, but doesn't alter the fact that people can do similar things which the type checkers *won't* have hard-coded for. As an occasional user of type checkers, I'd hope that they would degrade gracefully in that situation (treating names that can't be accessed as untyped), but that's all - as I said above, "static" is the key here. I certainly wouldn't expect them to find that source code. But maybe I'm more tolerant than other users ;-) However none of that matters for the case of editable installs, which can entirely reasonably be focused on sources in the filesystem (IMO).
I hope my explanation above could provide you with additional context on why the additional flexibilities on import resolutions is problematic for us: The more flexible&dynamic the mechanism is, the more engineering burden we will get as authors of static analyzers. In an ideal world with unlimited time&resources, this might not be an issue. But the reality is that resources are scarce for us, and we do have other priorities such as maintaining&evolving the Python type system.
Thanks, it's very helpful. I'd say none of it was a real surprise to me, and I understand exactly where you are coming from. For me, what was actually surprising was that *other* people were surprised by this limitation ;-)
My guess is that solutions with pre-existing mechanisms like `pth` files would be a path forward with least resistance for this community. Proposing some kind of static layout format that only allows filesystem imports would be a suboptimal but (barely) acceptable approach. Anything beyond that would be difficult to push for adoption.
I'd certainly hope that type checkers are aware of the implications of `.pth` files - they have been in common use for years now, not just for editable installs, but as a general mechanism for tailoring the import machinery. And indeed, the new editable install mechanism does allow tools to continue to use `.pth` files - so I don't think there's a significant change here on that front. People will still use `.pth` files, and (I imagine) would expect type checkers to be able to cope with them (or maybe they are happy with `.pth` files not being supported by type checkers - I'm not clear from your comment whether `.pth` support already exists in type checkers, or would need to be added). The trigger for this discussion is really that the new editable install mechanisms allow tools to explore *alternative* ways of delivering editable installs. Such alternatives have trade-offs and at the moment, I think it's fair to say we're still discovering what those trade-offs are. Type checkers are simply one aspect of this. From my point of view, given all that you said above, 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. A package `foo` has its metadata stored in a directory in site-packages called something like `foo-1.0.dist-info/`. We could easily add a metadata file in that directory containing information for type checkers. Maybe something as simple as a list of pathnames for additional source code files to scan? Would something like that be useful? Paul