lix-project/lix

Fork 55

nix-serve does not build on unstable, because of missing pkgs.nix.libs.nix-perl-bindings attribute #1007

New issue

Closed

opened 2025-10-10 04:15:42 +00:00 by benaryorg · 4 comments

benaryorg commented

2025-10-10 04:15:42 +00:00

Describe the bug

The following expression fails to build:

# pull in the current (as of time of writing) nixos-unstable
(import (builtins.fetchTree { type = "github"; owner = "NixOS"; repo = "nixpkgs"; rev = "c9b6fb798541223bbb396d287d16f43520250518"; narHash = "sha256-vgPm2xjOmKdZ0xKA6yLXPJpjOtQPHfaZDRtH+47XEBo="; }) {}).callPackage

# build nix-serve with lix as the nix implementation
({ lix, nix-serve }:
  nix-serve.override { nix = lix; }
) {}

full trace

error:
       … while evaluating an expression to select 'drvPath' on it
         at «internal»:1:552:
       … while evaluating strict
         at «internal»:1:552:
       … while calling the 'derivationStrict' builtin
         at «internal»:1:208:
       … while evaluating derivation 'nix-serve-0.2-a7e046d'
         whose name attribute is located at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/stdenv/generic/make-derivation.nix:544:13

       … while evaluating attribute 'installPhase' of derivation 'nix-serve-0.2-a7e046d'
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:32:3:
           31|
           32|   installPhase = ''
             |   ^
           33|     install -Dm0755 nix-serve.psgi $out/libexec/nix-serve/nix-serve.psgi

       … while calling the 'getAttr' builtin
         at «internal»:1:500:
       … while calling the 'derivationStrict' builtin
         at «internal»:1:208:
       … while evaluating derivation 'perl-5.40.0-env'
         whose name attribute is located at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/stdenv/generic/make-derivation.nix:544:13

       … while evaluating attribute 'passAsFile' of derivation 'perl-5.40.0-env'
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/trivial-builders/default.nix:81:9:
           80|         inherit buildCommand name;
           81|         passAsFile = [ "buildCommand" ] ++ (derivationArgs.passAsFile or [ ]);
             |         ^
           82|       }

       … while evaluating the attribute 'passAsFile'
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:9:
          112|         # XXX: The size is somewhat arbitrary
          113|         passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ];
             |         ^
          114|       }

       … while calling the 'lessThan' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:52:
          112|         # XXX: The size is somewhat arbitrary
          113|         passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ];
             |                                                    ^
          114|       }

       … while calling the 'stringLength' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:25:
          112|         # XXX: The size is somewhat arbitrary
          113|         passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ];
             |                         ^
          114|       }

       … while calling the 'toJSON' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:108:16:
          107|           ;
          108|         pkgs = builtins.toJSON chosenOutputs;
             |                ^
          109|         extraPathsFrom = lib.optional includeClosures (writeClosure pathsForClosure);

       … while calling the 'map' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:67:21:
           66|   let
           67|     chosenOutputs = map (drv: {
             |                     ^
           68|       paths =

       … from call site
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/development/interpreters/perl/wrapper.nix:18:15:
           17|     let
           18|       paths = requiredPerlModules (extraLibs ++ [ perl ]);
             |               ^
           19|     in

       … while calling 'requiredPerlModules'
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:45:5:
           44|   requiredPerlModules =
           45|     drvs:
             |     ^
           46|     let

       … while calling the 'foldl'' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:49:5:
           48|     in
           49|     lib.unique ([ perl ] ++ modules ++ lib.concatLists (lib.catAttrs "requiredPerlModules" modules));
             |     ^
           50|

       … while evaluating modules
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:49:29:
           48|     in
           49|     lib.unique ([ perl ] ++ modules ++ lib.concatLists (lib.catAttrs "requiredPerlModules" modules));
             |                             ^
           50|

       … while calling the 'filter' builtin
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:47:17:
           46|     let
           47|       modules = lib.filter hasPerlModule drvs;
             |                 ^
           48|     in

       … while calling 'hasPerlModule'
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:42:19:
           41|   # Check whether a derivation provides a perl module.
           42|   hasPerlModule = drv: drv ? perlModule;
             |                   ^
           43|

       … while evaluating drv
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:42:24:
           41|   # Check whether a derivation provides a perl module.
           42|   hasPerlModule = drv: drv ? perlModule;
             |                        ^
           43|

       … while evaluating an expression to select 'nix-perl-bindings' on it
         at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:15:22:
           14|   sha256 = "sha256-6ZQ0OLijq6UtOtUqRdFC19+helhU0Av6MvGCZf6XmcQ=";
           15|   inherit (nix.libs) nix-perl-bindings;
             |                      ^
           16| in

       error: attribute 'libs' missing
       at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:15:16:
           14|   sha256 = "sha256-6ZQ0OLijq6UtOtUqRdFC19+helhU0Av6MvGCZf6XmcQ=";
           15|   inherit (nix.libs) nix-perl-bindings;
             |                ^
           16| in

This happens in my much more convoluted infra repo too and over there I'm using the lix main and the module (5e2412ea7e and lix-project/nixos-module@3f09a5eb77 respectively), so with it yielding the exact same error I'm reasonably sure that this is a build failure due to a nixpkgs change which looks like the fix needs to be implemented in lix (though I've 100% lost track of the intricacies of the entangled web of packages).

Steps To Reproduce

one-liner

nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import (builtins.fetchTree { type = "github"; owner = "NixOS"; repo = "nixpkgs"; rev = "c9b6fb798541223bbb396d287d16f43520250518"; narHash = "sha256-vgPm2xjOmKdZ0xKA6yLXPJpjOtQPHfaZDRtH+47XEBo="; }) {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix; }) {}'

Expected behavior

nix-serve should be able to build with Lix.

This is especially true since lixPackageSets.latest.nix-serve-ng is currently marked broken in nixos-unstable.

`nix --version` output

nix (Lix, like Nix) 2.94.0-dev-52ef118
System type: x86_64-linux
Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux
Features: gc, signed-caches
System configuration file: /etc/nix/nix.conf
User configuration files: /home/benaryorg/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/benaryorg/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/benaryorg/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/benaryorg/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf
Store directory: /nix/store
State directory: /nix/var/nix
Data directory: /nix/store/fwk3a6j8flnlv8lj9a3ar44n3bl78lhg-lix-2.94.0-dev-52ef118/share

Additional context

This isn't especially urgent for me at least, and nixos-unstable is, well, unstable.
However with November and thus 25.11 around the corner, this web of dependencies is probably better dealt with earlier than later.

Related older issue which had pretty much the same problem:

#971

And please let this issue not be a duplicate for a change, I promise I tried to search the issues 🙃

## Describe the bug The following expression fails to build: ```nix # pull in the current (as of time of writing) nixos-unstable (import (builtins.fetchTree { type = "github"; owner = "NixOS"; repo = "nixpkgs"; rev = "c9b6fb798541223bbb396d287d16f43520250518"; narHash = "sha256-vgPm2xjOmKdZ0xKA6yLXPJpjOtQPHfaZDRtH+47XEBo="; }) {}).callPackage # build nix-serve with lix as the nix implementation ({ lix, nix-serve }: nix-serve.override { nix = lix; } ) {} ``` <details><summary>full trace</summary> ```text error: … while evaluating an expression to select 'drvPath' on it at «internal»:1:552: … while evaluating strict at «internal»:1:552: … while calling the 'derivationStrict' builtin at «internal»:1:208: … while evaluating derivation 'nix-serve-0.2-a7e046d' whose name attribute is located at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/stdenv/generic/make-derivation.nix:544:13 … while evaluating attribute 'installPhase' of derivation 'nix-serve-0.2-a7e046d' at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:32:3: 31| 32| installPhase = '' | ^ 33| install -Dm0755 nix-serve.psgi $out/libexec/nix-serve/nix-serve.psgi … while calling the 'getAttr' builtin at «internal»:1:500: … while calling the 'derivationStrict' builtin at «internal»:1:208: … while evaluating derivation 'perl-5.40.0-env' whose name attribute is located at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/stdenv/generic/make-derivation.nix:544:13 … while evaluating attribute 'passAsFile' of derivation 'perl-5.40.0-env' at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/trivial-builders/default.nix:81:9: 80| inherit buildCommand name; 81| passAsFile = [ "buildCommand" ] ++ (derivationArgs.passAsFile or [ ]); | ^ 82| } … while evaluating the attribute 'passAsFile' at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:9: 112| # XXX: The size is somewhat arbitrary 113| passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ]; | ^ 114| } … while calling the 'lessThan' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:52: 112| # XXX: The size is somewhat arbitrary 113| passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ]; | ^ 114| } … while calling the 'stringLength' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:113:25: 112| # XXX: The size is somewhat arbitrary 113| passAsFile = if builtins.stringLength pkgs >= 128 * 1024 then [ "pkgs" ] else [ ]; | ^ 114| } … while calling the 'toJSON' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:108:16: 107| ; 108| pkgs = builtins.toJSON chosenOutputs; | ^ 109| extraPathsFrom = lib.optional includeClosures (writeClosure pathsForClosure); … while calling the 'map' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/build-support/buildenv/default.nix:67:21: 66| let 67| chosenOutputs = map (drv: { | ^ 68| paths = … from call site at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/development/interpreters/perl/wrapper.nix:18:15: 17| let 18| paths = requiredPerlModules (extraLibs ++ [ perl ]); | ^ 19| in … while calling 'requiredPerlModules' at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:45:5: 44| requiredPerlModules = 45| drvs: | ^ 46| let … while calling the 'foldl'' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:49:5: 48| in 49| lib.unique ([ perl ] ++ modules ++ lib.concatLists (lib.catAttrs "requiredPerlModules" modules)); | ^ 50| … while evaluating modules at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:49:29: 48| in 49| lib.unique ([ perl ] ++ modules ++ lib.concatLists (lib.catAttrs "requiredPerlModules" modules)); | ^ 50| … while calling the 'filter' builtin at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:47:17: 46| let 47| modules = lib.filter hasPerlModule drvs; | ^ 48| in … while calling 'hasPerlModule' at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:42:19: 41| # Check whether a derivation provides a perl module. 42| hasPerlModule = drv: drv ? perlModule; | ^ 43| … while evaluating drv at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/top-level/perl-packages.nix:42:24: 41| # Check whether a derivation provides a perl module. 42| hasPerlModule = drv: drv ? perlModule; | ^ 43| … while evaluating an expression to select 'nix-perl-bindings' on it at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:15:22: 14| sha256 = "sha256-6ZQ0OLijq6UtOtUqRdFC19+helhU0Av6MvGCZf6XmcQ="; 15| inherit (nix.libs) nix-perl-bindings; | ^ 16| in error: attribute 'libs' missing at /nix/store/npsan903n6s1f30nrip3fvqkmx8fxwgg-source/pkgs/by-name/ni/nix-serve/package.nix:15:16: 14| sha256 = "sha256-6ZQ0OLijq6UtOtUqRdFC19+helhU0Av6MvGCZf6XmcQ="; 15| inherit (nix.libs) nix-perl-bindings; | ^ 16| in ``` </details> This happens in my much more convoluted infra repo too and over there I'm using the lix *main* and the module (5e2412ea7e3a8725355a07bed1f3cccc5506edcf and https://git.lix.systems/lix-project/nixos-module/commit/3f09a5eb772e02d98bb8878ab687d5b721f00d16 respectively), so with it yielding the exact same error I'm reasonably sure that this is a build failure due to a *nixpkgs* change which looks like the fix needs to be implemented in lix (though I've 100% lost track of the intricacies of the entangled web of packages). ## Steps To Reproduce <details><summary>one-liner</summary> ```bash nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import (builtins.fetchTree { type = "github"; owner = "NixOS"; repo = "nixpkgs"; rev = "c9b6fb798541223bbb396d287d16f43520250518"; narHash = "sha256-vgPm2xjOmKdZ0xKA6yLXPJpjOtQPHfaZDRtH+47XEBo="; }) {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix; }) {}' ``` </details> ## Expected behavior *nix-serve* should be able to build with Lix. This is especially true since *lixPackageSets.latest.nix-serve-ng* is currently marked broken in *nixos-unstable*. ## `nix --version` output ```text nix (Lix, like Nix) 2.94.0-dev-52ef118 System type: x86_64-linux Additional system types: i686-linux, x86_64-v1-linux, x86_64-v2-linux, x86_64-v3-linux Features: gc, signed-caches System configuration file: /etc/nix/nix.conf User configuration files: /home/benaryorg/.config/nix/nix.conf:/etc/xdg/nix/nix.conf:/home/benaryorg/.nix-profile/etc/xdg/nix/nix.conf:/nix/profile/etc/xdg/nix/nix.conf:/home/benaryorg/.local/state/nix/profile/etc/xdg/nix/nix.conf:/etc/profiles/per-user/benaryorg/etc/xdg/nix/nix.conf:/nix/var/nix/profiles/default/etc/xdg/nix/nix.conf:/run/current-system/sw/etc/xdg/nix/nix.conf Store directory: /nix/store State directory: /nix/var/nix Data directory: /nix/store/fwk3a6j8flnlv8lj9a3ar44n3bl78lhg-lix-2.94.0-dev-52ef118/share ``` ## Additional context This isn't especially urgent for me at least, and *nixos-unstable* is, well, unstable. However with November and thus 25.11 around the corner, this web of dependencies is probably better dealt with earlier than later. Related older issue which had pretty much the same problem: - #971 And please let this issue not be a duplicate for a change, I promise I tried to search the issues 🙃

benaryorg added the

bug

label

2025-10-10 04:15:42 +00:00

jade commented

2025-10-10 15:25:46 +00:00

Owner

You can run an older version of nix-serve against the lix perl bindings if you'd like.

I think the rust nix cache thing has a fork with lix support.

As a general rule, neither the perl nor the c++ apis of lix have any stability guarantees at all and there will never be a goal that our internal APIs are compatible with cppnix. Changes can be sent for review and if they have merit, they may be accepted, but compatibility of internal APIs is not considered.

The reason that #971 was closed with "I'm wasting my time here" is that the cppnix people changed the perl api and then updated nix-serve to match so it no longer works on lix. I'm not thinking about the merits of their change; it may have been good, but I'm not going to go change our perl apis around to support legacy software with known superior alternatives. You can run an older version of nix-serve against the lix perl bindings if you'd like. I think the rust nix cache thing has a fork with lix support. As a general rule, neither the perl nor the c++ apis of lix have any stability guarantees at all and there will *never* be a goal that our internal APIs are compatible with cppnix. Changes can be sent for review and if they have merit, they may be accepted, but compatibility of internal APIs is not considered.

👍 1

jade

2025-10-10 15:25:46 +00:00

closed this issue
added the
Status
wontfix
label

benaryorg commented

2025-10-10 19:02:04 +00:00

Author

I have no issue with the won't fix here, and I personally think the reason is more than justified.
However this isn't about changed APIs, rather than the location of the passthru attr has been changed starting with CppNix 2.26.

Instead of exposing lix.perl-bindings software like nix-serve now expects lix.libs.nix-perl-bindings.

more one-liners

Running this against nixpkgs with the Lix overlay (meaning that Lix actually has lix.perl-bindings, which is not merged upstream, as per the below link) fails with the trace as per the OP:

nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import ./. {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix; }) {}'

Only moving the bindings to the new passthru path builds:

nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import ./. {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix // { libs.nix-perl-bindings = lix.perl-bindings; }; }) {}'

I just found the nixpkgs PR for getting the former into nixpkgs, however this attribute is also exposed by Lix when pulled in as a flake, the overlay, or the module, so to fix compatibility with nixos-unstable (or rather anything post-CppNix-2.25) the path would need changing in this repo too (unless that one's set in the module, I'm not sure).
That is unless Lix wants to carry forward the diverging passthru attr, which I guess is fine, though it'll push the change down into the packaging of individual packages using the bindings (and potentially other libs) even if those packages themselves are written to be compatible with either.

If you disagree with that assessment, feel free to close the issue again, I only reopened it based on the assumption that it was closed because it looked like an actual API change.

Edit: more infos including references to the commits in nixpkgs changing this are found in the linked PR

I have no issue with the *won't fix* here, and I personally think the reason is more than justified. However this isn't about changed APIs, rather than the location of the *passthru* attr has been changed starting with CppNix 2.26. Instead of exposing *lix.perl-bindings* software like *nix-serve* now expects *lix.libs.nix-perl-bindings*. <details><summary>more one-liners</summary> Running this against nixpkgs with the Lix overlay (meaning that Lix actually has *lix.perl-bindings*, which is not merged upstream, as per the below link) fails with the trace as per the OP: ```bash nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import ./. {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix; }) {}' ``` Only moving the bindings to the new passthru path builds: ```bash nom build --no-link --print-out-paths --print-build-logs --impure --expr '(import ./. {}).callPackage ({ lix, nix-serve }: nix-serve.override { nix = lix // { libs.nix-perl-bindings = lix.perl-bindings; }; }) {}' ``` </details> I just found [the nixpkgs PR for getting the former into nixpkgs](https://github.com/NixOS/nixpkgs/pull/435681#issuecomment-3391840940), however this attribute is also exposed by Lix when pulled in as a flake, the overlay, or the module, so to fix compatibility with *nixos-unstable* (or rather anything post-CppNix-2.25) the path would need changing in this repo too (unless that one's set in the module, I'm not sure). That is unless Lix wants to carry forward the diverging *passthru* attr, which I guess is fine, though it'll push the change down into the packaging of individual packages using the bindings (and potentially other libs) even if those packages themselves are written to be compatible with either. If you disagree with that assessment, feel free to close the issue again, I only reopened it based on the assumption that it was closed because it looked like an actual API change. *Edit*: more infos including references to the commits in nixpkgs changing this are found in the linked PR

benaryorg reopened this issue

2025-10-10 19:02:04 +00:00

benaryorg commented

2025-10-10 19:23:45 +00:00

Author

Okay, 20 minutes later and two attempts at writing an overlay and deploying software later I come to the conclusion that I'll just close this issue since nix-serve-ng somehow works with all the Lix overlays and modules stacked on top, and the bindings are largely irrelevant anyway since Hydra will probably move to the Lix repo eventually.

The upstream implications are discussed in the nixpkgs PR.

Okay, 20 minutes later and two attempts at writing an overlay and deploying software later I come to the conclusion that I'll just close this issue since *nix-serve-ng* somehow works with all the Lix overlays and modules stacked on top, and the bindings are largely irrelevant anyway since [Hydra will probably move to the Lix repo eventually](https://git.lix.systems/lix-project/hydra/issues/56). The upstream implications are discussed in the nixpkgs PR.

benaryorg closed this issue

2025-10-10 19:23:46 +00:00

jade commented

2025-10-11 02:42:25 +00:00

Owner

lix.libs.nix-perl-bindings

hm. that's not really sensical for us to use as a name because we will not have any other libs in that set because the stuff cppnix did to their derivation to overcomplicate it is not something we're planning to copy. maybe we could have an alias, but the thing is that having the nix level stuff be api compatible is kind of pointless if once you actually build it, it blows up at runtime immediately because the perl api is incompatible as well.

i think strategically we don't want to be chasing cppnix and having api compatibility at a Nix level isn't really useful because we need different versions of the software that link against lix to deal with the c++/perl api differences, which ought to have their own derivations because cppnix is off doing their own thing to their package and nix api which we don't want to chase either.

> lix.libs.nix-perl-bindings hm. that's not really sensical for us to use as a name because we will not *have* any other libs in that set because the stuff cppnix did to their derivation to overcomplicate it is not something we're planning to copy. maybe we could have an alias, but the thing is that having the nix level stuff be api compatible is kind of pointless if once you actually build it, it blows up at runtime immediately because the perl api is incompatible as well. i think strategically we don't want to be chasing cppnix and having api compatibility at a Nix level isn't really useful because we need different versions of the software that link against lix to deal with the c++/perl api differences, which ought to have their own derivations because cppnix is off doing their own thing to their package and nix api which we don't want to chase either.