Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#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 Mariusz Felisiak)

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.py file, e.g. add print():
    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 Mariusz Felisiak, 6 years ago

Cc: Tom Forbes added
Component: Core (Management commands)Utilities
Description: modified (diff)
Severity: NormalRelease 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: UnreviewedAccepted

Thanks for the report. I simplified scenario.

Regression in c8720e7696ca41f3262d5369365cc1bd72a216ca.
Reproduced at 8d010f39869f107820421631111417298d1c5bb9.

comment:2 by Tom Forbes, 6 years ago

Owner: changed from nobody to Tom Forbes
Status: newassigned

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 Keryn Knight, 6 years ago

Done a touch of debugging:

  • iter_modules_and_files is 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)

Version 0, edited 6 years ago by Keryn Knight (next)

comment:4 by Mariusz Felisiak, 6 years ago

Tom, will you have time to work on this in the next few days?

comment:5 by Tom Forbes, 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 Mariusz Felisiak, 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 Tom Forbes, 5 years ago

Has patch: set

comment:9 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

Resolution: fixed
Status: assignedclosed

In b2790f74:

Fixed #30479 -- Fixed detecting changes in manage.py by autoreloader when using StatReloader.

Regression in c8720e7696ca41f3262d5369365cc1bd72a216ca.

comment:10 by Mariusz Felisiak <felisiak.mariusz@…>, 5 years ago

In 5bf2c87e:

[2.2.x] Fixed #30479 -- Fixed detecting changes in manage.py by autoreloader when using StatReloader.

Regression in c8720e7696ca41f3262d5369365cc1bd72a216ca.

Backport of b2790f74d4f38c8b297b7c1cef6875d2378f6fa6 from master

Note: See TracTickets for help on using tickets.
Back to Top