[BUG] page modules not imported correctly

[peteasa]

Describe your context
Dash pages for example see https://dash.plotly.com/urls

build from source using dev branch to get the latest

git checkout 756562bdbb5a3b7ef48197a4f9c6bfc803fb63e6

Describe the bug
In my code
dash.page_registry[module_name]
gives me access to many useful attributes of my page including function layout() however I can not access any custom methods or classes because the page modules are not loaded properly.

sys.modules[module_name]
Does not contain my module.

Expected behavior
One simple addition to dash.py will solve this and allow me to use page modules that have been loaded

index bb8327e6..bd43df8f 100644
--- a/dash/dash.py
+++ b/dash/dash.py
@@ -2024,6 +2024,7 @@ class Dash:
                     _pages.PAGE_REGISTRY[module_name]["layout"] = getattr(
                         page_module, "layout"
                     )
+                    sys.modules[module_name] = page_module
 
     @staticmethod
     def _path_to_page(path_id):

See for example this discussion https://stackoverflow.com/questions/73060129/how-are-changes-to-sys-modules-propagated

With this fix I can then use getmembers to access my custom methods and classes
print("functions", getmembers(sys.modules[module_name], isfunction))

[ned2]

I'm inclined to agree with you @peteasa. This to me feels similar to #2263, in that they both describe different symptoms of how Dash Pages' programmatic import of page modules does exactly enough to make Dash Pages happy, but then doesn't do what a Dash developer would have expected if they had imported the page modules themselves explicitly.

I actually considered adding sys.modules[module_name] = page_module to #2271, but it didn't turn out to be necessary in order to make relative imports work. Now I'd be inclined to extend my PR to include that, as I feel like the more general issue is that Dash Page programmatic imports should behave more like explicit imports as code, both in terms of supporting relative imports, and also having appropriate entries in sys.module.

There may be a little nuance in getting both behaviours playing together (looks like my PR results in non-packages having sys.module entries prefixed with __main__, which I don't think would be expected.). So I might wait until @alexcjohnson or @ann-marie-ward weighs in before diving into anything.