Avoid kernel restarts with "quarto preview"

[urbainvaes]

I use quarto preview from the command line in order to automatically re-render my document whenever the .qmd source changes. However, the program restarts a Julia kernel (my document contains Julia code) at every file change, and so rendering is very slow. Is it possible to avoid the kernel restarts or, even better, avoid re-running code cells that have not changed?

[cscheid]

Is it possible to avoid the kernel restarts or

We do have a jupyter daemon that keeps running across different renders. Unfortunately, we're tracking a bug where the daemon doesn't work on recent versions of Julia. Thanks for the patience and we'll

, even better, avoid re-running code cells that have not changed?

That's not possible with the current architecture in quarto, since .qmd files do not have the results in them. If you're willing to use nbclient (or some other execution infrastructure) by yourself, quarto does take .ipynb files with results as input, and does not re-execute them by default. So it's possible that this could be a more convenient approach for you.

[urbainvaes]

Thank you very much for your detailed response, I appreciate it. I noticed that sometimes it does work as expected (i.e. without kernel restart), and when it does the program is very responsive, which is great. I just haven't managed to figure out the specific conditions required to make this happen.

[urbainvaes]

On this subject, is it possible to avoid starting jupyter altogether if all I'm doing is printing code chunks (without evaluating them)? I haven't figured out a way to achieve this.

[cscheid]

It's unfortunately hard for us to make that work in general, because starting jupyter happens because of an engine determination (eg engine: jupyter) and code cell execution happens because of a contents of the code cells. Ideally, we'd be able to tell that if every cell has echo: false in them, then we could replace the engine execution with engine: markdown (our "trivial" engine).

But

1. we don't do that at the moment.
2. this is a change that is fairly prone to regression problems, because dynamic determination of engines has global consequences for semantics and formatting. We'd have to be a lot more careful about ensuring that the generated outputs match across engines. 3) this change is also potentially very confusing for multiple-language cases. If there are r and python code cells, but the r code cells all have eval: false, should we then target the jupyter engine? In that case, the semantics of printing are purposefully different (because of knitr and jupyter defaults).

I understand the issue with jupyter start performance. But I don't think the benefits outweigh the risks here.