Skip to content
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

Add tlmgr packages needed for quarto to knit to PDF #741

Merged
merged 1 commit into from
Jan 11, 2024

Conversation

yuvipanda
Copy link
Contributor

Follow-up to #721, adding tlmgr packages that quarto seems to need to knit to PDF. Without these, it takes a minute or more (depending on network) for first knit to happen apparently.

Reported to me by users from University of Toronto

Follow-up to rocker-org#721,
adding tlmgr packages that *quarto* seems to need to knit to PDF.
Without these, it takes a minute or more (depending on network)
for first knit to happen apparently.

Reported to me by users from University of Toronto
@cboettig
Copy link
Member

cboettig commented Jan 2, 2024

Thanks @yuvipanda , this looks good to me.

@eitsupi
Copy link
Member

eitsupi commented Jan 3, 2024

Given that some users don't need these packages and it's not clear what packages Quarto requires, I doubt whether it's worth adding them.

I think it depends on the purpose of this script.
Does it really matter that it takes 1 minute?

@eddelbuettel
Copy link
Member

The difficulty with latex 'on demand' issues is that they depend on the document in question. The only real answer, if someone really needs latex, maybe adding texlive. Else '1 min' once per run is not so bad, really.

@yuvipanda
Copy link
Contributor Author

For me, the goal is to make sure that the simplest possible document will knit to PDF. I think of those as 'these are the requirements for quarto' - similar to software package requirements, just in a different ecosystem. The packages added in this PR were required for the hello world of quarto document to knit:

Simple document that was tried to knit
---
title: "Untitled"
format: pdf
editor: visual
---

Quarto

Quarto enables you to weave together content and executable code into a finished document. To learn more about Quarto see https://quarto.org.

Running Code

When you click the Render button a document will be generated that includes both content and the output of embedded code. You can embed code like this:

1 + 1

You can add options to executable code like this

#| echo: false
2 * 2

The echo: false option disables the printing of code (only output is displayed).

$$
y=X\beta+\epsilon.
$$

rnorm(10)

So while additional tex packages that may be needed due to using extra features can be installed on demand, I think it's helpful to install the packages included in this PR as a baseline for 'support quarto'.

@yuvipanda
Copy link
Contributor Author

The sample document I showed is a slight modification of what RStudio opens if you go to File -> New File -> Quarto Document

@cboettig
Copy link
Member

cboettig commented Jan 5, 2024

Given that we already include some tlmgr packages, I think it makes sense that the 'out-of-the-box' dependencies on tlmgr for features already included in this docker image (i.e. rocker/verse) include all those which would be needed for default behaviors:

  • building an R package (with pdf documentation)
  • building a quarto PDF document using the default quarto pdf format.

I agree with @eitsupi that some users don't needs these packages. but that is also why we add latex late in the 'stack' (at verse, not in rocker/r-ver, rstudio, or tidyverse, and why we don't install (the several extra gigabyte) texlive dependencies. I agree with @eddelbuettel that 1 min isn't so bad in general, but I think default templates should be built faster, and it just feels a bit sloppy right now that we have missed some of those packages. I don't think we want the list to creep up (e.g. to include all deps of, say, rticles tlmgr dependencies, or reinvent the entire texlive package groups), but I think the set @yuvipanda has identified here is sensible. This PR would add very little to the size of the base images, have little chance of otherwise breaking downstream users, and strengthen this image in a clearly defined and limited-scope way to be 'self-consistent' with the out-of-the-box behavior. (Yes, future versions of quarto / pandoc pdf templates could lead to future changes here, but I suspect overall that scope is pretty limited).

So anyway, I appreciate all the points in general here but I'm in favor of merging this particular set.

@eitsupi
Copy link
Member

eitsupi commented Jan 11, 2024

Then let's merge this. The increase in capacity seems to be about 20MB.

@eitsupi eitsupi merged commit f0ad63b into rocker-org:master Jan 11, 2024
33 checks passed
@yuvipanda
Copy link
Contributor Author

Thank you, @cboettig @eddelbuettel and @eitsupi for your thoughtful stewardship of this project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants