Package request: ConTeXt LMTX

[colin-heffernan]

Project description ConTeXt is a macro system for TeX, similar to LaTeX. While it is packaged within TeXLive, it also maintains its own distribution which is more actively updated.

Metadata

• homepage URL: https://contextgarden.net/
• source URL: https://github.com/contextgarden/context
• license: gpl2
• platforms: linux

[akho]

I think the ConTeXt Suite is deprecated in favor of ConTeXt LMTX.

[colin-heffernan]

Oh, I thought LMTX was a part of the Suite. I can revise the issue later.

[apfelkuchen6]

Since ConTeXt LMTX is completely independent of the rest of the tex ecosystem -- luametatex doesn't even use kpathsea -- packaging ConTeXt LMTX (without MkII/MkIV support?) on its own definitely makes sense.

This would allow other options for the texlive 2023 upgrade (ConTeXt in texlive-2023 is kind of weird; the texlive binary distribution uses lmtx, but the source tarball does not contain luametatex sources, so #222142 currently adds luametatex separately, of which I'm not particularlay fond of):

• use the luametatex binary which is maintained as part of a new ConTeXt package (in a separate output or derivation) for the context in texlive. This would mean that we might use a different version of luametatex in texlive as the texlive binary distribution, but since the luametatex interfaces are considered stable since version 2.10, this should not cause any issues.
• drop ConTeXt LMTX from texlive and have context and mtxrun use luatex as was done in texlive-2022. I believe that arch linux is taking this approach. Since ConTeXt LMTX will still be available with the new package, this should be acceptable.

I'd love to hear the thoughts of @xworld21 and @veprbl on this.

[apfelkuchen6]

When packaging this, there probably also should be an easy way to add external packages (primarily from texlive). For example, tikz can absolutely be used with ConTeXT, but is not contained in the ConTeXt distribution. Upcoming changes to texlive (#218331) should be kept in mind to avoid making things more difficult.

[xworld21]

There is partial support for integrating arbitrary binary packages with TeX Live, but it's immature (see mftrace). Since ConTeXt LMTX is using its own database, though, we should probably think about it the other way around: ConTeXt should accept an overridable texmf argument and run mtxrun on it, in some form. (It would be best if ConTeXt only needs share/texmf and not share/texmf-var so that we don't compile the formats.)

Edit: let me clarify that the output of texlive.combine is now split in texmf, doc, and the final output. If ConTeXt needs it, we can expose texmf (say as a fake split output).

[apfelkuchen6]

Edit: let me clarify that the output of texlive.combine is now split in texmf, doc, and the final output. If ConTeXt needs it, we can expose texmf (say as a fake split output).

needing is a strong word, but it would be incredibly easy to consume on the ConTeXt side, so I'd love that. But then pkgs.context.override { extraModules = [ pkgs.texlive.combined-scheme-full.texmf-dist ]; } would probably still build all the formats, only to discard them. So keeping a "take dependency closure and combine"-function separate from the combine-function that also builds the formats and mktexlsrs accessible in the texlive scope might be even better for the ConTeXt side when the "take dependency closure"-behaviour is removed from the .pkgs attributes of the packages in texlive.

[xworld21]

But then pkgs.context.override { extraModules = [ pkgs.texlive.combined-scheme-full.texmf-dist ]; } would probably still build all the formats, only to discard them.

It wouldn't actually, that's the exciting part of the recent patch that was merged. The intended texlive.combined.scheme-full.tex (or .texmf) is its own derivation, and it only builds ls-R, which is cheap. It's just that right now .texmf is not exposed, but my plan is to make it visible. I'll get there eventually. Modernising texlive is quite the mountain to climb.

[apfelkuchen6]

It wouldn't actually, that's the exciting part of the recent patch that was merged. The intended texlive.combined.scheme-full.tex (or .texmf) is its own derivation, and it only builds ls-R, which is cheap. It's just that right now .texmf is not exposed, but my plan is to make it visible. I'll get there eventually. Modernising texlive is quite the mountain to climb.

nix can't build only a single output of a derivation, but it's possible to expose texmf as a passthru-attribute (which for the consumer looks like outputs anyway).

Great! I can't wait :]

[colin-heffernan]

I just realized that pkgs.texliveConTeXt exists. Is this ConTeXt LMTX, or something else?

[xworld21]

I just realized that pkgs.texliveConTeXt exists. Is this ConTeXt LMTX, or something else?

Yes and no. Since TeX Live 2023 (which will presumably enter Nixpkgs in a week or two), ConTeXt distributed by TeX Live is based LuaMetaTeX.

However the request is about having a separate ConTeXt package which tracks upstream releases. That makes sense to have, and the new TeX Live infrastructure is more amenable to exporting a package tree.

By the way the TL2023 update contains a new texlive.bin.context, so adding an upstream ConTeXt is a matter of copying (or overriding) existing code.

TL;DR this request should remain open, but it's also quite doable especially after TL2023 gets merged.