Provide a simpler way to default runserver IP/port to 0.0.0.0:8000

[Ed Morley]

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

[Tim Graham]

The DevelopersMailingList is a better place to gather feedback than this ticket tracker. Bumping to Someday/Maybe pending such a discussion.

[Ed Morley]

Posted:
​https://groups.google.com/forum/#!topic/django-developers/-f_6QVC7fic

[Adiyat Mubarak]

I have thought that if runserver has --bind command to serve into public network along with user defined port, like python manage.py runserver --bind 80
and for sake of clean command. I agree with first option to allow define runserver configuration in settings.py

[Kamalavelan]

PR - ​https://github.com/django/django/pull/7666

[Ed Morley]

I've opened a PR for option (3) - allowing easier overriding of the default address by subclasses of the runserver command:
​https://github.com/django/django/pull/7865

We can then either close this ticket as fixed (and call options 1+2 wontfix) or else leave the ticket open to tackle them later.

[Tim Graham <timograham@…>]

In 751d77cd:

Refs #27537 -- Added default_addr(_ipv6) attributes to runserver command.

[Tim Graham]

I don't see any consensus on the mailing list about further enhancements here.