Default port for quarto preview?

[astrowonk]

Description

Why does quarto preview pick a random port every time it is used? Most other processes that spawn a local port use a predictable port number, sometimes incrementing by one if the port is in use (i.e. jupyter).

shiny run tries to use port 8000. streamlit run uses port 8501, Dash uses 8050 (because that's what Flask does.)

I know I can specify a port, but that's more typing. Why not just have a default port like all these other tools that create local web servers?

(I noticed this because my VS Code auto-port-forwarding list because very long with numerous quarto ports when previewing… and because I couldn't just re-load the url in my browser history since the port had changed when I ran the command again.)

Not sure if this is an issue or a question so I started with a discussion item!

[cderv]

@dragonstyle is this a design choice ? I guess we did not want any conflict with other tools.

[cscheid]

Is slides.qmd inside a bigger quarto project? I believe project is a project-level option, so you'll need to configure it in _quarto.yml.

[mcanouil]

Here the preview mechanism is local and as such as no reason to expose the same port all the time (because nothing should rely on the preview deployed version).

That's not entirely true. One reason I run into all the time is that when I need to test a webpage outside of vsc, every time I rerun quarto, I need to load the preview on a new tab. That gets annoying pretty fast, especially since the devtools associate my debugging choices with a URL, and that URL is changing.

Oh, I see, I personally does not kill the process, so the port is the same.
Also, when I am using external browser it is more fire "final validation" on several browser so I don't get annoyed by the port switching. 🤷‍♂️

[cscheid]

Oh, I see, I personally does not kill the process, so the port is the same.

That doesn't always work when you're changing things that our change detection doesn't detect :)

[mcanouil]

Oh, I see, I personally does not kill the process, so the port is the same.

That doesn't always work when you're changing things that our change detection doesn't detect :)

True, but within my three to four opened VSCode Quarto projects, closing and reopening browser tabs is better, so static port or not 😅

[astrowonk]

I've decided the best analogy here is hugo server -D which defaults to port 1313, but then picks a random port if it's unavailable (I still prefer jupyter's increment +1 behavior there.)

My actual solution was to just create this zsh script and put it in my path in ~/bin:

#!/opt/homebrew/bin/zsh

quarto preview $1 --port 8800

[astrowonk]

My two cents:

Note that random port is the default of many software when doing this sort of things (including VSCode). Also the services mentioned with static port are not at all the same things. Those are apps which you need to have static port from, otherwise you wouldn't be able to include them in Docker container etc. and redirect the port to something else. Here the preview mechanism is local and as such as no reason to expose the same port all the time.

Well, Streamlit and maybe Shiny (if one was going to serve it outside shiny server) do have external needs for predictable ports, but Flask/Dash default to port 8050 even though they explicitly say the built in web server is not for production (and thus not for containers.) Similarly, Jupyter is usually run locally and has a default port and predictable port behavior (incrementing by 1 when the port is in use.)

It mostly comes down to me wanting to re-use one browser tab or window, rather than have dozens of unique localhost:xxxx entries in my browser history. But I can achieve this via YAML thankfully!