Opened 7 years ago

Closed 7 years ago

#27537 closed New feature (fixed)

Provide a simpler way to default runserver IP/port to

Reported by: Ed Morley Owned by: Ed Morley
Component: Core (Management commands) Version: dev
Severity: Normal Keywords: runserver, bind, loopback
Cc: Triage Stage: Someday/Maybe
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


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 ./ runserver doesn't work, since that binds to the loopback adapter of the VM guest OS only ( and not, wasting new dev time figuring out why connections aren't succeeding (since some might not know the difference between and, or even if they do, might presume the VM networking operated over the loopback adapater).
  • This means devs have to type ./ runserver 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<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 is hardcoded [2]).

Possible changes that would make this easier:
1) Allow setting runserver default IP/port via
2) Allow setting runserver default IP/port via environment variables (like PORT already supported by gunicorn, that defaults the IP to too)
3) Move the hardcoded 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 :-)


Attachments (1)

27537.diff (2.1 KB ) - added by Kamalavelan 7 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 by Tim Graham, 7 years ago

Triage Stage: UnreviewedSomeday/Maybe

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

comment:3 by Adiyat Mubarak, 7 years ago

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

comment:4 by Kamalavelan, 7 years ago

Owner: changed from nobody to Kamalavelan
Status: newassigned

by Kamalavelan, 7 years ago

Attachment: 27537.diff added

comment:5 by Kamalavelan, 7 years ago

Version: 1.10master

comment:6 by Ed Morley, 7 years ago

Has patch: set
Owner: changed from Kamalavelan to Ed Morley

I've opened a PR for option (3) - allowing easier overriding of the default address by subclasses of the runserver command:

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.

comment:7 by Tim Graham <timograham@…>, 7 years ago

In 751d77cd:

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

comment:8 by Tim Graham, 7 years ago

Resolution: fixed
Status: assignedclosed

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

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