Opened 4 years ago
Last modified 3 years ago
#32669 closed New feature
Allow autoreloading of `python -m custom_module runserver` — at Version 2
Reported by: | Moriyoshi Koizumi | Owned by: | Moriyoshi Koizumi |
---|---|---|---|
Component: | Utilities | Version: | 4.0 |
Severity: | Normal | Keywords: | autoreload runserver |
Cc: | William Schwartz | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The original fix [1] only attempted to deal with -m foo.bar
where bar
is a package and __main__.py
exists under foo/bar
.
When a dotted name for a module (for example, foo.bar.baz
where baz.py
resides under foo/bar
) is specified like -m foo.bar.baz
, the resulting arguments end up being -m foo.bar
, which is uncalled for.
[1] https://github.com/django/django/commit/ec6d2531c59466924b645f314ac33f54470d7ac3
Fixed detection when started non-django modules with "python -m" in autoreloader.
Change History (3)
by , 4 years ago
Attachment: | 32669-autoreload-fix.patch.diff added |
---|
comment:1 by , 4 years ago
Description: | modified (diff) |
---|
comment:2 by , 4 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
Owner: | changed from | to
Status: | new → assigned |
Summary: | Fix for #32314 causing problems with non-package dotted name specified to -m → Allow autoreloading of `python -m custom_module runserver` |
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → New feature |
Version: | 3.2 → 4.0 |
It doesn't work in Django 3.1 so I would not call it a regression.
Can you send PR via GitHub?
Patch