Would latex-clean = false make pdf building faster?

[memeplex]

Description

By default Quarto will remove all intermediate files after building a pdf using its own latex pipeline, as documented in https://quarto.org/docs/output-formats/pdf-engine.html#pdf-compilation. I'm used to keep intermediate files (inside an output dir under /tmp) with latexmk since that makes the build quite faster. But I don't know about the internals of Quarto's default pipeline.

• Is there any advantage in keeping those files?
• Is it safe or may I end with a document with broken references or such?

Thanks!

[mcanouil]

I think the question is the other way around: why do you want to keep intermediary files? Only to avoid the time spent deleting them?
Note that Quarto offers keep-* options to keep intermediary files.

[memeplex]

I think the question is the other way around: why do you want to keep intermediary files? Only to avoid the time spent deleting them?

I don't know about the internals, but in general latexmk is quite faster when you keep intermediate files from previous runs.

[mcanouil]

If you don't ask to delete files, it's expected that it takes less time ("quite faster" is a subjective so I don't really know what this means).
Here, you question is mostly about one particular LaTeX engine.
Quarto does not control how those engines works internally, it can pass some flags to Pandoc that pass those flags to the engine.
Anyhow, you'll have to look at the engine you want to use to make your workflow as you want.
Not cleaning up intermediary files (either from completed renders or failed ones) expose you to unexpected output as the engine might reuse those intermediary files.
In the end, it's 100% up to you to take the risk if you think "quite faster" worth it.

[memeplex]

If quarto is just passing the latexmk engine option to pandoc, that's the information that I need because that is what I have been doing myself for years, but I've read that quarto does its own thing, automatically installs latex packages, etc. So that's why I was asking.

Supposing that I want to keep intermediate files, is there a way to set that in a system-level or user-level fashion other than wrapping the quarto command?

[mcanouil]

automatically installs latex packages

That's not the engine.
That's the LaTeX distribution, especially TinyTex which is the recommended distribution. You can find it in the documentation and there are several threads about it.

Supposing that I want to keep intermediate files, is there a way to set that in a system-level or user-level fashion other than wrapping the quarto command?

I don't understand. You already know the answer to that question. It's in the title of your post.
Source: https://quarto.org/docs/reference/formats/pdf.html#latexmk

latex-clean | Clean intermediates after compilation.

I am starting to get confused about what you want exactly.
This was already the case with the title of your post "Would latex-clean = false make pdf building faster?" which kind of had an obvious answer "yes, removing steps decrease time (while cluttering your workspace)".
You have all Quarto and Pandoc options, so define whatever configuration you want as both uses YAML front matter in parallel / as alternative to command line options.

[memeplex]

automatically installs latex packages

That's not the engine. That's the LaTeX distribution, especially TinyTex

I know what is an engine, I know what it tinytex. Perhaps you should update your documentation then:

https://quarto.org/docs/output-formats/pdf-engine.html#quarto-pdf-engine

Quarto’s built-in PDF compilation engine handles running LaTeX multiple times to resolve index and bibliography entries, and also performs automatic LaTeX package installation.

which kind of had an obvious answer "yes, removing steps decrease time (while cluttering your workspace)".

No, it's not obvious considering that there is a "Quarto’s built-in PDF compilation engine" documented that now you say there actually isn't. Then it becomes obvious.

You have all Quarto and Pandoc options, so define whatever configuration you want

I'm well aware of this. My last question was: is there any way to set these options at system or user level (so I don't have to specify them in every project or document)? Because if there isn't, the only workaround I see is to wrap the quarto command so that I can set the appropriate options there.

[mcanouil]

"Quarto’s built-in PDF compilation engine"

I believe the choice of words here is ambiguous and confusing. Thanks for raising this.
Quarto does some processing before PDF rendering by the actual PDF engine such as "xelatex" (default), "pdflatex", "luatex", "latexmk", etc.
Here the sentence describes in fact the pre-processing done by Quarto.
@cscheid could confirm or correct me on that.

is there any way to set these options at system or user level (so I don't have to specify them in every project or document)?

That's not how Quarto works.
Quarto works on a project level using _quarto.yml, then directory level using _metadata.yml, then front matter YAML level.

[memeplex]

So I'm going to assume that by default this thing quarto does is ultimately calling latexmk. I know for sure that latexmk takes advantage of previous intermediate files in order to speed up the build. And there is no way to set latex-clean = false at the user/system level, so I'm going to wrap the quarto command so as to pass the appropriate pandoc option to render, or look for another workaround. Thank you very much.

[mcanouil]

If you don't want to set it in your _quarto.yml, then yes you'll have to pass this from the command line.

[memeplex]

Thing is I'd like to use Quarto for many standalone little documents outside any project, so that would involve adding the same options to every front matter. OTOH I'm not calling it from the CLI but mostly using the VSCode extension, where AFAICS there is no way to set command line options for the quarto command, but just its path. From what I've read in some other discussion or issue, I understand that you don't want to provide a way to set options outside projects so that everything is self-contained and reproducible. I tend to agree with the rationale, but some options are indeed more associated to the environment than to the project or document themselves. You can argue that there already are .local files for that use case and I don't disagree. Maybe the only thing that I miss is a VSCode option to set CLI arguments. Another workaround may be to set a dummy project file at the top of my Documents folder.

[mcanouil]

OTOH I'm not calling it from the CLI but mostly using the VSCode extension, where AFAICS there is no way to set command line options for the quarto command, but just its path [...] Maybe the only thing that I miss is a VSCode option to set CLI arguments.

This would be a feature request to https://github.com/quarto-dev/quarto