texlive.withPackages: use mkDerivation (finalAttrs: { ... }) instead of buildEnv

[xworld21]

Description of changes

Refactor texlive.withPackages to use mkDerivation (finalAttrs: { ... }) instead of buildEnv.

The main advantage is having texliveSmall.overrideAttrs { withDocs = true; }, which will allow us to deprecate texlive.combine, at last. Further benefit is that the build follows traditional phases, so one can add custom behaviours by setting the relevant pre/post-hooks.

Cons: I had to vendor a copy of the buildEnv script.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[veprbl]

Any plan to de-duplicate with the buildEnv script?

[xworld21]

Any plan to de-duplicate with the buildEnv script?

Am I allowed to use the one in build-support/build-env? At some point I got the notion that folders should be self contained, but maybe it's just a by-name rule. I wouldn't mind using the same script.

[xworld21]

The last update (which prevents the overrides from affecting the formats) seems to fix the performance regression:

The previous run reported some extra 60s – it might have been a CI fluke, but it got me worried.

[veprbl]

Any plan to de-duplicate with the buildEnv script?

Am I allowed to use the one in build-support/build-env? At some point I got the notion that folders should be self contained, but maybe it's just a by-name rule. I wouldn't mind using the same script.

I think, you are allowed. If we can get the script no by path but via an attribute, that would be better.

[veprbl]

Or, perhaps, converting buildEnv to mkDerivation is an option?

[xworld21]

I think, you are allowed. If we can get the script no by path but via an attribute, that would be better.

I have done so (hacky, because buildEnv is a function, but it's not outrageous).

Or, perhaps, converting buildEnv to mkDerivation is an option?

It may be too distruptive. buildEnv is written on the assumption that there won't be any phases, at best a kind of build phase (just so you can run postBuild). The new buildTeXEnv is split into unpack, configure, build, install and it runs fixup. I'd say they are too different at the moment.

A better solution, at the next round of improvements maybe, is to use buildEnv to create an 'unwrapped' output, and let buildTeXEnv deal only with actual building (formats, bin/ wrappers, ConTeXt cache and the likes).

[xworld21]

@GrahamcOfBorg eval

(Checking if the 30s eval increase is repeatable.)