2

There are so many questions related to "package clash" in this forum, but all of them relate to specific packages (why?). For instance I use more than 50 packages in my document. Even if I would be very diligent and track internal dependencies of which package loads other packages with specific options, I would still run into "triangles", where just loading the packages in the "correct" order is not possible. Therefore, I need to ask:

Is there a general way to resolve "package clash" issue ?

EDIT: I am writing a publication, which requires tables, figures, algorithms, different colors, captions, subcaptions, math symbols, physical units, and many others. In the end I have somewhere around 30 packages (the 50 was according to the line number, but then I realized the actual number of packages is lower).

new_stacker
  • 23
  • 1
    I think the point on the packages is that you want to load explicitly only those you use directly (for example, if pkg foo uses baz, but your document doesn't directly use feaures of baz, then you don't need to load the latter yourself). Of course, this may still not help. – Joseph Wright Jul 21 '20 at 10:56
  • 1
    Packages are developed independently by different people. There is no coordination, and CTAN is rife with bad packages. Odds are most of your packages are from a bad template. Try removing your packages one at a time and see what happens. – John Kormylo Jul 21 '20 at 12:09
  • 1
    @JosephWright If you’re getting package clashes, you often want to do the opposite. If the clash is from you loading a package manually, removing the manual load will fix it, but if two different packages are loading it with different options, you should load it yourself, first, with the correct options. – Davislor Jul 21 '20 at 17:17
  • 1
    Although I can imagine a document that would genuinely need to load fifty packages, which were so incompatible that they give you compile errors just from being loaded together, you almost certainly don’t. Whenever I’ve seen a new user post a preamble like that here, it’s been the result of copying someone else’s template, with a lot of packages they don’t really need. And that’s usually been the cause of their problem. – Davislor Jul 21 '20 at 17:32
  • The best thing is to find what is the problem by building a M(not)WE. – projetmbc Jul 21 '20 at 17:43

3 Answers3

4

The most general solution is

\PassOptionsToPackage[option,more=options]{package}

before loading a package for the first time. This can ensure that it is loaded with every option it needs, even when it is loaded indirectly from another package.

It’s also useful to load a package manually before another package loads it with the wrong options. With a very few exceptions (such as fontenc), the first time a package is loaded determines what options it is loaded with. Once, as a last resort, I’ve even needed to \RequirePackage before loading a \documentclass, but \PassOptionsToPackage is generally much better in this scenario.

Many options, such as languages, can be passed to the \documentclass, which will then pass them to every other package it loads, preventing any option clash for them.

Many packages allow you to change their options with a command after loading. It might be safer for a package to load another package without explicit options, then pass it the options it needs. There are also some packages that pass through options to a package they load, such as how mathtools will accept the options of amsmath.

None of these will work in every single case. Packages might load another package with mutually-exclusive options, or package A might need to be loaded before package B, but after package C, which must be loaded after B.

Davislor
  • 44,045
2

I guess you mean an option clash. Package xcolor is loaded by some package with option svgnames and later with option x11names, e.g.

No, there isn't a way to resolve those issues »in general«.

And package clashes are rare, because the package maintainers try to avoid them. Only 53 questions have the tag option-clash.

If you are loading yourself more than 50 packages, you'd better find out, which ones you really need. Sounds like a bloated template...

Keks Dose
  • 30,892
  • Thanks for fact checking me. Then, may I ask what is the proper way to "build" my own set of packages and control the way they are loaded ? (a tutorial, set of rules, good practice, etc) – new_stacker Jul 21 '20 at 11:01
  • @new_stacker LaTeX needs some study. Get an introduction under your belly. I recommend a KOMA-script class as documentclass. Regarding templates see here: https://tex.stackexchange.com/q/390683/4736 – Keks Dose Jul 21 '20 at 11:06
2

There can clearly be no general solution.

If you load package A that internally uses

\RequirePackage[final]{foo}

and you use another package B that uses

\RequirePackage[draft]{foo}

Then you will get an option clash error and no automatic way to resolve it. You will need to decide if you want final or draft and if you decide final then you may need to not use package B at all if it requires the draft mode.

Note that this requirement is inherent in loading multiple package whether or not you get the option clash error.

If the situation is slightly different and A does

\RequirePackage{foo}

and B does

\RequirePackage[final]{foo}

Then you will get an option clash if you load A then B, which could be "resolved" by changing the package order and loading B then A as the latex code makes a naive assumption that it is OK to ignore a package load request that uses a subset of the options used on the first load. But changing the order avoids the error but now means package A is "unexpectedly" using the foo package with the final option which may or may not work, depending on the specifics of the code.

If you load 50 packages (really???) then you need to be responsible for any interactions, the option clash error is just a minor help in catching some possible problems. Note it is designed to be a help not a problem to be solved. It would have been easier to not implement a check.

David Carlisle
  • 757,742
  • Thanks, this answer well explains the option clash and I am considering to mark it as final answer.

    My misunderstanding comes from the mind set, that packages are libraries, which I load and they provide me with extra commands. I did not know (or havent had a chance to realize), that the options actually control the behavior, not the content that is loaded.

     – new_stacker Jul 21 '20 at 11:00