#7000 closed (wontfix)
Provide option to automatically open development server URL with webbrowser (std lib)
| Reported by: | Jannis Leidel | Owned by: | Jannis Leidel |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| Severity: | Keywords: | browser command runserver | |
| Cc: | flori@… | Triage Stage: | Design decision needed |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
I think it would be a very useful addition in the daily development work to have an option that opens the URL of the develeopment server in the default system browser.
For example restview makes use of Python's webbrowser module that is used in the attached patch.
Attachments (1)
Change History (12)
by , 17 years ago
| Attachment: | open_browser.1.diff added |
|---|
follow-up: 3 comment:1 by , 17 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
This looks useful. The only thing I would suggest is that the code for opening a browser should be executed once when the command is invoked initially, so the autoreload can still be enabled. If I were to use this feature, I'd probably run the command once, ctrl+c, remove the --browser option, and start it again. In my opinion, it almost defeats the purpose.
comment:2 by , 17 years ago
I'm not sure about that, mainly, as webbrower docs say, if it needs to use a text browser for some reason the server will lock.
comment:3 by , 17 years ago
Replying to programmerq:
Right, having autoreload would be useful, I'm going to change the patch to call webbrowser.open outside of the inner_run() loop.
Replying to telenieko:
Since "--browser" is off by default there is no way a developer on a text shell would accidentally use it. Though I agree that this should be documented by stating --browser is most useful in graphical environments. I think it saves serious time in daily work.
comment:4 by , 16 years ago
| milestone: | → post-1.0 |
|---|---|
| Status: | new → assigned |
I'm setting this to post-1.0 since it's just not that important.
comment:5 by , 16 years ago
Correct me if I'm wrong, but won't that fail on users who enter 0 or 0.0.0.0 as their ip(since it is a catchall)?
comment:7 by , 16 years ago
RFC1700, around page 4, 0.0.0.0 *must* only be used as a source address (i.e.: bind to all interfaces) but not as destination.
It'd be better to translate 0.0.0.0 to "localhost" before opening the browser.
comment:8 by , 16 years ago
| Cc: | added |
|---|
comment:9 by , 16 years ago
As a compromise I suggest adding that feature to the runserver_plus command of the django_extensions app. What do you think?
comment:10 by , 16 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
Closing as wontfix after adding the option to the revision 113 of the django_extensions app.
patch including docs