-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify error about taken port in serve
; allow to open a browser
#3498
base: master
Are you sure you want to change the base?
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. |
@@ -248,7 +252,9 @@ def cli(): | |||
|
|||
|
|||
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK what do you suggest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
serve
portmkdocs serve
fails to bind a portmkdocs serve
switch to another port if the current port is busy #3496