Why does the LaTeX kernel define \usepackage *and* \RequirePackage?

The ubiquitous \usepackage command is used to load packages in the preamble of a document; the command syntax is

\usepackage[<package-option-list>]{<package-list>}[<version>]


Actually, \usepackage is derived from the \RequirePackage command which, according to source2e, section 69.3, may be used in package or class files to load other packages. Contrary to \usepackage, \RequirePackage can also be used in documents before \documentclass or in (LaTeX 2.09) compatibility mode:

\def\documentclass{%
\let\documentclass\@twoclasseserror
\if@compatibility\else\let\usepackage\RequirePackage\fi
\@fileswithoptions\@clsextension}
\@onlypreamble\documentclass


But if \RequirePackage can do everything \usepackage does and more, why the need for two different commands at all? Why doesn't the LaTeX kernel simply define one command (however named) for loading packages?

-
Separation between "commands for class and package writing" and "user commands"? – egreg May 13 '12 at 11:07
@egreg But why in a case where the two commands provide about the same functionality? Why not simply define a user command that may also be used in packages and classes, like \newcommand? – lockstep May 13 '12 at 11:12
@lockstep: Either to prevent normal users from loading packages before the class, or simply some compatibility reason or accidentally during the change from LaTeX2.0 to LaTeX2e. – Martin Scharrer May 13 '12 at 11:29
– Marco Daniel May 13 '12 at 11:42
@MartinScharrer If you provide some details about why it's a good idea to prevent normal users from loading packages before the class, while providing a circumvention for advanced users, I might accept that as answer. – lockstep May 13 '12 at 11:54

The creation of 2e is rather long ago so this is all a bit hazy, but the reasons as I remember them have been the following:

• LaTeX 2.09 had no class/package/option concept. Options to a \documentstyle have been external files with the extension .sty.
• For LaTeX2e we wanted a structured approach for classes/packages and their options.
• This structure was for package and class writers not for users and we decided that we make the commands for this part CamelCase, e.g., \RequirePackage
• This layer contains more commands, for example, \RequirePackageWithOptions which have no quivalent on the user level.

Now the LaTeX2.09 situation was rather a mess at this time, with a good number of incompatible extensions and one of the goal for 2e was to consolidate the situation. For this it was extremely important to the 2e concepts would not be used on top of LaTeX2.09 as that would have resulted in yet another incompatible flavor. Instead LaTeX2e was supposed (and actually did fairly well) allow to run old documents in compatibility mode.

But then, no new features on the document level should be available!

Under the hood LaTeX2e would and should be able to use its new feature nevertheless since old stuff got reimplemented (using the package mechanism, for example) and that should work for packages that have been around for 2.09 as style options.

So the decision was made to only offer LaTeX2e extensions on the user level for documents that started out with \documentclass but prevent them for old document starting with \documentstyle. Therefore \usepackageis not available unless you have a \documentclasscommand and the way to ensure this is to wait until you see one :-). On the other hand, \documenstyle{article} would internally now load the 2e article.cls thus all the class and package commands like \RequirePackage had to be available even then. So the fact that you can load a package before \documentclasswith \RequirePackageis not so much because that was deemed very useful or important (though there are a couple of situations where this is true) but because it had to be available for both compatibility and native mode.

So in summary the two commands exists

• because we wanted a clear separation between class/package designer layer
• and the ability to not offer new functionality in compatibility mode

Of course, neither goal is enforced since nothing prevents a user to use \RequirePackage on an old document starting with \documentstyle. But on the whole it worked well. Class/package commands are something you do not find in user documents (normally) and the decision to not allow new 2e features to be used in compatibility mode has been in my opinion one of the key factors that 2e got adopted fairly soon.

-
I doubt if it is a good idea to separate "user level" and "class designer level". When my preamble got somewhat big, i've decided to move it into a single-use class. Now i am wondering what style of commands to use in my single-use class so that it remains readable for an average user. I think, the document body and the document class are on rather equal rights: like HTML and CSS. – Alexey Oct 3 '13 at 8:23

Since they are \let equal to each other there clearly isn't much difference, but there is the issue of the different naming schemes for document level and package level commands, see

Macro naming best practice?

and making \usepackage an error helped ease people from the LaTeX 2.09 to LaTeX 2e syntax.

Also (hard to remember now) there may have been a point when \usepackage and \RequirePackage were not identical. The package loading scheme was one of the main innovations of 2e and we went through a lot of prototypes:-)

-

As you already pointed out the only difference between \usepackage and \RequirePackage is that \usepackage is initially defined as an error message but then defined as an alias of \RequirePackage.

One explanation for this could be to stop normal users to load packages before the class. This is probably from the LaTeX2.09 time (which I didn't experience myself) where there AFAIK were no classes but only style files, which are now more correctly called packages. People might have had one class-like .sty file and might have simply changed the loading macro to \documentclass without putting it at the beginning of the file. Disallowing the loading of packages before the class would then be an educational measure and prevent a lot of potential issues because of wrong loading order. Changing the LaTeX format is already a lot of work, but handling all such feedback would be a support nightmare. The existence of \RequirePackage then still allows for exceptions.

Other possibilities would be some compatibility reason or that this was caused accidentally during the change from LaTeX2.09 to LaTeX2e. There are also some other macros which apparently were meant to be changed or removed but got stuck once LaTeX2e got frozen. One example is \@empty and \empty, which are also identical.

-
Having two commands always allows for giving them different meanings (for example some consistency check in the case of \RequirePackage that wouldn't be significant for \usepackage at a user's level). – egreg May 13 '12 at 12:40
@egreg: Yes, maybe this was originally indented but not implemented in time for the feature freeze. – Martin Scharrer May 13 '12 at 12:42
About the \@empty and \empty example see also What is the difference between \empty and \@empty? – Martin Scharrer May 13 '12 at 12:42
Not necessarily intended: any class writer can locally modify the meaning of \RequirePackage, which is not a user level command, for instance in order to disable loading some package or other purposes. – egreg May 13 '12 at 12:45
According to Kopka/Daly, Guide to LaTeX, loading "packages" in LaTeX 2.09 was done using the optional argument of \documentstyle, e.g. \documentstyle[12pt,parskip,makeidx]{article}. – lockstep May 13 '12 at 13:15

I would say LaTeX defines \RequirePackage for package writers partly simply to have a consistent syntax compared to other similar package writer commands line \ProvidesClass and \LoadClass. But also because \usepackage is as you are describing yourself not identical to \RequirePackage: package writers are allowed to load packages before \documentclass while the normal user normally shouldn't do it.

-