LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Joseph Wright <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Thu, 23 Jul 2020 10:19:24 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (84 lines)
On 23/07/2020 03:00, Henri Menke wrote:
> Dear list,
>
> Inspired by issue #900 on the PGF/TikZ repo [1], I'd like to kick off
> the discussion on how to correctly integrate the new hook management
> system into existing LaTeX package codebases.
>
> In a naïve adaptation, two code branches would be maintained, with and
> without the new hook management. This is quite tedious for maintainers,
> especially when trying to integrate this properly into existing CI.
>
> For me as PGF/TikZ maintainer it is also of paramount importance to
> avoid anything similar to the oberdiek-split and iftex-merge
> clusterfucks. Back then I had to fix the CI every other day without any
> guidance whatsoever from upstream, which was a massive sink of my time.
>
> Obviously there has to be some transition at some point. Hence I'm
> asking how to properly integrate and coordinate the migration this time.
>
> Kind regards,
> Henri
>
> [1] https://github.com/pgf-tikz/pgf/issues/900

Hello Henri,

First, an paragraph aside about the oberdiek split and iftex merge
changes. Both of those were mainly issues in TeX Live packaging, which
is separate from the case here, which is about the macro layer. As such,
the impact of the earlier changes was mainly felt by package authors
using CI set-ups. There are a couple of ways of setting up a CI: you can
have a frozen set of packages (libraries) available, or you can update
to see 'what your users get'. Like me, you've gone for the latter: there
are advantages to both, but updating does leave you at the mercy of
third-party changes. One could I guess set up parallel tests to 'focus
in' on where the issues come from, but that is likely overkill here.
(The number of packages to track is sufficiently small to know where
things come from.)

On the matter in hand, all that is needed is to test for the new
mechanism being available, and to use it when it is. That is potentially
as simple as

     \@ifundefined{AddToHook}
       {
          % Old code
       }
       {\AddToHook{...}{...}}

if you are using LaTeX, or for code that must work format-neutral

     \long\def\@firstoftwo#1#2{#1}
     \long\def\@secondoftwo#1#2{#2}
     \ifx\AddToHook\undefined
       \expandafter\@firstoftwo
     \else
       \expandafter\@secondoftwo
     \fi
       {
         % Old code
       }
       {\AddToHook{...}{...}}

(I'll cover the possible targets for \AddToHook in a separate email, as
it goes with the tex4ht mail in this thread). I've used the \@firstoftwo
approach here as I'm allowing for the 'old code' containing unbalanced
conditionals.

One might of course define the hook 'payload' in a macro and do
something like

     \protected\def\my@hook@payload{...}
     \@ifundefined{AddToHook}
       {
         \g@addto@macro\document{\my@hook@payload}%
       }
       {\AddToHook{begindocument/end}{\my@hook@payload}}

I've already adjusted beamer in light of the above need, see
https://github.com/josephwright/beamer/commit/877c44cc5fd32ef0736fbe66f88a53995c8e1850:
beamer used to mess with \document, not with \shipout.

Joseph

ATOM RSS1 RSS2