# Why is LaTeX separated into many thousands of packages?

This question might belong elsewhere but I figured if I posted it here I might come across someone that deals behind the scenes of LaTeX. I'm an assistant Linux Admin at my school and we install LaTeX for our professors that obviously need it. Why is it, though, that doing a "yum install" of LaTeX results in installation of nearly 2500 different packages? I realize we may be installing more than the "average joe" might, but doesn't this seem like over-modularization of an application?

-
"over-modularization of an application": You should not see LaTeX and its packages as one application. Rather every package is one. The splitting was used historically because (La)TeX should run on low-memory machines in the 80ties. Also most packages are provided by users and not by the LaTeX core team, so they need to be in there own files. You should compare LaTeX packages more to Perl modules. I'm sure there are 2.5k or more modules on CPAN as well. – Martin Scharrer Apr 5 '11 at 19:15
The core LaTeX stuff from the LaTeX Project (base + required + tools) is nothing like that big :-) The thing is that you can extend LaTeX. It's like wondering the totality of Perl modules available: the number of things that are the core product is a lot less than the total available. – Joseph Wright Apr 5 '11 at 19:16
Good points. I see what you mean. I guess, for some reason, I had it in my head that they weren't really third party plugins. – jphenow Apr 5 '11 at 19:18
I'm on the LaTeX3 Project, and one of the aims there is to develop something where more stuff is in the 'core product'. The issue is then that the current 'LaTeX' (i.e. all of those 2500-ish files) do a lot of things, and a new version needs to do those and more! – Joseph Wright Apr 5 '11 at 19:19
@Martin: What's funny is that we both thought of Perl. – Joseph Wright Apr 5 '11 at 19:20

The obvious answer is: because it can. Most systems are less flexible and die at a much younger age than TeX. Look at other successful systems and you will find the same traits: Perl, Python, Java, Ruby, C, and Unix - to name a few.

However, it's actually quite surprising that LaTeX developed such a strong eco system of packages because TeX's DNA isn't really wired for it. TeX lacks proper modules, scopes and abstraction mechanisms that we are taking today as granted in programming languages. This means that modularity in TeX and LaTeX is based mostly on conventions and therefore is quite fragile (much like modularity in C).

So, while I understand that the many packages (and sometimes their incompatibilities) can be inconvenient, especially for less experienced users, it's actually a sign of strength. I'd suggest to play to TeX's strengths rather than fighting its weaknesses.

The last sentence might suggest that I see no point in improving TeX or LaTeX in particular with respect to modularity. Quite the opposite indeed, as I consider projects like LaTeX3 or LuaTeX as very important to carry TeX and LaTeX forward. I said it more in the sense that one should embrace the power and flexibility of TeX/LaTeX rather than trying to restrict it to make it simpler. With respect to the installation, projects like TeX Live already do the heavy lifting for users and administrators.

-
TeX is a typesetting system, not a general-purpose programming language. – morbusg Apr 5 '11 at 20:33
@morbusg: That's true as an explanation for why TeX lacks certain programming constructs, but as all the LaTeX packages are actually for typesetting, they seem well within the intended scope of what it does have. – Ryan Reich Apr 5 '11 at 22:10
I think one should definitely fight those weaknesses: the scoping (which might not be avoidable, of course, unless one designs a complete tex overhaul) and the complicated path structure which makes local installation of packages a huge pain. – Debilski Apr 5 '11 at 22:52
@morbusg I understand that it is a typesetting system but also would argue that TeX never would have come this far if it were less programmable. I therefore think comparing the mechanisms that enable modularity in TeX and programming languages is useful. – Christian Lindig Apr 6 '11 at 5:29
Christian, @Ryan: Fair enough. I just felt it'd be good to comment on that distinction after the listed general-purpose programming languages. – morbusg Apr 6 '11 at 19:07

An answer is perhaps : `ConTeXt`! Why ? because `ConTeXt` is more compact and avoid some of the problems of `LaTeX` with multiples packages. Some of them are obsolete or incompatible. We can talk about flexibility but we need to talk about stability. I'm not a ConTeXt user but I read the excellent interview of Hans Hagen where HH ( great ! it's like Herman Hesse in SteppenWolf) talks about the difference between `ConTeXt` and `LaTeX`. Interview of HH

An extract :

What I do remember is that writing styles and extensions involved hacking around in the kernel. I believe that extensibility has never been part of the concept and that shows. I also know from talking to the core LaTeX people that it's very hard to improve things once users start doing that kind of hacking. Also, the output needs to be “as it was before”, a restriction that I didn't put upon myself with ConTeXt.

-
I'd agree about extensibility, which partly came about because of the restrictions on computing when LaTeX2e was written. (ConTeXt is newer, after all.) – Joseph Wright Apr 5 '11 at 20:34
But then you’ll find that you like that certain style very much and, oh, it’s been packaged in t-super-brilliant-style, and you need somebody to install this package as well. – It may be easier though, with Context – if it had the momentum. – Debilski Apr 5 '11 at 22:48
+1 for the HH comment `:)` – Will Robertson Apr 6 '11 at 12:19

I think that's the best thing about LaTeX: you can customize it as you wish and add your own bits and pieces :D

You never know when you might need something specific, so you have a lot to choose from...

-
I suppose, but are there really enough little (yet big enough) addons to warrant an entire package for each thing? over 2000 packages seems gigantic. – jphenow Apr 5 '11 at 19:16
Question answered in comments above :) I mistakenly took the extra packages as part of the core LaTeX team and not as third party add-ons which would obviously require them to be separate packages. I feel silly now, as that makes so much sense. – jphenow Apr 5 '11 at 19:20

I think this is a bit of a problem that arises with package managers and shared environments in general. In your Linux administrated systems you have the problem that only authorised people may install software – and more or less only software that has been packaged into the distribution may be installed.

In many cases it would be favourable that each user decides on their own which Tex packages they need to install – and in the best case, this package would virtually install itself. (I think Miktex on Windows made this possible.)

The tex structure makes the local installation a bit complicated though, because of its pretty special directory structure and therefore a it is rather impractical to have anybody install a package locally. The only way out for these systems seems to be the global installation routine – which means that 2500 packages need to be shipped to satisfy all needs.

-
Local package installation is usually pretty simple. Often, one need do no more than unzip an archive in ~/texmf. The TeX directory structure is certainly no more complicated than say the Linux directory structure. – TH. Apr 6 '11 at 0:25
And in fact, you can install an entire TeXLive distribution locally (not as an admin user) if you like. (Not necessarily recommended, but certainly possible.) – Alan Munn Apr 6 '11 at 4:08
I use MikTeX on Windows, and one of the things I generally like about it is the way it just goes and gets any missing packages the first time they are used. It makes it a lot simpler to just try things suggested here. – RBerteig Apr 6 '11 at 7:57
@TH. @Alan Munn : That may be okay for simple packages. But when it involves fonts, updmap stuff or even uninstalling, one wishes that there was a better tool for that. The Linux file system only works today because there are package managers. tlmgr is working well but unfortunately is not shipped with a Texlive installation on many Linux systems. – Debilski Apr 6 '11 at 8:50

## protected by Martin Scharrer♦Apr 5 '11 at 19:17

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.