lix: package nix-eval-jobs

[9999years]

This adds packaging for the Lix fork of nix-eval-jobs.

lixVersions.lix_2_91 has been renamed to lixPackageSets.lix_2_91.lix.

The elements of lixPackageSets are proper scopes instead of single packages. This makes it easy to build nix-eval-jobs against the correct version of Lix.

TODO:

• Should the attribute be called nix-eval-jobs or lix-eval-jobs?
• Should the overridden dependencies be part of the scope as well, or should I keep those hidden like they were previously?

$ nix repl --file .
nix-repl> lixPackageSets.lix_2_91
{
  Security = «derivation /nix/store/ivj0dwr2g18gf3bci9xva6g8qfan59ya-Security-11.0.drv»;
  aws-sdk-cpp = «derivation /nix/store/cds59fiybckyg0d4ls5a4l5afp2y1q1c-aws-sdk-cpp-1.11.448.drv»;
  boehmgc = «derivation /nix/store/r6i08v2sj1gkxf1nwq79sm6qfc96qlbs-boehm-gc-8.2.8.drv»;
  callPackage = «lambda callPackageWith @ /Users/wiggles/nixpkgs/lixos-module/lib/customisation.nix:240:15»;
  confDir = "/etc";
  lix = «derivation /nix/store/1mmy5wyr8fmprc52f9xkgrvn3qm7wfs3-lix-2.91.1.drv»;
  newScope = «lambda newScope @ /Users/wiggles/nixpkgs/lixos-module/lib/customisation.nix:609:20»;
  nix-eval-jobs = «derivation /nix/store/ka5lm9g1ylbzznzrdfkyadgkjxvhvjvv-nix-eval-jobs-2.91.0.drv»;
  overrideScope = «lambda overrideScope @ /Users/wiggles/nixpkgs/lixos-module/lib/customisation.nix:611:25»;
  packages = «lambda @ /Users/wiggles/nixpkgs/lixos-module/pkgs/tools/package-management/lix/default.nix:22:29»;
  stateDir = "/nix/var";
  storeDir = "/nix/store";
}

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 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.

[9999years]

This wasn't used, is it needed for anything?

[9999years]

Open question: What should the structure of the attribute set be?

Previous

This is what it previously looked like:

lixPackages
  lix_2_90
    lix
    nix-eval-jobs
  lix_2_91
    ...
  latest
  stable

Pros:

• All versions clearly listed in one attribute set

Cons:

• Kinda clumsy to access different versions, it's weird that lixPackages.lix_2_90 isn't actually Lix and you need lixPackages.lix_2_90.lix for that

LLVM-style

We could have it be like LLVM or the Linux kernel:

lixPackages_2_90
  lix
  nix-eval-jobs
lixPackages_2_91
  ...
lixPackages_latest

Pros:

• All versions accessible at top-level
• lixPackages_2_90.lix is a pretty clear name

Cons:

• No single place to access all the versions. The kernel has linuxKernel.packages, but there's not really a good corresponding name for Lix. LLVM doesn't export any such attribute; there's llvmPackagesSet but it's not exported.

Compromise-ish

This is the new structure I went with:

lixPackageSets
  "2.90"
    lix
    nix-eval-jobs
  "2.91"
  stable
  latest
lixPackages_2_90
  lix
  nix-eval-jobs
lixPackages_stable
...

Pros:

• All versions accessible at top level
• All versions accessible in one place under lixPackageSets
• lixPackages_2_90.lix is a good name

Cons:

• Versions under lixPackageSets have attr names that start with digits, so you need to quote them to access them: lixPackageSets."2.90"
• Attr names under lixPackageSets don't match attr names under pkgs, so the aliases need to be maintained manually: lixPackages_2_90 = lixPackageSets."2.90"
• This also makes the logic to set up the lixVersions alias a bit complex, although we'll only pay that cost for a few months

Compromise-ish 2

Having top-level aliases is seen as clumsy and leading to bad code, particularly with LLVM and kernel package sets. Here's the new new structure:

lixPackageSets
  lix_2_90
    lix
    nix-eval-jobs
  lix_2_91
  stable
  latest

Pros:

• All versions accessible in one place under lixPackageSets
• No quoted attr names

Cons:

• lixPackageSets.lix_2_90.lix makes you type lix three times, which sucks

[lf-]

oh gods. that's a special argument to mkDerivation that looks like it is supposed to land in drvAttrs but actually doesn't? that's some evil API design in mkDerivation.

[lf-]

https://github.com/nixos/nixpkgs/blob/05c1f927c632bf443a03dc6313e8f2915cc91078/pkgs/stdenv/generic/make-derivation.nix#L537-L542 yeah. huh. TIL. neat.

[9999years]

tbh i assumed you wrote it from the comment but it appears to be a @RaitoBezarius special from #310194

[lf-]

um. great question. i dont know. probably because it was introduced due to nix 2.3?

[lf-]

lol we didn't tag these huh. the canonical source for the version that shipped with a given lix is then the nixos module (which is PROBABLY just the branch tip of release-*). clown shoes on our part. you or i should tag these upstream.

[lf-]

okay im just going to do it, it will take 5 mins.

[lf-]

2.91.1 and 2.90.0 and 2.92.0 tags now exist.

[lf-]

approved pending doing a quick QA to make sure it doesn't blow up the module

[lf-]

Passes my brief QA so should be good to go.