I recently made some extension to an old document of mine, and it stopped compiling. Luckily I am aware of the package ordering issue, especially with the notorious hyperref package. However, I am not aware of a way to systematically find the correct order of the packages besides trial and error. Is there a systematic way to determine the correct package loading order besides trial and error?

For example, when I use both the feyn and the nicematrix package, then the order does not matter. However, if I additionally load the amsmath package first, then I need to load the nicematrix package before the feyn package. I did not find anything in the documentation of either package regarding the loading order :-(

Example for anyone to try:

\usepackage{nicematrix}   % should come before the feyn package
 & 1 & 2 \\
3 & a & b \\
4 & c & d
\Diagram{\vertexlabel^a \\
fd \\
& g\vertexlabel_{\mu,c} \\
\vertexlabel_b fu\\
= ig\gamma_\mu (T^c)_{ab}

2 Answers 2


There can be no general rule here and nothing you can expect to find in the individual package documenation, if package A sets \foo=1 and packageB sets \foo=2 then the load order depends on whether you want \foo to be 1 or 2, or if packageA requires \foo to be 1 and packageB requires it to be 2 then the packages are incompatible and can't be loaded together unless you patch one of them to use a different name.

There are thousands of packages on ctan, individual packages may test against the main core packages such as amsmath but will not in general test against all combinations of contributed packages.

In recent latex releases we have added the hook mechanism that allows you to hook in to package loading and control the order in which hooks are run independent of package loading order. This can address some issues here but the general issue is not solvable.

However the case you give here is documented by thefeyn package. That package somewhat bravely makes ! active so it will be incompatible with lots of things, however it provides an option not to do that. If you use


there is no error.

Package clashes can only be avoided if you report them to the maintainer and they decide to take special action to avoid known issues.

here feynwould be better to use


rather than

\def!{\char`\!}               % ! produces this character everywhere

to define its "normal" !as \char`\! only produces a !in typesetting contexts, eg try \typeout{hello!}

Similarly nicematrixcould (probably) locally ensure the catcode of known active punctuation characters and so defend itself against packages that make characters active already in the preamble. (Although really it shouldn't have to do that.)

  • Wooaaa, thanks for explaining things. So when I load amsmath later, it also works. For the documentation, I was searching for order and compatibility, but did not find anything with these keywords. I understand that packages can redefine stuff and this would be difficult to catch, but I was hoping that there would be a tool that parses the tex file, reads all the usepackage and the prints out which ones define the same commands. That would be very handy.
    – laolux
    Commented Mar 2, 2022 at 8:12
  • 3
    @laolux it is not possible to parse tex without executing it, and here they don't even define the same commands, they just use the same character ! The feynpackage is potentially incompatible with every package and every document that uses a ! character anywhere. Commented Mar 2, 2022 at 8:14

There are about 5000 packages out there on CTAN and while not all of them are for LaTeX the majority is. As David wrote in his answer there are 4 possibles relationships between packages A and B:

  • they are independent
  • they are incompatible (because they overwrite each other in some way)
  • A must be loaded before B (A<B)
  • B must be loaded before A

Unfortunately even that is an oversimplification because if A<B and A and C are independent or A<C one would expect that loading A,B,C should work. However that might not be the case if B alters some code of A in order to allow both packages to work with each other and that change might end up being incompatible with C.

As also mentioned by David, the hook management introduced should eventually help in many cases, because most of the incompatibilities are due to package A and B not knowing about each other both extend/alter some internal LaTeX command and without knowing about each other overwrite the modification made by the other. With the hook mangement in use they could both make their alterations and even rules in which order they are to bee carried out can be defined. This doesn't solve all problems (like changing catcodes of characters) but it would help in many cases.

Having said this, the small problem is that it requires packages to use the hook mechanism instead of doing the unconditional overwrites. WE are strongly lobbying for that and as long as packages still have active maintainers we see an increase of hook usage and by "hookifying" more of LaTeX's internals we expect that trend to continue.

However, it will not solve any such problem, e.g., incompatible packages may be incompatible forever, whether or not they are using hooks.

Nevertheless I wonder if it could be a huge help (or not) if there would be a volunteer project that that sets up a database of relationships between packages (perhaps one that allows users (in a moderated fashion) to contribute). So a db could be more or less a simple file like

A, B, <,  version-A, version-B, date checked   % A must be before B
A, C, X,  version-A, version-C, date checked   % A and C are incompatible

There could then be a (latex) package that constructs a dependency try and does or suggests an ordering.

And with a bit of further thoughts this could be take into account the version/date in one way or the other.

There should (and probably could) be a way to verify dependency checking automatically most if not all the time.

Just a thought. I think it could be a great service for the community if something like this would become available but I guess it wouldn't be easy to make it work smoothly and well. In fact, if I remember correctly, there is or was an attempt by some developer to do something like this on his or her own. I guess that package is still on ctan, but I've forgotten what the name was.

  • 2
    Maybe said package was ctan.org/pkg/pkgloader?
    – cgnieder
    Commented Mar 8, 2022 at 21:49
  • @cgnieder right, that one. Commented Mar 9, 2022 at 10:40
  • Concrete examples of how packages authors should use the hook mechanism (instead of doing the unconditional overwrites) would be very welcome. Commented Mar 11, 2022 at 9:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .