-
-
Notifications
You must be signed in to change notification settings - Fork 15k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
texlive_latest: init at 2023.20230606 #236382
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just added a few comments while passing by :)
32fcec8
to
4f07992
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How hard would it be to have bin.nix
as before, and an extra bin-latest.nix
with overrides only? Which I believe would be the more nixpkgs-y way of providing two versions.
Alternatively, bin-latest.nix
could be a straight copy of bin.nix
, which would become the new bin.nix
once it becomes frozen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly as before is rather inconvenient as the sources would have to be overridden for every derivation. Just passing in the source as an argument and doing the patches and version-specific hacks via overrides shouldn't be too hard at this time as 2023 mostly just adds hacks over 2022. This might become more inconvenient if parts of hacks have to be removed.
I don't really like either approach. Using overrides makes upgrading less convenient and having a complete copy of the file feels really wasteful. I think just keeping bin.nix
mostly general and put version-specific hacks/patches somewhere else for both versions is better as the upgrade remains just moving a file.
@@ -317,23 +317,29 @@ in (buildEnv { | |||
'' | |||
rm "$out"/bin/*-sys | |||
wrapBin | |||
'' + | |||
'' | |||
+ bin.cleanBrokenLinks + |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Incidental: cleanBrokenLinks
will disappear with the bin container patch. I believe it is already a no-op since we started using texlinks
.)
substitute "$TEXMFDIST"/scripts/context/lua/mtxrun.lua mtxrun.lua \ | ||
--replace 'cache_uuid=osuuid()' 'cache_uuid="e2402e51-133d-4c73-a278-006ea4ed734f"' \ | ||
--replace 'uuid=osuuid(),' 'uuid="242be807-d17e-4792-8e39-aa93326fc871",' | ||
FORCE_SOURCE_DATE=1 TZ= faketime -f '@1980-01-01 00:00:00 x0.001' luatex --luaonly mtxrun.lua --generate | ||
|
||
if [[ -e "$out/bin/luametatex" ]]; then | ||
# we intentionally don't use the scripts.lst-mechanism here since we don't want to strip the suffix or wrap the scripts here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(This should also become unnecessary after the bin container patch.)
pkgs/top-level/all-packages.nix
Outdated
@@ -5003,7 +5005,8 @@ with pkgs; | |||
texFunctions = callPackage ../tools/typesetting/tex/nix pkgs; | |||
|
|||
# TeX Live; see https://nixos.org/nixpkgs/manual/#sec-language-texlive | |||
texlive = recurseIntoAttrs (callPackage ../tools/typesetting/tex/texlive { }); | |||
texlive = recurseIntoAttrs (callPackage ../tools/typesetting/tex/texlive/frozen.nix { }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Picking up on the above, I believe tradition is to use default.nix
for the stable version (thus default.nix -> make-tex-live.nix
and frozen.nix -> default.nix
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There already are a lot of files here and I feel like this makes it even less obvious where what is as this breaks up the symmetry between the two versions and replaces default.nix
with a mostly empty file just containing version information. How do you feel about the following layout:
├── bin.nix
├── combine.nix
├── generate-fixed-hashes.nix
├── latest
│ ├── default.nix
│ ├── fixed-hashes.nix
│ ├── tlpdb.nix
├── make-texlive.nix
├── make-texlive-packages.nix
├── stable
│ ├── default.nix
│ ├── fixed-hashes.nix
│ ├── tlpdb.nix
├── tl2nix.sed
└── UPGRADING.md
Version specific stuff is put into subdirectories whereas make-texlive.nix
becomes a generic function that builds the texlive(_latest) scope. The code that builds the texlive packages (currently tl
in default.nix
) is extracted into a separate file make-texlive-packages
.
The entry points called in all-packages.nix
are moved into the subdirectories and call make-texlive.nix
, with the version-specific stuff, possibly applying overrides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@apfelkuchen6 now that the binary containers are in, what do you think of refactoring the packages in texlivePackages
? Presumably with tlpdb.nix
and fixed-hashes.nix
in a separate texlive-packages/
folder, while texlive
keeps the combine machinery in place. The Nix expressions to build the packages should probably stay under texlive
, e.g. texlive.buildPackage
. Priority should be to make the entire thing easy to override, something which is currently very hard.
You have a few pieces here already – shall we start from those? Say with a new 0-rebuild PR?
callPackage ./default.nix { | ||
inherit version tlpdb tlpdbxz fixedHashes urlPrefixes src; | ||
texlive = texlive_latest; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
E.g. could the 2023-specific overrides happen here? Likewise 2022-only patches could be specified in frozen.nix
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's very good. I thought it would be a lot harder.
I like that frozen.nix
and latest.nix
more or less contain the essential information about each specific version. However, the logic is still duplicated around – default.nix
has special code for 2022 and 2023; the urls can be computed once in default.nix
, like before; and similar (see comments).
I suggest we push further, and have a make-tex-live.nix
that takes as input: the version info, the tlpdb.xz hash (just the hash, not the url!), tlpdb.nix, the binary sources, and fixed hashes. Then frozen.nix
calls that function and plugs in whatever overrides are required (e.g. version-specific patches).
4f07992
to
f52763b
Compare
This prepares the use of callPackage (to avoid repeating the parameter names all over the place) and makes static analysis possible
The assertion that all TeX Live packages have a fixed hash is time consuming and should only be checked when running tests.
this is purely a whitespace change that was separated from the previous commit to make the diff easier to read
This generic interface allows the addition of texlive-2023 without repeating too much code or case distinctions TODO: rename default.nix -> generic.nix, stable.nix -> default.nix This will be done later as this makes rebasing a lot harder
70053c0
to
ea56a00
Compare
Description of changes
This is an alternative approach to #222142 suggested by @xworld21 in #222142 (comment): This adds texlive-2023 in addition to the old version instead of replacing it.
I also noticed the following:
texlive.scheme-full.pkgs
is empty since texlive.combine: move dependencies to attribute tlDeps, resolve them … #218331. As this will be resolved/changed by texlive: generate "fixed-hashes.nix" from Nixpkgs attribute #223104 anyway, I haven't bothered with updating the instructions yet.dvisvgm
's pdf conversion feature is incompatible withghostscript >= 10
. We have a test for that, but the test isn't good enough: It just successfully creates an empty svg file. Thedvisvgm
version shipped with texlive-2023 also has amupdf
-backend as a workaround. I'm not sure what to do about the old version.Things done
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)