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.

  • 2
    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 07: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 07: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? –  Jun 29 '16 at 07:56
  • so the answer seems to be yes, if you are using the standard package loader, but as with any latex macro if you load a package that redefines the internals, then the answer depends on that package..... – David Carlisle Jun 29 '16 at 07:58
  • @DavidCarlisle As package author I need something I can rely on, "it depends" does not help me... It's easy to write a package which changes internal behaviour and blame other packages afterwards. Is this a bug in catoptions or not? What is the documented behaviour? –  Jun 29 '16 at 08:12
  • how can you rely on anything in a system when any package can redefine any part of the system? I'd say it's less than ideal behaviour but if the package documents what it does then it isn't really a bug as such. The latex core can only document what the core code does and as implemented, if the later call to \usepackage uses a (possibly empty) subset of the options used in the first call, the file is not input again, and no warning is given. – David Carlisle Jun 29 '16 at 08:15
  • 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 08: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 08:26
  • @JosephWright So it's a question about feeling!? I can live with that. My feeling is that writing \RequirePackage{caption} within subcaption is totally fine, and the user has to decide if his feelings are more in sync with my feelings or the feelings of the catoptions package author ;-) When answering issues to users, can I quote this as the official point of view of the LaTeX team? :-D –  Jun 29 '16 at 08:35
  • @DavidCarlisle I see two differences between catoptions and caption regarding patching existing commands: 1. The package loading stuff is elementary for other packages and therefore affecting package authors. 2. There is IMHO no technical reason to change it the way catoptions does. As Joseph has already written: It's just about "feeling", the catoptions author "feels" that this is an option clash which the LaTeX2e team (and I) does "feel" not. –  Jun 29 '16 at 08:49
  • @AxelSommerfeldt: Sorry I hadn't understand that your question is about the order and the way catoptions changes the handling. I personally avoid to use catoptions and other packages of the author. He tries to much to do everything better without caring enough about side-effects on the standard behaviour. – Ulrike Fischer Jun 29 '16 at 10:33

1 Answers1

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.

egreg
  • 1,121,712
  • 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? –  Jun 29 '16 at 08:01
  • @touhami Yes, of course. I'll fix. – egreg Jun 29 '16 at 08: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 08: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
  • @percusse First of all I try to find out if the author of catoptions is wrong or if I am wrong. (I know this isn't easy to answer, but otherwise I would not ask here ;-)) Second, what do I tell the user? The user has a document class which loads caption and catoptions, and the user tries to load subcaption additionally and get an error message (because of \RequirePackage{caption} inside subcaption). I told the user the problem is in catoptions and the catoption author told the user that it's a option clash and his package is only highlighting an existing problem here. :-( –  Jun 29 '16 at 13:37
  • @AxelSommerfeldt I'm just trying to reformulate the question because it sounds very interesting to know. But it seems to me that if you remove the author opinions and put the MWE I think people can chime in with more specific details where exactly catoptions fails to operate. Apparently there is a context for your question and you are pretty capable of TeX hence I think it would be beneficial for all of us if the question is steered towards the experts rather than package loading multiple times detail itself. – percusse Jun 29 '16 at 13:57
  • @AxelSommerfeldt The only existing problem is that the author of catoptions was not able to make his modified version of \usepackage to work as it should. There is no problem in the LaTeX kernel, as it behaves as documented; of course the option parsing could be improved, but certainly not in a way that invalidates existing documents. – egreg Jun 29 '16 at 13:58
  • @AxelSommerfeldt if I wasn't on the latex team I think I'd have no problem in saying catoptions is wrong here. But as I am, I can't really do that unless I can formulate a rule that says what parts of the latex format a package can change, and I don't want to do that. If it was a general package and it changed the package loading for all packages as an accidental side effect, then I'd say it is clearly wrong, but since the first line of the package documentation says it redefines the latex package loading, it's a grey area. – David Carlisle Jun 29 '16 at 14:19
  • @DavidCarlisle I see your dilemma,but on the one hand there is "We consider it good practice,when writing packages and classes,to use LATEX commands as much as possible" and "We recommend strongly that you use them (=\RequirePackage and others),rather than the primitive \input command,for a number of reasons" inside the clsguide,and on the other hand you say I cannot rely on anything because everything of LaTeX could be changed. So either maintaining packages is doomed to fail or I have to rewrite my sty using as much TeX primitives as possible, to minimize problems with other packages!? –  Jun 29 '16 at 16:12
  • Maybe we could agree on "Since this is a documented behavior of catoptions it's not a bug, but since other package authors rely on the documented behavior of basic LaTeX commands it's a bad idea"? –  Jun 29 '16 at 16:23
  • @AxelSommerfeldt Indeed, I talked about a “misfeature”. – egreg Jun 29 '16 at 16:24
  • @AxelSommerfeldt yes :-)... – David Carlisle Jun 29 '16 at 16:29