Lix: mismatch in feature name compared to nix

Development Nix
1

Regarding RFC 148 -

The feature is called "pipe-operators" in nix:

but "pipe-operator" in lix:

This makes it more of a hassle to test differences between, or freely switch between, lix and nix.

CC @jade

5 Likes
2

Both were implemented fairly independently, hence the mismatch. I picked the singular name for the Lix implementation because the RFC always was about ā€œtheā€ pipe operator and it is far from certain that the backwards pipe is going to make it through stabilization.

As a workaround, you can just enable both features, this will have no consequences except CppNix/Lix warning about an unknown experimental features

1 Like
3

Unfortunately, enabling an invalid feature blocks rebuilds, and Iā€™m not exactly keen on disabling nix.checkConfig, since that opens up the possibility of actually making (n/l)ix unusable until I pull out a live image or such.

2 Likes
4

Not only are the names different, but so is the operator precedence. I would not advise using the feature if you are switching back and forth between Nix and CppLix.

4 Likes
5

I donā€™t mix the two in the same expression,so that shouldnā€™t be an issue for me, but thatā€™s a good note.

https://nix.dev/manual/nix/2.24/language/operators.html#operators
https://docs.lix.systems/manual/lix/stable/language/operators.html#operators

1 Like
6

and Iā€™m not exactly keen on disabling nix.checkConfig, since that opens up the possibility of actually making (n/l)ix unusable until I pull out a live image or such.

Hmm, why does checkConfig block on such a harmless thing in the first place?
If itā€™s supposed to be protecting one from messing up nix.conf (which is reasonable), Iā€™d argue that it shouldnā€™t really do that.

3 Likes
7

I agree! I donā€™t think setting an invalid experimental feature should be considered a ā€œbrokenā€ config either, since nix usually just ignores features it doesnā€™t know about

ā€¦and after looking at the nix module to see how checkConfig worked, I just discovered thereā€™s also nix.checkAllErrors which can be set to false to do exactly what I would expect here :sweat_smile:

EDIT: or maybe it does the opposite of what I want? Arguably the real problem is on this line:

1 Like
8

For anyone who likes to live dangerously with the difference precedence, here is the NixOS module I am using to enable Lix on some of my systems. It takes care of the difference in feature name (I have pipes enabled in my default Nix config elsewhere).

9

How does your nixpkgs.overlay not infrec?

For context:

[user@nixos]$ nix-instantiate expr.nix
error: infinite recursion encountered
       at /nix/store/wn3wblni1cm7plb1dvakqcmr31szqdgn-source/pkgs/tools/package-management/lix/default.nix:101:28:
          100|
          101|           nixpkgs-review = nixpkgs-review.override {
             |                            ^
          102|             nix = self.lix;

# expr.nix
let
  overlays = [(final: prev: {
    inherit (prev.lixPackageSets.latest)
      nixpkgs-review
      ;
  })];
  pkgs = import <nixpkgs> { inherit overlays; };
in
  pkgs.nixpkgs-review
10

Not 100% sure. We are stretching my knowledge here, I barely know anything about overlays, I generally try to avoid them when I do have to use them it is normally a mess.

I am using blueprint so maybe that has something to do with it? I wouldnā€™t be surprised if they are just not actually taking effect. That was copied from the Lix docs a few hours ago and I havenā€™t thoroughly tested it.

11

Yeah I suspect itā€™s not applying at all. Accessing pkgs.lixPackageSets should have caused an infrec.