Django compatibility

[heisen273]

Hey, just wondering whether you had in plans to make HMR compatible with django – I'm afraid I'm really not that good with metaprogramming to implement it myself 🥲

It's one of the blockers I'm facing in my HMR+pytest endeavor – apparently making pure pytest work is not enough(i did made it work in this MR heisen273/pyth-on-line-fork#1 + added logics that reloads the file immediately after the filechange in oppose to letting the code run till the very end. this makes reloading more natural, especially if you're working in debugger - see explanation & preview in linked MR), since almost everyone uses it in combo, e.g. pytest+django, pytest+flask, etc.

Would really appreciate your insight here.
And thanks a lot for fantastic work you've done so far.

[CNSeniorious000]

Thanks for reaching out.

Django is a long-standing and, in my view, quite a "heavy" web framework. A native HMR integration that seamlessly replaces its built-in reloader would certainly benefit many users. However, I have very limited experience with Django, so I'm probably not the right person to implement it. Perhaps consulting a Django maintainer would be a good way to move this forward.

However! As far as I know, Django can be run as an ASGI application:

• How to deploy with ASGI | Django documentation | Django
• How to use Django with Uvicorn | Django documentation | Django
• Django 3.0 release notes | Django documentation | Django
• Applications | Django documentation | Django

Since Uvicorn may be the most popular ASGI server, we already have a well-working integration for it, uvicorn-hmr. This means that instead of the uvicorn myproject.asgi:application command from the official docs, you should be able to just run uvicorn-hmr myproject.asgi:application to start your Django app with hot reloading.

If there's demand, or when I find some time, I can add a Django example to the examples/ directory in this repository.

---

Regarding your mention of pytest, I'd suggest opening a separate issue for that discussion to avoid mixing it with the Django topic here.

I took a look at your implementation and have a few thoughts, as I feel it's not quite ideal yet:

1. Your _kill_thread function seems designed to interrupt an await call (I'm not an expert on ctypes, just guessing from the name). However, it doesn't seem like there are any await calls to interrupt outside of the AsyncReloader's own logic. I suspect it only works in your video because the debugger's breakpoint introduces an await-like state that can be interrupted. If you ran it directly with python runner.py, I doubt it would be interruptible.
2. In your video, the changes apply immediately. This behavior is quite similar to our hmr-daemon tool. (Apologies for the missing README, but it's a library that's designed to just work). hmr-daemon starts a daemon thread that re-runs the modified module (and any affected ones) upon file changes.
3. My vision for an HMR + pytest integration is a bit different. I'm not looking to interrupt and restart the entire test suite. Instead, the goal is to be more like Vitest, where only the specific subset of tests affected by a code change is re-run. (I'm not familiar with pytest's internals, so I might need to consult one of its maintainers or even build a prototype test framework to explore the feasibility). The feature you demonstrated seems only effective within a debugger.

Finally, I noticed you achieved this by extending the HMR core via inheritance rather than modifying it directly. That's a great approach! You could easily integrate a script like this into your own project to enhance your workflow, or even publish it as your own package on PyPI