# How do packages work ? Why aren't they all pre-initiated?

I have been using LaTeX for about a month now and whenever I have a question, most answers involve adding new packages to the preamble.

My question is, how do these packages work? Are they all included in source code and just waiting to be initiated in the preamble?

Why don't they all come activated (pre-initiated) without the need to manually insert them?

If this is all done locally without using the internet, it provokes another question: can you use packages from an online source without manually downloading them? If not, is that in the works?

• there are more than 3000 packages. It is not a good idea to load them all by default ... ;-) – user2478 May 1 '13 at 18:31
• In simple terms: Packages are to LaTeX what Lego pieces are to your big pirate boat :) – Mario S. E. May 1 '13 at 18:31
• @Razor: You are free to create your own LaTeX which has all those packages preloaded. That is what we call a special format, like LaTeX itself. – user2478 May 1 '13 at 18:35
• @Razor -- not all tex users are mathematicians. most math packages aren't needed for, e.g., linguistics, and vice versa, never mind folks who want to prepare dramatic scripts or set poetry. a number of well-designed packages use \RequirePackage statements to pull in others that are really necessary, so by learning such details, it's possible to minimize the number of \usepackage statements in your preamble. and you can always create your own mybasics.sty if you always use the same package collection. – barbara beeton May 1 '13 at 19:09
• I've always thought of the \usepackage commands as a facsimile for C/C++'s #include (or similar in other languages). If you don't have those statements, then the code (in this case packages) wont be included by the linker, thus they wont end up being used to compile the document. – Jamie Taylor May 2 '13 at 9:17

Packages are simply tex files with commands as you may define in your own document. Many packages are essentially options where it doesn't make sense to load both font packages: or packages for footnote styles and other layout choices etc.

If LaTeX was being designed now, it would probably have more code in the preloaded format, but in 1993 when LaTeX2e was designed there was room for around 100 commands (including \label) in a document after you had loaded amsmath so having the option of not loading such packages was a vital option. In fact for many years LaTeX was distributed with an autoload version where parts of the code such as picture mode and tabbing were not preloaded by default and were essentially packages (that automatically loaded if the environments were used). This was to leave room for more user commands and cross references in the document.

The time taken to load a package file is not usually that significant, however if you make heavy use of classes that load a lot of packages it is possible to preload them into a personal format. (see mylatexformat for example).

I would say that it's good that LaTeX doesn't preload a large set of packages. This, as explained by David Carlisle, is due to historic reasons based on the small computing power of 1990's machines, but has very useful consequences.

Let me present an example. Along with LaTeX2e, some packages were released as integral part of any LaTeX distribution, among which one finds enumerate. This is a great addition for customizing enumerated lists, but has been largely superseded by a much more powerful package such as enumitem.

Assume that enumerate had been made part of LaTeX without the need to load it separately; then I'd see only two possibilities for exploiting the power of enumitem:

1. Load enumitem as separate package, that is, what's done today;
2. Integrate enumitem in LaTeX, with the consequence of probably breaking documents written with the enumerate functionalities in mind.

Other examples. What high level graphic package would be chosen as part of LaTeX? PSTricks or TikZ? Or, perhaps, mfpic? If the first had been made part of LaTeX we probably wouldn't have pdflatex, that's incompatible with PSTricks in many features, or we'd have a PDFLaTeX format with PSTricks disabled: a sure source for "format wars", that is, slightly incompatible versions of the same LaTeX. Precisely one of the reasons why LaTeX2e was released: give an end to the multiplication of different LaTeX 2.09 versions (one adjusted for Dutch, one for German, one for A4 paper, another for Russian and so on).

A count of subdirectories in <texlive2012>/tex/latex returns 1731. This means much more tha 1731 packages, since those directories often contain more than one package. Several of them are almost dead, kept only for backward compatibility. If those had been integrated in the LaTeX kernel, the problems I showed with the enumerate versus enumitem example would be multiplied.

Here's where the idea of packages is good: you're not stuck with something that has been written twenty years ago from a perspective that might have revealed not as general as it could. New packages can solve old problems in a cleaner and better way, but documents written twenty years ago can still be typeset without changes.

This is not so different from what happens with programming languages. Do people load all C libraries for their programs? Do Perl scripts load the whole CPAN for a single run? On the contrary, you don't have libraries/packages with LibreOffice or similar software: All You Get Is What They Gave. And old documents will easily break with new versions of the software.

• in addition to what's in <texlive2012>/tex/latex, a number of "packages" that reside in <texlive2012>/tex/generic can also be used with latex, increasing the count. (but i haven't counted them.) – barbara beeton May 1 '13 at 20:53
• +1 for comparison with C libraries. It never gets boring to type #include <stdio.h> or in C++ #include <vector> and using namespace std;, but in fact thereare cases when you need neither of these. – Hagen von Eitzen May 1 '13 at 21:14
• @Hagen Indeed, continuing in this line of inquiry one might ask (absurdly) why one needs to install software at all, when the computer could come with all programs already loaded and perhaps present in memory at boot. – Ryan Reich May 1 '13 at 21:39
• @RyanReich Haha, nice twist. – percusse May 1 '13 at 22:09
• @Hagen,RyanReich But that's how it is on my Mac, it just works... Ok, I'll leave now :) – Xavier May 2 '13 at 6:59

One of the beauty of (La)TeX is that it is fully programmable. As a consequence, many people create their own set of commands and, sometimes, release them as packages when they believe they could be useful to others.

I do agree to some extend that some (basic) functionalities could be included in the LaTeX "base", but don't overlook the difficulty of doing so, e.g.

• (La)TeX enables a very broad range of output, from giant posters to big multi-volume books, and including charts, presentations, resumes, music scores, etc., so what might be "basic" for one application might be completely useless for another,
• for a specific application, not everyone agrees on what constitutes "basic" functionalities that should be included,
• even for some supposedly agreed upon "basic" functionality for a specific application, there are always different ways to implement them, and they are often incompatible with each other!

Here are some technicalities:

• If you \usepackage{whatever}, it means that a whatever.sty file is present/will be downloaded on your computer and loaded during compilation.
• A .sty file contains TeX commands in source code form, and may load other .sty files.
• Packages can be written by anybody, not only a centralized development team. This means there is no control over what goes into them. Because of this some packages clash with each other, so they can't be loaded together. For example when the package has been written a long time ago, or by a less TeX-savvy person. You can't autoload a package by default because in some years there may be a better replacement written by someone in the community. And so on.
• As for MiKTeX, TeX Live can be installed in full. – Xavier May 1 '13 at 19:32
• MiKTeX also comes with a graphical package manager (but the command line tools aren't worth their bits) so it is possibly to cherry-pick your packages. – Sean Allred May 1 '13 at 19:48

### How do packages work?

Packages are an extension mechanism that is standardised in Latex. Latex is itself made out of Tex macros, as are packages, and Latex defines commands and interface structure that allows the packages' Tex code to be executed. There is also a substantial social infrastructure that makes the package mechanism function, through the CTAN repository and through the efforts put into getting the big distributions like Tex Live and Miktex to work smoothly.

### Why are packages not pre-initialised?

The importance of packages in Latex, and the need for typical Latex documents to import many packages, is a result of the decision made in the 90s for Latex to evolve through this package mechanism, while other document preparation systems based on Tex tried to centralise their evolution. Context is one of those, and most Context documents I have seen only import modules (the Context counterpart to packages) to load fonts. The others generally have died.

The great advantage of the Latex model has been exploration of new functionality, resulting in excellent endeavours such as the memoir and KOMA script packages. The cost is that the Latex community has a cacophony of different ways to do similar things, and packages conflict in syntax, and sometimes interact badly.

One of the main goals of the Latex 3 effort is to rationalise this, by specifying uniform interfaces and incorporating more of the kind of things done in standard packages into the base system. To do this while keeping the Latex community with them is, and will continue to be a heroic effort, like herding cats with a robot sheepdog whose operating system is still under development.

### Can packages be loaded on demand from the internet

Miktex can load packages "on the fly"; Tex Live currently does not (see Joseph Wright, 'TEX on Windows: MiKTEX or TEX Live?', TUGboat). See also texliveonfly for Unix.

### Bonus question: Are there alternatives?

Context, as I mentioned, is the most important rival approach; there is some information at our Context tag wiki.

Plain Tex does not have a meaningful package mechanism: essentially you put bits of Tex code in your TEXMF directory and \input them, which is half of what Latex does with its package system, but there is no meaningful abstraction to handle things like repeated load requests, querying what has been loaded and the like. Some Tex code exists to try to impose structure. The lack of package structure is most painful when working with fonts.

• MiKTeX can load packages on demand from internet (I don't know about others). – Reinstate Monica May 2 '13 at 10:21
• @WolframH: Indeed. I've rewritten that part. – Charles Stewart May 2 '13 at 11:56

Here's my two cent's worth: (Quite obviously) it was already mentioned that loading thousands of packages can become unmanageable and packages might clash, it also depends on what engine you use (see for instance fontspec - works only for Xe(La)TeX and Lua(La)TeX). Plus you often want to select options when you load a package (of course, a mechanism can be thought of to customize things on the go, but that might be tricky at times: see mdframed - loads e.g. TikZ or PSTricks or neither, based on your preference; another one: biblatex will require you to invoke bibtex or biber for instance, you have to make this choice when you load the package).

The way I see it, the current system, loading packages individually, has several merits that outweigh the disadvantages. To keep it short, it's like a customizable Swiss army knife, where you decide how many blades, cork screws, files, etc. you want to add. Now imagine, how difficult it would be to wield one that has so many tools in it that you can barely wrap your fingers around it... (and possibly won't fit in your pocket either!) :D It sure looks 'cool', but it won't cut it!