module has no attribute 'load'

[HaraldTR]

Trying to run uvicorn_hmr programmatically, but getting issues. On newest FastAPI / Starlette / uvicorn.

# __main__.py
from pathlib import Path
import sys
import uvicorn_hmr

if __name__ == "__main__":
    app_path = 'src.server:app'  
    cwd = Path.cwd()
    
    if str(cwd) not in sys.path:
        sys.path.insert(0, str(cwd))

    uvicorn_hmr.main(
        slug=app_path,
        host="0.0.0.0",
        port=8000,
        log_level="debug",
        reload_include=str(cwd / "src"),
        reload=False
    )

Traceback (most recent call last):
  File "/venv/lib/python3.12/site-packages/uvicorn_hmr.py", line 91, in run_entry_file
    self.entry_module.load()
AttributeError: module 'src.server' has no attribute 'load'

[HaraldTR]

reload=True also gives me an error bc

runtime_js = Path(__file__, "../runtime.js").read_text()

has one to many . and does not resolve.

[CNSeniorious000]

Thank for reporting! I am looking into it.

[HaraldTR]

Thank for reporting! I am looking into it.

Awesome 🏎️💨 Also, any thoughts about how hard it would be to implement for Celery? HMR would be suuuper powerful for fast celery reloads too.

In general I think this package can do very well. I currently run a very large FastAPI project, and I have to do a lot of work to enable lazy imports to decrease startup times / reload times. With some of my libraries (data science stuff on the backend), this can take 45+ seconds without lazy imports, which is absolutely intolerable of course. I am surprised something like this has not shown up earlier.

[HaraldTR]

It looks like your reactive code is also using py3.14 generics syntax. Might it be a python version issue?

[CNSeniorious000]

Did you import the src.server module before calling uvicorn_hmr.main() in __main__.py? If so, I can reproduce this issue.

The problem arises because hmr registers a new module loader to the import mechanism, making the module dependency graph visible. However, if src.server is imported first, it gets cached in sys.modules as a normal module, which uvicorn-hmr then uses.

To fix this, try adding the following code before importing src.server:

from reactivity.hmr.core import patch_meta_path
patch_meta_path("./src/server")  # or "./src" or "."

If you prefer not to modify your existing code, you'll need to reload src.server and all its dependencies, as dependency information cannot be inferred from already-imported modules.

[CNSeniorious000]

It looks like your reactive code is also using py3.14 generics syntax. Might it be a python version issue?

Nope, these packages are compatible and tested with python>=3.12

[CNSeniorious000]

implement for Celery

Won't be hard, I think. Every integration only needs to override the run_entry_file method of a Reloader class (sorry for such a bad name😂), like the one I implemented for uvicorn:

hmr/packages/uvicorn-hmr/uvicorn_hmr.py

Lines 83 to 92 in 13787c3

	@override
	def run_entry_file(self):
	stop_server()
	with self.error_filter:
	self.entry_module.load()
	app = getattr(self.entry_module, attr)
	start_server(app)

However, I haven't learned Celery yet, so the implementation might be delayed. Contributions are welcome! If you're unsure about how hmr works internally, I'm happy to explain.

---

Personally I have some heavy FastAPI servers too, which is my motivation to implement this ecosystem.

I am surprised something like this has not shown up earlier.

So do I. HMR has accelerated JavaScript development for nearly a decade, yet I haven’t seen a similar tool in Python until now.

[HaraldTR]

Did you import the src.server module before calling uvicorn_hmr.main() in __main__.py? If so, I can reproduce this issue.

The problem arises because hmr registers a new module loader to the import mechanism, making the module dependency graph visible. However, if src.server is imported first, it gets cached in sys.modules as a normal module, which uvicorn-hmr then uses.

To fix this, try adding the following code before importing src.server:

from reactivity.hmr.core import patch_meta_path
patch_meta_path("./src/server") # or "./src" or "."
If you prefer not to modify your existing code, you'll need to reload src.server and all its dependencies, as dependency information cannot be inferred from already-imported modules.

Yes! Thats it.

I still get an error though:

Traceback (most recent call last):
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 215, in <genexpr>
    return any(not isinstance(s, BaseDerived) or _pulled(s) for s in sub.subscribers)
                                                  ^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 215, in _pulled
    return any(not isinstance(s, BaseDerived) or _pulled(s) for s in sub.subscribers)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 215, in <genexpr>
    return any(not isinstance(s, BaseDerived) or _pulled(s) for s in sub.subscribers)
                                                  ^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 215, in _pulled
    return any(not isinstance(s, BaseDerived) or _pulled(s) for s in sub.subscribers)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 215, in <genexpr>
    return any(not isinstance(s, BaseDerived) or _pulled(s) for s in sub.subscribers)
                                                  ^^^^^^^^^^
  File "/venv/lib/python3.12/site-packages/reactivity/primitives.py", line 214, in _pulled
    def _pulled(sub: Subscribable):
RecursionError: maximum recursion depth exceeded

I also tried to not import app so I didnt have to patch the path, but ran into the same issue. I havent dived deep into the code yet so I couldnt immediately tell why this happens.

[HaraldTR]

Won't be hard, I think. Every integration only needs to override the run_entry_file method of a Reloader class (sorry for such a bad name😂), like the one I implemented for uvicorn:

Yeah nice! If I can get this to work as a part of my project, I will for sure want to contribute here to make it work for celery too.

[CNSeniorious000]

RecursionError: maximum recursion depth exceeded

Got it. It’s definitely due to a circular import. This is a bug in the HMR core, and I’ll fix it in the next few days when I have some free time.

[HaraldTR]

RecursionError: maximum recursion depth exceeded

Got it. It’s definitely due to a circular import. This is a bug in the HMR core, and I’ll fix it in the next few days when I have some free time.

Okay! I have a lot of imports in my project and typically import my packages in order to make sure I dont run into circular dependency issues. It might be that hmr resolves my modules and packages differently than how my project as a whole does it, or differently from python in general. Just a pointer! I will do some experiments myself, I will let you know if I figure anything out

[HaraldTR]

I think I might have found it!

1. reactivity/helpers.py line 127: self.track()
2. reactivity/primitives.py line 17: last.dependencies.add(self)
3. _weakrefset.py line 88: self.data.add(ref(item, self._remove))
4. _collections_abc.py line 834: return dict(self.items()) == dict(other.items())
5. Back to reactivity/helpers.py line 127: self.track()

This creates a circular dependency in the reactivity library itself. When adding an item to a dependency set, it triggers equality comparisons, which call items(), which calls track(), which tries to add to the dependency set again, creating an infinite recursion. I am pretty sure that is what is happening at least.

What do you think is the best way to fix it?

[CNSeniorious000]

Brilliant observation! It make sense. For the fix, consider adding a gloabl _no_track = 0 flag in primitives.py and bypass tracking when _no_track != 0.

@contextmanager
def untrack():
    primitives._no_track += 1  # noqa: SLF001
    try:
        yield
    finally:
        primitives._no_track -= 1  # noqa: SLF001

And wrap Subscribable.track with this context manager?

    if last is not self:
        with untrack():
            self.subscribers.add(last)
            last.dependencies.add(self)

Though somewhat inelegant.

---

BTW, I've never encountered this situation before. It would be very helpful if you could provide a minimal reproduction (for example, using only Reactive, Derived, and Effect).

---

Also, I noticed that the traceback you provided relates to the circular dependencies between Derived instances during triggering, not tracking. It seems we’ve uncovered two separate issues here 🤯

[HaraldTR]

BTW, I've never encountered this situation before. It would be very helpful if you could provide a minimal reproduction (for example, using only Reactive, Derived, and Effect).

I was not able to reproduce this with a minimal example. However, I think the problem is due to this:

If I dont do the src/server import I will often get circular import issues, for example when running alembic migrations. This is because I have a set initialization order according to my project dependency rules. I do this in __init__.py and __main__.py. I init settings before database clients, before business logic for example. Trying to patch these imports using patch_meta_path, patch_module results in the same circular dependency issues. I assume hmr does not follow the ordering of imports that I want, and therefore get circular deps issues.