#31716: django-admin runserver mostly does not work on Windows
-------------------------------------+-------------------------------------
Reporter: Christian Ullrich | Owner: nobody
Type: Bug | Status: new
Component: Core (Management | Version: 3.0
commands) |
Severity: Normal | Resolution:
Keywords: Windows | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Christian Ullrich):
The best solution that I can come up with is adding this in the else
branch of get_child_arguments():
{{{
if sys.platform == 'win32':
for i in range(1, len(args)):
if args[i].lower().endswith("scripts\\django-admin"):
# setuptools style; setup.py develop or pip install -e
if os.path.exists(args[i] + "-script.py"):
args[i] = args[i] + "-script.py"
# pip style
elif os.path.exists(args[i] + ".exe"):
args[i] = args[i] + ".exe"
}}}
I think this has about as much chance of being accepted as would solving
the problem properly by dropping all Windows support, but if you think I
should make the attempt, please let me know.
The two branches exist because there are (at least) two types of these
.exe "scripts". If generated by pip install, they have ~100 KiB, contain a
small block of Python at the end, and can be run directly by the
interpreter ("python.exe django-admin.exe" works in that Python finds the
embedded script). However, if they are generated by setuptools, they do
not have the Python block, are only ~70 KiB, and can ''not'' be run as
scripts. Instead, there is the "...-script.py" companion script whose name
they derive from their own and that they run via sys.executable .
Then there is the case of "python -m django runserver", about whose
existence I just found out in get_child_arguments(), and whether that may
need special treatment, too.
Not to mention that the processes end up stacked five deep. Yes, it is a
dev situation so it doesn't matter much, but a better fix would still be
to reinvent autoreloading entirely, again, and ''somehow'' get by without
the monitoring process and $RUN_MAIN. (Getting rid of the bouncing around
between the venv and system pythons would be nice, too, but that's another
department.)
--
Ticket URL: <https://code.djangoproject.com/ticket/31716#comment:4>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/068.c496451806a32e9c9dac40a4e3a33756%40djangoproject.com.
