Opened 8 years ago
Closed 8 years ago
#27537 closed New feature (fixed)
Provide a simpler way to default runserver IP/port to 0.0.0.0:8000
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 |
Description
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 to0.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, since127.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
Attachments (1)
Change History (9)
comment:1 by , 8 years ago
Triage Stage: | Unreviewed → Someday/Maybe |
---|
comment:2 by , 8 years ago
comment:3 by , 8 years ago
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
comment:4 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
by , 8 years ago
Attachment: | 27537.diff added |
---|
comment:6 by , 8 years ago
Has patch: | set |
---|---|
Owner: | changed from | to
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.
comment:8 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I don't see any consensus on the mailing list about further enhancements here.
The DevelopersMailingList is a better place to gather feedback than this ticket tracker. Bumping to Someday/Maybe pending such a discussion.