circular dependency when building LaTeX?
phe.h.o1 at gmail.com
Sun Jun 27 00:11:49 CEST 2021
On 6/26/21 18:23, Thiago Jung Bauermann wrote:>
> Generating files during the build process is much preferred to using pre-
> generated ones, because if one wants or needs to modify the software they
> are running, it’s much better to change the source file. Generated files are
> often too cumbersome or unintelligible to be modified. Perhaps that’s not
> the case for the xparse files specifically. I haven’t looked closely.
Yes, having the source is usually preferred, indeed, but as I said
xparse-as-a-package is now frozen, so no changes will be applied to that
code. Instead (most of) that same source was moved to the LaTeX kernel,
and development continues there.
> This isn’t just a theoretical concern. Guix has a mechanism called “package
> transformations”¹ where the user can specify a patch to be applied to the
> package they are installing. Guix strives to make it easy for users to
> modify the software on their systems.
That sounds... dangerous :-)
I have no idea about Guix, so apologies if I'm nonsensing here, but this
mechanism seems (from what I understood) to allow you to select a
specific version of a package, but it rather uncommon that someone wants
to update their xparse alone. Usually LaTeX users update packages when
they have some new feature, and then this new feature requires a newer
xparse, so usually a full upgrade is done, rather than a single package.
But that's going off on a tangent...
>> |xparse-generic.tex| and the |xparse-<date>.sty| you mention are no
>> longer generated from |xparse.ins| because the development version moved
>> to |ltcmd.dtx| in latex-base.
>> Also, the |texlive-2020.1| tag is frozen and doesn't get any more
>> updates. I'd recommend you use the |trunk| version (updated daily),
>> which has the newest LaTeX, that I mentioned.
> Interesting suggestion, thanks. Is trunk considered a stable version of the
> TeX Live distribution that can be relied upon by users?
Depends what you mean by stable. Most regulars in this mailing list use
this version (which is what you get when you install vanilla TeX Live).
Others prefer to distribute older "frozen" versions, to the example of
Overleaf which is usually an year or so behind, but then you get users
trying to upgrade their packages as I mentioned above, and issues begin.
>>> I also see a couple of xparse-<date>.sty. Their headers say that they
>>> were “generated from xparse.dtx […] then adapted”. Does that mean that
>>> they were modified by hand after being generated by docstrip?
>> Exactly (I am the one to blame :-). |xparse-generic.tex| was generated
>> then modified by hand, but I forgot to add a similar note on its header.
> Ok, that makes it unrealistic to try to generate it during the build
> process. I’ll simply copy the versions that are in the CTAN package. As you
> mention, this is a temporary situation that will go away after
> texlive-2021.1, so the impact is limited.
Good. Generating these versions themselves was quite troublesome
because some are required to be loaded on top of the others, so baking a
source to generate them is not really practical. I think these should
not give your version-picking mechanism too much trouble, hopefully :-)
Hope it helps,
More information about the tex-live