#30479 closed Bug (fixed)
Autoreloader with StatReloader doesn't track changes in manage.py.
| Reported by: | Keryn Knight | Owned by: | Tom Forbes | 
|---|---|---|---|
| Component: | Utilities | Version: | 2.2 | 
| Severity: | Release blocker | Keywords: | autoreload | 
| Cc: | Tom Forbes | Triage Stage: | Accepted | 
| Has patch: | yes | Needs documentation: | no | 
| Needs tests: | no | Patch needs improvement: | no | 
| Easy pickings: | no | UI/UX: | no | 
Description (last modified by )
This is a bit convoluted, but here we go.
Environment (OSX 10.11):
$ python -V Python 3.6.2 $ pip -V pip 19.1.1 $ pip install Django==2.2.1
Steps to reproduce:
- Run a server 
python manage.py runserver - Edit the 
manage.pyfile, e.g. addprint():def main(): print('sth') os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'ticket_30479.settings') ... 
Under 2.1.8 (and prior), this will trigger the auto-reloading mechanism. Under 2.2.1, it won't. As far as I can tell from the django.utils.autoreload log lines, it never sees the manage.py itself.
Change History (10)
comment:1 by , 6 years ago
| Cc: | added | 
|---|---|
| Component: | Core (Management commands) → Utilities | 
| Description: | modified (diff) | 
| Severity: | Normal → Release blocker | 
| Summary: | Auto-reloading with StatReloader may not track changes to the main entrypoint? → Autoreloader with StatReloader doesn't track changes in manage.py. | 
| Triage Stage: | Unreviewed → Accepted | 
comment:2 by , 6 years ago
| Owner: | changed from to | 
|---|---|
| Status: | new → assigned | 
Argh. I guess this is because manage.py isn't showing up in the sys.modules. I'm not sure I remember any specific manage.py handling in the old implementation, so I'm not sure how it used to work, but I should be able to fix this pretty easily.
comment:3 by , 6 years ago
Done a touch of debugging:
iter_modules_and_filesis where it gets lost.
Specifically, it ends up in there twice:
(<module '__future__' from '/../lib/python3.6/__future__.py'>, <module '__main__' from 'manage.py'>, <module '__main__' from 'manage.py'>, ...,)
But getattr(module, "__spec__", None) is None is True so it continues onwards. I thought I managed to get one of them to have a __spec__ attr but no has_location, but I can't seem to get that again (stepping around with pdb)
Digging into wtf __spec__ is None: Here's the py3 docs on it, which helpfully mentions that The one exception is __main__, where __spec__ is set to None in some cases
comment:5 by , 6 years ago
I'm sorry for assigning it to myself Mariusz, I intended to work on it on Tuesday but work overtook me and now I am travelling for a wedding this weekend. So I doubt it I'm afraid.
It seems Keryn's debugging is a great help, it should be somewhat simple to add special case handling for __main__, while __spec__ is None we can still get the filename and watch on that.
comment:6 by , 6 years ago
np, Tom, thanks for info.
Keryn, it looks that you've already made most of the work. Would you like to prepare a patch?
comment:8 by , 6 years ago
| Has patch: | set | 
|---|
Thanks for the report. I simplified scenario.
Regression in c8720e7696ca41f3262d5369365cc1bd72a216ca.
Reproduced at 8d010f39869f107820421631111417298d1c5bb9.