I mentioned in texlive.withPackages: add withDocs, withSources and expose texliveFullWithDocs at top level by xworld21 · Pull Request #497867 · NixOS/nixpkgs · GitHub that I’d like to deprecate texlive.combine. I wanted to do that for quite some time, but I had to drop nixpkgs work for a while. Now I believe the above PR is the last missing piece to make texlive.withPackages a fully functional replacement. E.g. you can now override single packages relatively easily (just pass a new package with the same pname), you can add docs (the new .withDocs attribute), and… that’s it, really. (Full disclosure: by ‘fully functional’ I don’t mean you can replicate texlive.combine completely, because .combine allows for some really weird stuff, but I don’t think that kind of power is required. I don’t believe any other lang2nix has anything comparable to .combine.)
How do I go about it? First of all, are there any objections to removing texlive.combine?
Second question is about planning. I suppose the sensible strategy is to add a deprecation warning soon after 26.05 is out, then remove texlive.combine after the 26.11 release. Is that reasonable?
PS: this is a good moment as any to ask around if there are TeX Live users that would feel confident reviewing TeX Live PRs. I have already started pestering @chrjabs because he had the unfortunate idea of submitting some TeX Live PRs… are there other volunteers? Next thing I want to add (if I can find the time) is texliveUnstable so we can track TeX Live 2026 while the default texlive remains frozen at TL2025.
While I used to be involved in this looong ago, I haven’t really used *TeX for many years now and I’m not a suitable reviewer (too busy with other stuff, too).
From my side I can say that I’m willing to be more involved with maintaining TeXLive going forward, however, I’m still too new to TeXLive packaging and Nixpkgs overall to be a suitable (only) reviewer for bigger changes, I think.
Does texliveUnstable mean basically a few conditions in the expression and yet another generated list of source URLs? I often (although not always) might be convinced to review and merge logically simple (of which I might hav e a weird definition) changes within a single-digit number of days.
Apparently I have stopped using anything cursed in my TeXLive package set…
Thanks everybody, I started some easy PRs now to prepare the ground for texliveUnstable. Still in the dark on how to generate a tlpdb-unstable.nix that contains only the differences with tlpdb.nix (which includes somehow removing packages). tlpdb.nix is >2MB as it is, I most definitely do not want to add a duplicate…
Uhm, if I have to evaluate Nix, I might as well generate the diff from with Nix directly. I don’t love the idea of calling nix-instantiate within a derivation, but it is probably the only robust solution.
Alternatively, we switch from tlpdb.nix to tlpdb.json. Wouldn’t JSON be faster to parse as well?
I mainly wanted to describe a pipeline where diff is already available, and includes the list of deletions. Not 100% sure if JSON will be faster to parse from inside Nix: one still needs to create the Nix AST, and possibly (I haven’t looked at the code) the entire JSON AST.
@xworld21 Is there any way I can help in preparing for the deprecation of texlive.combine? Would it be helpful if I draw up a PR to get rid of the usages of .combine throughout other packages in nixpkgs?
I’ve been looking into this and have most of it done. However, then I came across pkgs.texFunctions.runLaTeX. Does anyone have some more information about that function, and others in pkgs/tools/typesetting/tex/nix/default.nix?
As far as I can tell, most of these functions (all that rely on runLaTeX) are not used anywhere in nixpkgs, except the following:
Why did you make me look – runLaTeX is nasty. I don’t think a script to automatically run latex the correct number of times, launch bibtex, makeindex, etc. should be developed inside Nixpkgs. TeX Live has much better options for that (latexmk being the more obvious one).
On the other hand, there must have been reasons for adding it and there may be users. Fixing it won’t be that bad I hope. I can look into this, and do some git archeology, at some point.
Just FYI, I now have a branch for TeXLive 2026 around. Currently this is just updating the stable texlive packages, which we will not want to do upstream, but in any case, once we get to setting up texliveUnstable, maybe this branch will come in handy, rather than figuring out the necessary fixes from scratch again.
Thanks! There’s an upstream patch missing, published somewhere on the TeX Live mailing lists (this is just a note to make sure we don’t forget – right now I don’t even remember which binary needs the patch). The hilatex issue is a little worrying. As soon as the recent changes hit master, I’ll start texliveUnstable proper and figure out what is going on.