41

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?

David Carlisle
  • 757,742
Razor
  • 2,691
  • 19
    there are more than 3000 packages. It is not a good idea to load them all by default ... ;-) –  May 01 '13 at 18:31
  • 16
    In simple terms: Packages are to LaTeX what Lego pieces are to your big pirate boat :) – Mario S. E. May 01 '13 at 18:31
  • Why not have the most common ones at least pre-initiated ?? such as math packages, fonts, long table, multi arrays, figure types etc .. Wouldn't that save a lot of time ? – Razor May 01 '13 at 18:32
  • 5
    @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. –  May 01 '13 at 18:35
  • It is worth noting that many LaTeX versions will auto-download your requested packages, on demand. – Steven B. Segletes May 01 '13 at 19:01
  • 13
    @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 01 '13 at 19:09
  • 2
    @Razor There may be several packages that can do the same thing and some packages are incompatible. Clearly, LaTeX cannot decide which one to choose. –  May 02 '13 at 08:18
  • 3
    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 02 '13 at 09:17
  • Thanks to everyone for replying. Greatly appreciated and very informative. – Razor May 03 '13 at 20:45

6 Answers6

39

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).

David Carlisle
  • 757,742
34

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.

egreg
  • 1,121,712
  • 2
    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 01 '13 at 20:53
  • 2
    +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 01 '13 at 21:14
  • 3
    @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 01 '13 at 21:39
  • @RyanReich Haha, nice twist. – percusse May 01 '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 02 '13 at 06:59
  • And yet, all of these new, improved versions of standard Latex commands that this cacophony of Latex packages delivers hasn't delivered functionality better than that which comes baked into regular Context. I'm not persuaded by this argument - I think this is a defect of Latex that stands in the way of its wider adoption. (Not to say that Context doesn't have its problems as well). – Charles Stewart May 02 '13 at 08:00
25

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!
Xavier
  • 13,947
15

Here are some technicalities:

  • Depending on your TeX distribution, the packages may or may not already be in your computer. MikTeX comes in "everything included" and "download-on-the-fly" flavors, TeX Live AFAIK does only do "download-on-demand".
  • 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.
marczellm
  • 11,809
13

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.

Community
  • 1
Charles Stewart
  • 21,014
  • 5
  • 65
  • 121
2

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!

Count Zero
  • 17,424