How to reexport a submodule from the root?

[rchiodo]

Suppose I had a package defined like so:

mypackage
   - __init__.py 
   childpackage
       - __init__.py
       grandchildpackage
           - foo.py

And I wanted a user to be able to do something like so:

from mypackage.grandchildpackage import Foo

Now there is a way to get this to work in the runtime (as explained here). I add the childpackage path to __path__ in the __init__.py. Like so:

__path__.append(os.path.join(os.path.dirname(__file__), "childpackage"))

But is there a way to model this behavior so that Pyright can understand it?

How do I eliminate this error:

I bring this up because of this issue in Keras:
keras-team/keras#19779

[rchiodo]

My initial though was that this would work in the mypackage/__init__.py

from .childpackage import grandchildpackage as grandchildpackage

But that only seems to work for symbols, not modules.

[rchiodo]

Oh I guess that doesn't work at runtime by itself though. It still requires the dynamic path addition.

[erictraut]

That sounds potentially feasible. It's a pattern that I've never seen used before, which explains why it was never implemented.

This would involve touching code that is not currently fresh in my memory, so I (or someone else) would need to investigate what would be involved — and whether it would break any assumptions in the current code or introduce significant performance issues with import resolution.

[heejaechang]

Such heuristics would be incredibly hacky and difficult to debug when they fail. In the past, we've always said that we don't support dynamic manipulation of path, and that's the stance I'd like to maintain.

we might not support every possible ways but like __all__, we could handle a few specific case or pattern? then we can tell package maintainer that if you use this pattern, pyright will understand it and will work at runtime as well. not ideal but still a compromise?

[erictraut]

I don't think we should entertain supporting dynamic manipulation of __paths__. Please don't pursue that Heejae.

[erictraut]

In the case of __all__, we eventually got to the point where we standardized a limited subset of forms that all tools can and should support. I don't think we should attempt a similar standardization effort for dynamic __paths__ manipulation. Other tools like mypy likewise do not handle this, and for good reason.