Clarify error about taken port in serve; allow to open a browser
#3498
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
|
I dropped port randomization and trying multiple ports, compared to #3497. I think it can actually be too confusing. |
|
|
||
| @cli.command(name="serve") | ||
| @click.option('-a', '--dev-addr', help=dev_addr_help, metavar='<IP:PORT>') | ||
| @click.option('-a', '--dev-addr', help=dev_addr_help, metavar='IP:PORT') |
There was a problem hiding this comment.
So, please don't get me wrong, but IMHO, this is not a very consistent design. You can specify a port via --dev-addr, but also via --port? That's two ways of achieving the same thing.
There was a problem hiding this comment.
OK what do you suggest?
There was a problem hiding this comment.
Either remove --port or deprecate and split up --dev-addr into --host and --port. I'm not sure what you're aiming here for however, because --dev-addr is working perfectly fine.
There was a problem hiding this comment.
Also note that all of this might incentivize people to use the development server as a production server, because now you can only set the --port. --dev-addr carries dev in it, which I think was put there deliberately to keep people from using it in production. Still happens more often than one might think, as judging from issues I answered in the past.
There was a problem hiding this comment.
I would find a -p option really convenient. I literally never change the default host, and if I had to, it would probably be in a container setup where I would set it to 0.0.0.0 and never change it again. Whereas in (rare) cases where I serve multiple sites, I need to change the port, and having to re-specify the default localhost is a bit annoying.
So I wouldn't mind if --dev-addr was deprecated in favor of two --host and --port options. However I'm not the only MkDocs user and I fear it would be quite disruptive to deprecate --dev-addr for, again, rarely happening situations. Maybe they could both (dev-addr and host+port) live together, forever, as mutually exclusive options? Or maybe --dev-addr could be modified so that we can pass either HOST:PORT, or just HOST, or just PORT? It looks like it's easy to distinguish the three cases?
`dev_addr` flag already covers this but is too inconvenient to use
Suggest the user to pick some other port - the suggested number seems random but is actually derived from the current site's name.
|
What happens if I permanently set the port to 8010 with |
|
I wonder if this really brings value. Choosing a different ports among different projects will be cumbersome, and will not play well with project templates. Also it caters to a (I'd say) small fraction of users who run multiple live-reload servers concurrently. And IMO is only useful when you also use I feel like anything more than a default port plus a way to override it doesn't bring any real guarantee or benefit, and only increases cognitive overhead and/or maintenance work. I do note that this is an opt-in feature, so I won't push against it. |
|
Yea the feature kinda falls apart easily. A compromise where nobody will bother trying to benefit from it |
I feel that we're wasting our time discussing something that provides so little value as opposed to other open issues that would need more attention. This won't add any new functionality besides what's already achievable. |
|
For you perhaps time is money. And for me, not spending time on one interesting issue doesn't mean I'll be more likely to spend time on another issue (actually often quite the opposite) |
That's a key point 🙂, for occasional or volunteer contributors. Both viewpoints exist and complement each other. Of course, I am beating the drum for my own subjects of interest; though I can see and appreciate the other person's viewpoint. I any case if |
serveportmkdocs servefails to bind a portmkdocs serveswitch to another port if the current port is busy #3496