17

In

Loading package twice with \RequirePackage causes "option clash"

and

Loading a package more than once

we see that a package can be loaded multiple times, as long as no options or no different options are given.

However, my question is not if this actually works, or if it is implemented in LaTeX this way (well, obviously it is), but if this is a documented behaviour.

This is what I've found in the clsguide about it:

"If a package is always loaded with \RequirePackage... or \usepackage then, even if its loading is requested several times, it will be loaded only once."

While this is a clear indication for me that loading a package several times is ok, the author of the catoptions has a different opinion:

"You first loaded xcolor with option cmyk and later without any option. That leads to an option clash that LaTeX can't catch. The catoptions package highlights it." (Source: catoptions causes option clash with xcolor )

Any more hints from the LaTeX2e documentation regarding this issue?

Example documents which show the problem:

\documentclass{article}
\usepackage{catoptions}
\usepackage[labelfont=bf]{caption}
\usepackage{subcaption}
\begin{document}
Test
\end{document}
\documentclass{article}
\usepackage{catoptions}
\usepackage[balancingshow]{multicol}
\usepackage{doc}
\begin{document}
Test
\end{document}
\documentclass{article}
\usepackage{catoptions}
\usepackage[demo]{graphicx}
\usepackage{rotating}
\begin{document}
Test
\end{document}

All these examples compile fine without using catoptions, but fail when using it.

  • 1
    If you load a package with options and then reload it with no option, nothing happens; it's an error to do the converse or to load the package twice with different sets of options. – egreg Jun 29 '16 at 7:27
  • I'm not sure I understand. Your quote from catoptions is about loading with different options. This naturally doesn't work. So where do you see a "different opinion"? – Ulrike Fischer Jun 29 '16 at 7:29
  • @UlrikeFischer xcolor was loaded with options "cmyk" first and then loaded again without options. As long as you don't load the catoptions package additionally this works fine, so I don't see why your opinion is "This naturally doesn't work". It works, but is this indended? – Axel Sommerfeldt Jun 29 '16 at 7:56
  • 1
    @AxelSommerfeldt This is clearly a deliberate decision of the design of catoptions: it's author feels that \usepackage[foo]{bar}\usepackage{bar} is an option clash. In contrast, the kernel team decided that this was not a clash. Both positions have points in their favour. – Joseph Wright Jun 29 '16 at 8:23
  • 1
    @AxelSommerfeldt I don't see how "changing package loading from the documented behaviour (and documenting the new behaviour)" is any different in principle from "changing \caption from the documented behaviour (and documenting the new behaviour)" That is one of the strengths of latex, that it can be extended. It is also one of its weaknesses, that extensions can interfere with each other. I think catoptions would be better not to do this, but I wouldn't call it a bug if it does. – David Carlisle Jun 29 '16 at 8:26
12

Experiment 1:

\documentclass{article}
\usepackage[cmyk]{xcolor}
\usepackage{xcolor}
\begin{document}
a
\end{document}

Terminal output:

This is pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016) (preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
(./exp.tex
LaTeX2e <2016/03/31> patch level 2
Babel <3.9r> and hyphenation patterns for 83 language(s) loaded.
(/usr/local/texlive/2016/texmf-dist/tex/latex/base/article.cls
Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
(/usr/local/texlive/2016/texmf-dist/tex/latex/base/size10.clo))
(/usr/local/texlive/2016/texmf-dist/tex/latex/xcolor/xcolor.sty
(/usr/local/texlive/2016/texmf-dist/tex/latex/graphics-cfg/color.cfg)
(/usr/local/texlive/2016/texmf-dist/tex/latex/pdftex-def/pdftex.def
(/usr/local/texlive/2016/texmf-dist/tex/generic/oberdiek/infwarerr.sty)
(/usr/local/texlive/2016/texmf-dist/tex/generic/oberdiek/ltxcmds.sty)))
No file exp.aux.
(/usr/local/texlive/2016/texmf-dist/tex/context/base/mkii/supp-pdf.mkii
[Loading MPS to PDF converter (version 2006.09.02).]
) [1{/usr/local/texlive/2016/texmf-var/fonts/map/pdftex/updmap/pdftex.map}]
(./exp.aux) )</usr/local/texlive/2016/texmf-dist/fonts/type1/public/amsfonts/cm
/cmr10.pfb>
Output written on exp.pdf (1 page, 9748 bytes).
Transcript written on exp.log.

Experiment 2:

\documentclass{article}
\usepackage[cmyk]{xcolor}
\usepackage[cmyk]{xcolor}
\begin{document}
a
\end{document}

Same terminal output.

Experiment 3:

\documentclass{article}
\usepackage{xcolor}
\usepackage[cmyk]{xcolor}
\begin{document}
a
\end{document}

Error:

! LaTeX Error: Option clash for package xcolor.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                              

Experiment 4:

\documentclass{article}
\usepackage{catoptions}
\usepackage[cmyk]{xcolor}
\usepackage{xcolor}
\begin{document}
a
\end{document}

Error as in experiment 3.

Comments

The catoptions package changes the definition of \@fileswith@ptions, which is internally used by \usepackage (and \RequirePackage).

Without it, the statement in the manual about package loading is true: loading a package with different sets of options raises an error, unless the second (or further) call is with a subset of the original set of options (for example no option) in the first call.

  • I know the outcome, that's not what I have asked about. Let's focus on Experiment 4: Is this a bug in catoptions (which should be fixed) or is catoptions merely highlighting a problem here? – Axel Sommerfeldt Jun 29 '16 at 8:01
  • @touhami Yes, of course. I'll fix. – egreg Jun 29 '16 at 8:19
  • 2
    @AxelSommerfeldt It's a misfeature of catoptions, yes: it changes the behavior of \usepackage making illegal what should be legal. And, no, there is no problem to be highlighted, except that catoptions should be modified. – egreg Jun 29 '16 at 8:21
  • 1
    I think @AxelSommerfeldt is asking what exactly the bad idea in the catoptions is and whether there is a way to signal the user about multiple calls to the his own package – percusse Jun 29 '16 at 11:25
  • @percusse catoptions.sty is quite complex. It fails in doing the right thing, where it does is the author's business. – egreg Jun 29 '16 at 12:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.