References: <20170731.162337.688577912214660894.wl@gnu.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0)
            Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Message-ID:  <63285c18-e1f1-11b7-8876-dab4c8ea661a@latex-project.org>
Date:         Tue, 1 Aug 2017 16:37:29 +0200
Reply-To:     Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender:       Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From:         Frank Mittelbach <frank.mittelbach@LATEX-PROJECT.ORG>
Subject: Re: \usepackage problem with LaTeX 3
To:           LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <20170731.162337.688577912214660894.wl@gnu.org>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Content-Transfer-Encoding: 8bit
Status: R

Hi Werner

> 
> [Not sure whether this is a generic LaTeX 3 problem or specific to
>   `fontspec' – however, I guess this question is of greater importance,
>   thus writing to this list.]

I think it is neither but rather a general issue with TeX code, but as 
you say it is important


the issue is that you can't execute code twice that is not meant to be 
executed twice. So if you clone some code that contains such material 
and you execute both the original and the new code (clone) you get 
errors, either subtle ones or simple ones like "not allowed"

examples are from plain TeX things like \newwif from 2e stuff like 
\newcommand and in l3 anything _new:... typically checks like 
\newcommand if that is actually defining a free name

so running any such code twice gives you error messages and if it is 
because of a newcommand then it will look like a 2e error and if it is 
necause if \newif like a plain TeX error and if it happens to be due to 
an expl3 construct like

\bool_new:N

then surprise :-) an L3 style error

but effectively they all say the same:

    you asked me to generate something new but I see this is already there


The way packages guard against this problem is simply by making sure 
that \usepackage or \RequirePackage will execute the external code only 
once. This means you can't load a package with different option sets 
(and we know that causes sometimes grief too) but on the whole that 
works fairly well.

Of course it doesn't work if two different packages define the same 
constructs and both use \newcommand or something similar

then the second package will bomb and if you change the order of loading 
the other one will.

And normally this is a Good Thing (TM) as it signals that something 
incompatible is happening

Now with the cloned code under a new name the situation is like that 
only here package A is supposed to be replaced by package A-clone

So one way to achieve that is as Will pointed out to tell the world that 
once package A-clone was loaded package A was loaded too.

And the mechanism for this is fairly simple: the loader looks in

    \csname ver@<filename>\endcsname

and if that is \relax the it loads the file.
Otherwise it expects that this holds the "version" or rather the date of 
the file (there are some macros dealing with different actions depending 
on package dates).

So with

  \def\ver@fontenc.sty{2016/01/01}

you would claim that that package from that date was now loaded. Thus 
libertine would not try to load it again.

It is in fact enough to make it anything other than \relax the date is 
only useful if downstream there is any code that goes "do something 
special if fontspec is older than X"

Maybe we should have a declaration

\ThisCodeReplacesPackage{foo}{date}

for the above but we don't (yet)

Note that all this is only necessary if it is likely that package A is 
used inside other packages; with most packages that isn't really the 
case so that variants may coexist nicely even if they can never be 
loaded both (guess caption caption2/3/whathaveyou would be examples of this)

-----------------

what else could you do?

depending on how much change/extension there is you could simply write a 
package

\usepackage{fontspec-extended-WL}

and have the latter do

  - require fontspec  % now it is definitely loaded
  - check if we are on xetex
  - if so update the xetex related code as needed
  - if not do nothing or complain that this is really for xetex and 
otherwise not needed

I don't really see the need to clone fontspec and fontspec-xetex 
especially given that fontspec does so little and you aren't really 
changing it.


cheers
frank