Will LaTeX3 improve freedom of package ordering and reduce "options clash"?

Question

A prefatory afterthought: you may think this question better asked on the LaTeX3 mailing list, but I believe there may be a more general interest in the rather Byzantine rules for package load order. I only mention LaTeX3 as, perhaps, the most obvious opportunity for fixing this.

---

This is a working MWE; swapping the marked lines makes it fail (options clash):

\documentclass[draft]{memoir}
\usepackage[final]{graphicx}   % <== Swap this one
\usepackage{fontspec}          % <== with this to break it
\usepackage[final]{microtype}
% =================================================
\begin{document}
% =================================================
\mainmatter
For that reason among others,
typography and typographers must honour 
the variety and complexity of human language,
thought and identity, instead of 
homogenizing or hiding it.
% =================================================
\end{document}

Obviously, somewhere in fontspec is loading graphicx (though I couldn't find where).

Although I am fairly happy to live with this kind of minor annoyance, it occurs to me that constraints on the order of loading packages could be one of the factors that might discourage potential TeX adopters.

Do the LaTeX3 team have any views on this? Might it be possible, for example, to suppress option clash checks when using RequirePackage as opposed to usepackage, or provide package writers with a generic means of suppression?

Or is this something that needs to be under the detailed scrutiny of each package writer?

Answer 1

In so far as the top level LaTeX3 code isn't written, I'm sure it will improve "freedom of package ordering", "freedom of speech" and generally move the world towards peace and harmony.

To answer your implied comment about LaTeX2e (the main point of this answer:)

Might it be possible, for example, to suppress option clash checks

It is easy to suppress the checks, even in latex2e (You'd just need to redefine the internal macro \@onefilewithoptions without the check).

The problem is that if you don't check then things can go wrong. If a package has been loaded in (say) pdftex so internally defines all its back end code for that platform, and then another package tries to load it in xetex (or dvips or whatever mode). Then the code that is already loaded won't work for the new call. If you over-write all the definitions by reloading the package with the new options then any use expecting the first version will fail, and in any case, loading a package (if it were enabled) twice typically fails, not least because if you \newcommand the same thing twice, the second one generates an error.

None of these things are insurmountably difficult to work around, but probably not with the current syntax as suppressing the warnings doesn't really help unless you say what you want to happen given the input

 \usepackagep[dvips]{graphics}
 \usepackage[pdftex]{graphics}

As Frank indicated in another answer somewhere, one could conceive of the basic LaTeX3 functionality having different top level interfaces for different contexts. But (I suspect) that for interfaces that stay close to the LaTeX2e syntax, some of these restrictions will remain as if the syntax allows people to shoot themselves (or others) in the foot, you have to have protection in place to guard against that.

Answer 2

In general I would claim that there is no good point in suppressing option clashes by default --- at least not if they indicate incompatible requests. If one load request says behave like "X" and the next one behave like "Y" and the two behaviors are incompatible then this needs to be resolved. And even if they are compatible (i.e., can be used together) it usually wouldn't work if you tried to load the package twice for many reasons, one being that 2e is not build for loading stuff twice (e.g., \newcommand issue) but also that there is now concept for resolving dependencies between "X" and "Y" that are not catered for unless the package knows that you want both options together.

That we didn't got it completely right with 2e is probably true and that the system errs unnecessarily on the side of caution is true as well.

Basically in 2e we just detect option clashes using a simple approach that tests if the new requestion for loading doesn't require "additional" options (if I remember correctly, not checked). So requesting less options works by assuming that this will be fine (which isn't necessarily true either in all situations). This is the reason that the error message suggests that loading options globally might work, or that changing the order of packages normally work.

So I guess there is room for improvement but it would require a better model on how options really interact with each other (which isn't available in 2e, hence the simple set of assumptions).

So speaking about how LaTeX3 should do this: yes it should come with a package loading mechanism that improves the 2e concepts (which in turn improved the 2.09 situation) but none of that level has been designed so this is really hand-waving on my part. But something to add to my answer to help for LaTeX3 as it is a concept that needs thinking about what is conceptually really wanted and necessary.

But coming back to the example in the question above: expl3 currently loads graphics and color under certain circumstances and thus 2e packages that use expl3 have a surprising dependency which is not the way it should be. In my opinion this dependency need to be removed by us going forward.

Answer 3

Both David and Frank have provided good views on this, but there are few points I think are worth covering, both on the LaTeX3 possibilities and the current expl3 use of color and graphicx.

---

On the possibilities for a 'native' LaTeX3 mechanism, there are both technical and conceptual changes that I think we will go for. Frank has outlined some general areas to consider, but it's worth bearing in mind that an area that can cause particular issues is the use of keyval options, which were not part of the LaTeX2e kernel design but are used. It's certain that these will be natively supported by a LaTeX3 kernel, and so something like

\usepackage[draft]{foo}

and

\usepackage[draft=true]{foo}

will be recognised as the same. (Try this in LaTeX2e and see that it fails, as the entire text is compared.)

At the more conceptual level, at least some load order/option issues in LaTeX2e occur due to the way that packages patch commands from other packages, and the way in which user commands are tied to implementation. LaTeX3 kernel code will certainly work much better in this regard, while we're encouraging others to adopt the same approaches.

Finally, the LaTeX3 'plan' is for a much richer kernel than for LaTeX2e. That means that a lot of stuff that is currently loaded from packages will be in the kernel itself or in supported packages (not 100% clear yet!). As a result, many of the current 'high risk' areas should be addressed.

---

On the (current) loading of color and graphicx by expl3, this is ultimately to do with drivers and ensuring that stuff works. To support box transformations (scaling, rotation, etc.) you need support at the driver level, which is provided by graphicx. Loading the color package is slightly more complex as the reason for loading it is to do with 'colour safe' boxes and how these then interact with the galley concepts in l3galley (part of l3experimental).

Now, both of these issues can and perhaps should be addressed in other ways. There are now 'native' drivers available for use with LaTeX3, which support rotations and so on without needing to load graphicx. The limitation here is that at the moment these support only pdfmode (pdfTeX >1.40 or LuaTeX in PDF mode), dvips (pdfTeX >1.40 or LuaTeX in DVI mode) and xdvipdfmx (i.e. XeTeX). Of course, this limited range of backends only shows up if you try to use the driver-dependent parts. For the color side of things, it is possible to simply skip that loading entirely, as the issues only shows up as an issue if people try to use LaTeX2e user-level boxes with l3galley (I think: a while since I tested this).

The biggest single issue here is actually that some people may be relying on us loading the code. We had issues when we dropped calc (for good reasons) as a few other packages had been coded on the assumption it was available.

At the time of writing we are making some other important changes to expl3, so this would be a good time to address this area: one for LaTeX-L I think.