# Dependencies

There’s been some recent discussion on the TeX Live mailing list about recording dependencies for (La)TeX packages. This is a good idea but means that package authors need to think about their dependency situation. So I thought a few words on this would be helpful, at least from the point of view of the most common case: LaTeX packages.

It’s pretty easy to accumulate \RequirePackage lines in your source, but if you are serious about giving a useful set of dependencies you need to know what each one is for. In many ways the rule is easy: require each package you use. What makes that more complicated is that you might use features which are available when you load package X but are actually provided by package Y. For example, if you load my siunitx package, it loads array so means that you can do for example

\begin{tabular}{>{$}l<{$}}


So how do you tell what your ‘real’ dependencies are? The usual rule is that you check the documentation: does it say that package X itself provides the features you use? In the case above, siunitx doesn’t document that syntax extension for tabular: it’s documented by array. So if you wrote a package that uses siunitx but also needs to use features from array you should

\RequirePackage{array}
\RequirePackage{siunitx}

This means that even if at some future stage there’s a change in the internals of a package you load, things should still all work.

If you want to track down where stuff might be coming from, you can always \listfiles to get a full overview of your current package use (starting from a small example).

There are a few places were packages are so closely linked you might not have to list them both. The most obvious is TikZ/pgf: the two are different ‘layers’ of the same set up but are documented together, so if you load TikZ you can assume pgf. Of course, there is no harm in listing both!

### 2 thoughts on “Dependencies”

1. Denis J. Navas

I made this excersize with a template I use for class notes and discovered that the most complex package is polyglossia. Polyglossia requires the bidi package and this in turn, starts a complex maze of five required packages and zref-abspage, that through zref-base requires ltxcmds (again), infwarrer, kvsetkeys which requires infwarrer, etc … in total 14 requirements of 8 packages; zref-abspage also requires atbegshi which makes 15 requirements of 8 packages, six of these previously required by zref-base.

This makes me think that a polyglossia version without the bidi requirement, could help with a faster compile with LuaLaTeX, where polyglossia impact is more notorious and this have been considered in TeX StackExchange in the following questions:
– lualatex-is-consuming-40-sec-is-there-a-way-to-reduce
Package loading is quite a fast process in general: it’s largely down to the number of files so something like pgf (broken up into lots of files) is more of an issue that loading a dozen separate but ‘monolithic’ packages. As mentioned many times on TeX-sx and in other places, the time taken by LuaTeX for processing isn’t to do with loading packages but rather that it’s doing a lot of work with Unicode data structures.