4

I am trying to emulate LaTeX 2020-10-01 on a system still using LaTeX 2020-02-02 PL 5. I have downloaded the latest version of latexrelease.sty from GitHub. However, the following MWE fails:

\RequirePackage[2020/10/01]{latexrelease}
\documentclass{article}

\begin{document}

Test.

\end{document}

I get:

! Undefined control sequence.
l.1911 \NewDocumentCommand
                           \NewHook             { m }{ \hook_new:n {#1} }
? 

What am I doing wrong?

  • 3
    Your input is correct and it should work. Marking all latexrelease tags in the source code is hard and we've obviously got something wrong along the way. Could you please report an issue at https://github.com/latex3/latex2e/issues? – Phelype Oleinik Nov 24 '20 at 16:00
  • It's interesting to find a user in the 'real world' using the roll-forward possibility: it might be useful to outline your set up (purely for informing development, not directly for fixing the issue). – Joseph Wright Nov 24 '20 at 16:02
  • Note that roll forward can help in simple cases but in general things can not work well, for example for this release one or two packages updated to work better with the new format but if you have an old distribution and just roll forward the base latex, you end up with an untested situation with new format code but all the packages in your installation are still old. If it helps in some cases of sharing documents with newer installations it is good but if it fails it is not totally unexpected . (although this failure is with one of our own packages, xparse so we can fix that) – David Carlisle Nov 24 '20 at 16:16
  • @PhelypeOleinik I opened an issue at GitHub. – user227621 Nov 24 '20 at 16:37
  • @user227621 Thanks. I've done some digging meanwhile and this one is going to be especially tricky because it relies on code added to expl3 this year, so in a TL 2019 system (which I assume is what you have) that is not defined. As David says, roll forward is tricky – Phelype Oleinik Nov 24 '20 at 16:43
  • @PhelypeOleinik No, MiKTeX 20.7. See the log file I posted at GitHub. – user227621 Nov 24 '20 at 16:45
  • @user227621 Oh, right, I didn't see it... If you don't mind me asking though, why not just update LaTeX then? – Phelype Oleinik Nov 24 '20 at 16:47
  • Not tested but why shouldn't a \RequirePackage{xparse} do the trick in that case? After all the is is mainly the the latexrelease.sty file assumes that xparse is around in the kernel (which is of course wrong if you roll forward). – Frank Mittelbach Nov 24 '20 at 16:49
  • @FrankMittelbach Then I get `! Undefined control sequence. @kernel@after@enddocument

    l.4671 }

    ? ` See my comment I just wrote at GitHub.

    – user227621 Nov 24 '20 at 16:53
  • @PhelypeOleinik and JosephWright The situation is the following: Person A and Person B are working together on a (not so important) document. Person A has LaTeX 2020-10-01 and person B has LaTeX 2020-02-02 PL 5. Furthermore, person B is working on an important document which will be finished soon. Person B will update LaTeX after finishing the important document (but not before finishing it, as the update might affect the important document). – user227621 Nov 24 '20 at 17:23
  • @user227621 In that case, I'd suggest Person A to rollback their document to 2020-02-02 PL 5 instead (rollback has a lot more testing than roll forward). But (sorry for being a nuisance) why can't each of you use a different version? Unless the person with 2020-10-01 is using bleeding-edge new features, the document should work the same way on either version (if it doesn't, what's the problem?) – Phelype Oleinik Nov 24 '20 at 17:31
  • @PhelypeOleinik The document indeed uses new features of LaTeX 2020-10-01. But I don't mind if you decide that such a roll forward is not possible in a reasonable way :). The specific problem can certainly be solved differently. You don't need to rewrite the whole roll back/forward mechanism :). – user227621 Nov 24 '20 at 17:42
  • @user227621 No, it is probably doable with reasonable effort, but it's likely not going to happen so soon (maybe in a couple of weeks, maybe only in the next major release), thus I asked you so we could try to find a work around. Take a look at this workaround: it defines some missing token lists and the missing \file_parse_full_name_apply:nN, so fixing rollforward is likely possible in this case. Meanwhile the workaround may work (not sure how well though). (By the way: it's good to see people using the new features :) – Phelype Oleinik Nov 24 '20 at 18:03
  • @PhelypeOleinik The workaround deosn't work: `! LaTeX3 Error: Control sequence \file_parse_full_name_apply:nN already (LaTeX3) defined.

    For immediate help type H . ...

    l.12 \cs_new:Npn \file_parse_full_name_apply:nN #1 ? `

    – user227621 Nov 25 '20 at 07:54
  • @user227621 Ah, (I guess) you updated expl3 (thus you already have \file_parse_full_name_apply:nN). Try deleting the code chunk between the first \cs_new:Npn until (but not including) the first \ExplSyntaxOff (like this). Note that Frank is already fixing the roll-forward code so it might be released in the next few weeks. – Phelype Oleinik Nov 25 '20 at 10:59
  • 1
    @user227621 I have a corrected latexrelease.sty more or less ready and will post it soon. – Frank Mittelbach Nov 25 '20 at 11:26

1 Answers1

5

As mentioned in the comments the main reason for latexrelease is being able to roll back. Roll forward is much harder to manage (and to test) and given that we now offer development release which are ahead of the official release less needed.

Having said this, the current latexrelease was/is simply buggy when it comes to rolling forward. For one it had the code in a different order than it is in the kernel (which doesn't matter much when rolling back but matters a lot when rolling forward). And there have been a number of other issues that I found when trying to do roll forward using earlier TeXLive releases as a starting point.

I think I have fixed all of them but I only tested from yearly releases as it is rather difficult to build a release from say 2020-02-02 just for testing. So fingers crossed but you may want to check out if the following file works for you:

https://pastebin.com/raw/sZFgEwMr

pastebin told me it is perhaps offensive content :-) (probably because the word latex appears a lot?) but it should be just the package code.

Update

I should note that rolling forward using latexrelease is obviously only rolling forward the kernel files (as these are the only ones that can be patched this way). While rolling back can also be done for package, that is obviously not possible when rolling forward, because the package from 2019 can't know what changes it needs in 2020. For the kernel that also only works by getting a new LaTeX release from 2020 and using that to patch a 2019 kernel.

So concerning the comment below: amsmath is still on 2019 version and that version used \newcommand for \negmedspace and this breaks because patching the kernel to 2020 defines that command already in the kernel.

Possible solutions: either update amsmath to 2020 or try

\RequirePackage[2020/10/01]{latexrelease}

\AddToHook{package/before/amsmath}{% \let\negmedspace\relax \let\negthickspace\relax }

Explanation: after using latexrelease the new hook management scheme is available so we can state that just before loading amsmath it should undefine the problem commands.

But not that this only works because the change here is trivial. If more had changed in amsmath that need updating it really would get out of hand.

  • The MWE works. But if I add \usepackage{amsmath}, I get `! LaTeX Error: Command \negmedspace already defined. Or name \end... illegal, see p.192 of the manual.

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

    l.169 ...egmedspace}{\tmspace-\medmuskip{.2222em}}

    ? `.

    – user227621 Nov 25 '20 at 13:51
  • @user227621 you are seriously testing out the roll forward ... that was a bug we actually introduced and thought that it was fixed, obviously not in the rollback/forward code. I'll check. – Frank Mittelbach Nov 25 '20 at 14:18
  • @user227621 see my updated post – Frank Mittelbach Nov 25 '20 at 16:32
  • Thanks! Using amsmath now also works, although I see that this is not a general approach. Indeed, one should be aware of the limitations of rolling forward. – user227621 Nov 25 '20 at 19:29