# Convention for packages that modify commands of other packages

I want to write a package that modify a command of another package. Let's say for example the command is \includegraphics from the graphicx package so in mynewpack.sty file I have something like that:

\let\latex@includegraphics\includegraphics
\renewcommand\includegraphics[2][]{<some tex code> \latex@includegraphics[#1]{#2}}


If in my main.tex file I have this

\usepackage{graphicx}
\usepackage{mynewpack}


all goes fine, graphicx defines \includegraphics command and mynewpack redefines it.

But if the loading of these two packages is switched then I don't understand what happen. I expect an error because into mynewpack.sty I use includegraphics when the graphicx package is not yet loaded. Instead no error is produced but the inclusion of mynewpack has no effects (I think it is because it is loaded before graphicx and graphicx restores includegraphics to the default one).

Why I don't get the error I expect in this situation?

How can I fix this problem? My idea is of loading the graphicx package directly from the mynewpack one but then I don't know what happens if the also the user add the graphicx package inside the main.tex. Another possibility is using some command inside mynewpack.sty that delays the redefinition of includegraphics until all other packages are loaded but I don't know if this command exist...

-
I would place \usepackage{graphicx} in your style file, and have users not place it in their main document (though it shouldn't hurt things, in general). It will also guarantee that it is pre-loaded, regardless of whether the user also puts it in his file or not. If your package deals solely with modifications to an existing package (also called customization), I would sometimes name my style, using your example, Redgraphicx.sty or something that clues the user into its purpose. –  Steven B. Segletes Oct 10 at 14:42
There's no error when you say \let\foo=\baz and \baz is not defined. This justs leaves \foo in the same undefined status as \baz. You should \RequirePackage{graphicx} before starting to modify its macros. –  egreg Oct 10 at 14:43
To back up what Steven says, if you put \usepackage{graphicx} (or the equivalent but semantically better \RequirePackage{graphicx} then you guarantee that graphicx is loaded before your package and it doesn't matter if a user puts \usepackage{graphicx} in their preamble or not, or where they put it. –  Andrew Stacey Oct 10 at 14:43
But if I use \RequirePackage{graphicx} inside my .sty file and a user put \usepackage{graphicx} AFTER the \usepackage{mynewpack} this does not overwrite the includegraphics command restoring it to the original definition? –  Red Oct 10 at 14:50
@Red No, the LaTeX package loading system only loads packages once. (OK, there are a few that side-step this, but that is very rare.) –  Joseph Wright Oct 10 at 14:52
show 7 more comments

Let's say that in your package you have

\let\latex@includegraphics\includegraphics
\newcommand\variant@includegraphics[2][]{<code>\latex@includegraphics[#1]{#2}


and then, under some conditions, you say

\let\includegraphics\variant@includegraphics


(for instance as the “begin” part of an environment).

If graphicx is loaded before your package, you'll have no problem; otherwise, \includegraphics will not be defined at the moment the first \let is executed, leaving \latex@includegraphics undefined.

When graphicx is loaded after your package, a call to \includegraphics when not under the scope of your second \let. But inside that scope, you'll get an error when TeX will try to expand \latex@includegraphics which is undefined. If you don't, then check whether another package you load defines \latex@includegraphics).

So, whenever you want to modify a command's behavior (without changing its main syntax, the possibilities are adding a *-variant or an optional argument if not included in the original syntax), you need to ensure the command is defined at the moment you \let a new control sequence to it. Therefore you should say

\RequirePackage{graphicx}


so it will be immaterial whether the end user loads it before or after your package. There may be problems if a user loads graphicx with options, so you should tell in your package's documentation that graphicx is required, so it should be loaded in advance if options need to be passed to it.

Actually, the situation with \includegraphics is rather complicated. Some packages do modify it, in particular some TikZ related ones. Then it's best to use \LetLtxMacro instead of \let. However, this would break if somebody uses the * variant (rare usage, but possible), so you must tell in the documentation that the * variant is not supported and that the clip option must be specified instead.

-