Now that we have seen how to both write commands and environments, it is time to look at how we can reuse this code in several different documents. The basis of reusability in LaTeX is handled through packages, otherwise known as .sty-files. A copious amount of packages exist for LaTeX at CTAN, and we have seen several of them already: tikz, graphicx, fontenc, mathdesign, and many others. Common to each package is that it provides a number of commands and environments that gives you some form of functionality. Tikz allows us to create vector-based drawings directly from inside LaTeX, graphicx allows us to interface with a number of existing graphics formats, mathdesign provides new math fonts that correspond to a number of free and non-free serif fonts.

So, if you have some form of functionality that you use repeatedly in different projects and would like to abstract it away in a separate package that you can easily use in your other projects, a package is what you are looking for. The basis of creating a package is to pick a filename, say, mypackage.sty (on some systems you may have to keep to the 8.3 filename standard, so it may be prudent to name your packages to fit inside that, but it is not a requirement).

Every package starts with either the first or both of the following lines:

\ProvidesPackage{mypackage}[2006/05/01 version 1.0 by Someone] \NeedsTeXFormat{LaTeX2e}

\ProvidesPackage's name is required to be the same as the file of the package, and \NeedsTeXFormat specifies what document format is required in order to use the package (if it is using functionality specific to a certain format). Here, LaTeX2e is what most of us use when we write documents, but plenty of others exist as well.

Packages can, of course, also depend on other packages, but unlike in the main document, we do not use \usepackage to include these, rather, a separate command, \RequirePackage exist instead that otherwise does the same thing (more or less). So if we were to require some higher level constructs for directing command flow using the ifthen package, we could use the following line of code inside our package:


With some packages it is also possible to pass them options, for instance for the babel package that takes care of renaming various commands to a specific language:


These options dictate that we should load both the british and french modules and that we want to pre-select french (as that is the last option) for the language to write in. Likewise it might be relevant for your package to provide a number of options that can be used to control overall functionality of the package or pre-define certain environments or commands. Declaring a package option is done using the \DeclareOption command. So if we were to declare a theorem option, it might look like this:

\DeclareOption{theorem}{% % code goes here }

And when we subsequently use the package in a document we can write:


All the options aren't executed at the point of declaration though, it requires a separate command, \ProcessOptions that can occur anywhere in the package code (though naturally after the \DeclareOption and before the end of the package). A reason to place it later in the document than immediately after your declared options could be that some options redefine commands that are introduced later on in the package, for instance.

Most of the remaining code in a package is just a collection of introducing new commands and environments. There is one thing that is worthy of notice, though, namely that command names that are internal to packages are typically given a @-sign inside them, as these are not directly available in normal documents, as we have seen before. Inside a package the @-sign behaves as a letter and you do not need to surround all such uses with \makeatletter and \makeatother. Also, remember that commands must be unique, there are no overloading, so try to pick names that don't conflict with other packages. Of course, given the sheer number of packages in existence, this may prove rather difficult.

This is basically all there is to creating packages. The rest is pretty much up to what you need to abstract for kinds of behaviour. Looking back at the code we have seen in this blog, we might, for instance, pick out the layout of a book to package. That way we can reuse this layout at a later time, merely by including a package. And that is, in short, the basic idea of packages.