On Wed, 20 Apr 2022 at 18:55, Bernat Gabor <gaborjbernat@gmail.com> wrote:
I'd like to disagree with the "dynamic import hook problem" doesn't need to be solved. I believe the reason why they are not popular today is that static check tools/IDEs don't support it well and therefore discourage users from adopting them. However, if we start adding dynamic import hooks for every editable installation for every project the need for handling them correctly would significantly increase and also comments on those issue trackers would jump up. If possible I'd like to at least explore how we can solve the dynamic import hooks. We might conclude that's not feasible or desirable. Nevertheless. then we can at least have good reasoning on what are the obstacles in achieving this are.
I agree with this position. We had the same problems with imports from zipfiles. For *years*, code was written that made unfortunate assumptions that packages would live in the filesystem, and that hindered development of things like zipapps, pyInstaller, etc. Setuptools even had an "is this package zip safe" flag, that attempted to mark what code could reliably be included in a zipfile - which doesn't actually solve the problem, just makes it easier to spot when you have an issue. Now that importlib.resources is in the stdlib, it's possible to write code that *doesn't make assumptions that packages live on the filesystem, and we can move on with some confidence. It would be a shame to lose all those benefits just because a new set of tools are appearing which make the same limiting assumptions. Also, I would point out that the fact that tools like pyright treat zipfiles like directories is exactly the same sort of special casing that tools had to do before importlib.resources was created. I'd much rather we had a solution that meant tools *didn't* have to all add that special casing, just to support one possible import hook that happens to be shipped with Python. Paul PS I should also say that I understand that in full generality this is a *hard* problem and there will need to be some compromises. One of which may well be that for harder cases, users will need to manually specify some things, or maybe even accept that tooltips/auto-completion may not work in some cases. In which case, the key will be for the tools to degrade gracefully, and we should make sure that's possible, rather than simply saying "don't do that".