#27537: Provide a simpler way to default runserver IP/port to 0.0.0.0:8000
-------------------------------------+-------------------------------------
Reporter: Ed Morley | Owner: nobody
Type: New | Status: new
feature |
Component: Core | Version: 1.10
(Management commands) | Keywords: runserver, bind,
Severity: Normal | loopback
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Use case:
* An app uses a VM for the local development environment (eg via Vagrant).
* It's required to be accessible from the VM host (either on it's own IP,
or on localhost via eg Virtualbox port forwarding) to allow development to
occur using editors/browsers on the host. (The configuration is such that
connections are only allowed from the VM host and not other machines on
the network, so this is still secure.)
* The app has no need for nginx/apache, since production is Heroku (where
that's discouraged) and so it uses gunicorn + WhiteNoise.
* During development, devs want to use runserver rather than gunicorn for
convenience (and familiarity for existing Django devs).
* However `./manage.py runserver` doesn't work, since that binds to the
loopback adapter of the VM guest OS only (127.0.0.1) and not 0.0.0.0,
wasting new dev time figuring out why connections aren't succeeding (since
some might not know the difference between 127.0.0.1 and 0.0.0.0, or even
if they do, might presume the VM networking operated over the loopback
adapater).
* This means devs have to type `./manage.py runserver 0.0.0.0:8000` every
time, which is a pain.
* Current workarounds are:
- Add nginx/apache/varnish as a reverse proxy to the VM, increasing
bootstrap time and boilerplate.
- Not use runserver, and use gunicorn instead (where the `PORT`
environment variable can be set, making it bind to `0.0.0.0:<PORT>` [1]).
- Add bash aliases to the development environment (but then they're not
immediately discoverable.
- Write a custom runserver command that overrides the inbuilt one (but
this requires overriding the `handle()` method, since `127.0.0.1` is
hardcoded [2]).
Possible changes that would make this easier:
1) Allow setting runserver default IP/port via settings.py
2) Allow setting runserver default IP/port via environment variables (like
`PORT` already supported by gunicorn, that defaults the IP to `0.0.0.0`
too)
3) Move the hardcoded `127.0.0.1` string [2] to an attribute on the
`Command`, like `default_port` is, to reduce the boilerplate for
overriding using a custom runserver command.
I can imagine (3) would be more likely to be accepted, however it would
still mean we have to override runserver, so (1) or (2) would be
preferred.
I'm happy to implement this - it would just be helpful to know people's
thoughts before I open a PR.
Many thanks :-)
[1]
https://github.com/benoitc/gunicorn/blob/6eb01409da42a81b7020cd78c52613d8ec868e94/gunicorn/config.py#L543-L544
[2]
https://github.com/django/django/blob/eb42d8d5d9b0968ce12d09760afff684bee56a3a/django/core/management/commands/runserver.py#L95
--
Ticket URL: <https://code.djangoproject.com/ticket/27537>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/051.3e3b70b0cedadcbb8bb8eea697b1418b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
