TinyTeX: a LaTeX distribution that installs the missing package for you

The two problems the project set out to solve

The README states the motivation as two common problems with installing and maintaining LaTeX distributions, and they are the same problem seen from opposite ends.

The first is the size trap. You have to either install a basic version that is relatively small, several hundred MB, but basically does not work, because it is very likely that certain frequently used LaTeX packages are missing. Or you install the full version, which is several GB, and in your whole life you will probably use only 1% of the packages.

There is no good middle option in the standard distribution, and that is the observation the project is built on. Either you accept a broken toolchain, or you accept a large one, and the amount of disk you waste is roughly the amount of setup you avoid.

The second problem is the documentation. The documentation for installation and maintenance is often too long for beginners. The tlmgr manual is given as the example, described as comprehensive and very useful, but often hard to figure out what to do when running into a LaTeX issue that says a certain .sty file is not found.

That is a specific and very recognisable frustration. The error message names a file, and the reader is expected to know that .sty files live inside TeX packages, that packages are managed by tlmgr, and that tlmgr has its own verbosity and its own subcommands. TinyTeX is positioned as the answer to both problems at once: small in size but still functional in most cases, and clear about what to do when a package is missing.

The claim in the README is that these problems can be solved by a custom LaTeX distribution based on TeX Live that is small in size but still functions well in most cases, and that even if you hit a missing package it should be clear what you need to do.

Automatic package installation, which is the part that changes the workflow

The strongest sentence in the README is the one about R Markdown users. If you are an R Markdown user, there is nothing you need to do, because missing packages will just be installed automatically. You may not even know the existence of LaTeX at all since it should rarely bother you.

That is the design goal stated in its most useful form. The distribution itself is small, and the recovery path when something is missing is automatic, so the failure mode of a small distribution, which is that it is missing the package you needed, is handled by the R package rather than by the user.

The distinction between the two artefacts is worth being precise about, because it explains the repository layout and the licensing split. This repo contains the installation scripts of TinyTeX, under the tools directory, and the R companion package tinytex. The full documentation is at the project website, and the author's aside about hoping it is not too long tells you the documentation is a real part of the project rather than an afterthought.

So there are three pieces in play. The installation scripts build a distribution from TeX Live components, and they live here. The R package is what an R user interacts with, and it is what performs the on-demand installation. The resulting distribution is what gets installed on a machine, and the README links to a separate repository, tinytex-releases, for its licence, which is where the GPL-2 grant for the distribution comes from.

The practical takeaway is that the R package is the part most people will use, and it is the part most people will read the documentation for. The scripts in tools/ are for people building the distribution, which is a much smaller group.

An R package that lives on CRAN, in a repository that also builds distributions

The repository is an R package repository and a distribution build repository at the same time, and the file list shows both.

The R package side is conventional. There is a DESCRIPTION file, a NAMESPACE, an R/ directory with the source, man/ with the documentation, inst/ for installed files, tests/ for the test suite, a tinytex.Rproj project file, a NEWS.md changelog, a .Rbuildignore file, and a .vscode/ directory. The R CMD check workflow badge is the standard one for an R package, and codecov is wired to the main branch, so the test coverage of the R code is tracked.

The distribution side is the tools/ directory, which contains the installation scripts, plus a TUGboat/ directory, which is the directory a LaTeX package uses for its user-facing magazine articles. A TUGboat directory in a LaTeX distribution repository is a convention from the TeX User Group, and its presence suggests this project keeps the same publishing discipline for its own documentation as for a package distributed through CTAN.

The release cadence is steady. The version list shows tinytex 0.61 on 2026-09-17, 0.60 on 2026-06-16 and 0.59 on 2026-03-28, which is roughly every three months. The last push to the repository was on 2026-10-13, and the repository is not archived.

One thing to note about the version numbers. The package version 0.61 does not correspond to the TeX Live version it is built around, and the two are released independently. The R package is the versioned thing you install from CRAN, and the distribution it fetches is a separate artefact with its own versioning scheme, described in the tinytex-releases repository the README links to.

Two licences for two artefacts, and what that means in practice

The licensing is stated precisely in the README and it is worth reading carefully, because it is unusual.

The R package tinytex is licensed under MIT. The LaTeX distribution TinyTeX is licensed under GPL-2, and the README links to the tinytex-releases repository for that licence. The licence recorded for this repository is a custom one that GitHub cannot classify, which is consistent with a repository that contains both an MIT licensed package and the scripts that assemble a GPL-2 distribution.

What this means in practice is different for the two halves, and the difference matters for anyone building on it.

If you are an R user and you install tinytex from CRAN, you are using MIT licensed code. That is permissive, it places no obligations on your own project, and it is the same licence as most of the R ecosystem.

If you are redistributing the LaTeX distribution itself, you are redistributing GPL-2 licensed software, and TeX Live itself carries its own licensing arrangements for the packages it contains, which are not uniform. The GPL-2 grant covers the TinyTeX distribution as assembled by these scripts; the individual TeX Live packages it pulls in keep their own terms.

The practical difference between the two is that the R package is a tool you use and the distribution is an artefact you ship. Most people only ever touch the first.

The MIT grant on the package also means you can read it, modify it, and vendor it into your own tooling without obligations, which is worth something for a package whose whole job is to hide a complicated subsystem behind a simple function call. The GPL-2 on the distribution does not reach the R package, and the R package does not reach the distribution.

Where the automatic install approach is the wrong approach

The design has a clear shape, and the shape has a clear edge.

The edge is reproducibility. TinyTeX solves the missing package problem by installing packages when it discovers they are missing. That is exactly right for the case the author describes, compiling a document and walking away. It is exactly wrong for a case where you need to know that a specific version of a specific package will be present, because the set of installed packages then depends on what you happened to compile, and the moment your build runs somewhere else the set can differ.

That rules out a few concrete uses. A publishing workflow that must produce byte identical output on a different machine is in trouble, since the set of packages in the TinyTeX tree becomes part of the build inputs and is not pinned by the tool. A course that instructs students to install a particular set of packages and expects them to be there is in trouble for the same reason. A CI job that runs on a fresh container and compiles a document with a package that was never installed before will now install it during the build, which means the build has network access and the run is not hermetic.

The second edge is the scale of the change. A system that installs software while compiling a document is doing something a system administrator would want to know about, and on a locked down machine the automatic path will simply fail rather than fall back to a smaller distribution.

The third is that the automatic behaviour is invisible by design, which the README presents as a benefit. You may not even know the existence of LaTeX at all since it should rarely bother you. That is a good property for an R Markdown user and a poor one for anyone responsible for a build system, because the tool removes the visibility of a dependency decision that someone will eventually have to make.

The alternative is a full TeX Live installation, or the medium sized basic scheme, with the tlmgr manual open in another window. That is heavier and more painful, and the documentation says so plainly. The choice is between a tool that hides the problem and a tool that makes you deal with it, and TinyTeX bets on the first for a defined audience.

Editorial conclusion

TinyTeX fits someone who needs LaTeX occasionally, who is working in R Markdown or another tool that shells out to pdflatex, and who would rather not maintain a several gigabyte TeX installation to compile a report. It does not fit a publisher or a course that needs a curated package set, because the whole design is to install what is missing on demand rather than to guarantee what is present. Check three things before you commit. Check whether your workflow is compile-and-forget, because the automatic installation path is the feature that only helps when you do not need to pin a package set. Check that you can accept the licensing split, because the R package tinytex is MIT while the LaTeX distribution it installs is licensed under GPL-2, and the licence recorded for this repository is custom and GitHub cannot classify it. And check where the scripts live, because this repository contains the installation scripts under tools/ and the R package beside them, while the built distribution itself is released from a separate repository, tinytex-releases. The last push was on 2026-10-13, the newest release listed is tinytex 0.61 from 2026-09-17, and the package is on CRAN.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. rstudio/tinytex on GitHub