Evaluating twice?

Help
1

Hello, I decided to try out unstable on my main machine for a bit. When I do nh os switch I get a load of evaluation warnings (which I sort of expected and should be able to fix, though I’m not sure where I’m pulling in the xorg stuff) but what struck me was that they appear twice:

evaluation warning: The xorg package set has been deprecated, 'xorg.libXi' has been renamed to 'libxi'
evaluation warning: The xorg package set has been deprecated, 'xorg.libXrender' has been renamed to 'libxrender'
evaluation warning: The xorg package set has been deprecated, 'xorg.xcbutilimage' has been renamed to 'libxcb-image'
evaluation warning: The xorg package set has been deprecated, 'xorg.xcbutilrenderutil' has been renamed to 'libxcb-render-util'
evaluation warning: The option `documentation.man.generateCaches' defined in `/nix/store/4x5yrjxmjkhz9xndmyi1i24w84ag6nv1-source/modules/sw/fish.nix' has been renamed to `documentation.man.cache.enable'.
evaluation warning: The xorg package set has been deprecated, 'xorg.libXi' has been renamed to 'libxi'
evaluation warning: The xorg package set has been deprecated, 'xorg.libXrender' has been renamed to 'libxrender'
evaluation warning: The xorg package set has been deprecated, 'xorg.xcbutilimage' has been renamed to 'libxcb-image'
evaluation warning: The xorg package set has been deprecated, 'xorg.xcbutilrenderutil' has been renamed to 'libxcb-render-util'
evaluation warning: The option `documentation.man.generateCaches' defined in `/nix/store/4x5yrjxmjkhz9xndmyi1i24w84ag6nv1-source/modules/sw/fish.nix' has been renamed to `documentation.man.cache.enable'.

Is Nix supposed to be evaluated twice? I get really slow evaluation times in general, and this sort of lines up with what I’ve seen in profiling before (Profiling/optimising NixOS Configuration Derivation - #8 by peterc-s).

If it isn’t meant to be evaluated twice, what could cause it? If it is, I’m curious as to why.

2 Likes
2

You may have multiple nixpkgs evaluations in your config and you should probably fix that.

3

Okay so not intended then. How can I find what is causing the nixpkgs evaluations?

4

You’ll want to check if you import nixpkgs anywhere, or if any code that you depend on does. Same with nixpkgs.legacyPackages.

1 Like
5

I assume this includes within flakes that are in my inputs too? Because my config does not have import nixpkgs or use nixpkgs.legacyPackages anywhere (at least with a quick rg check).

6

Yes those are all code that nix looks at.

7

I think I might know my problem then. Have a few flakes that I’ve written out of necessity with little regard for evaluation speed. If both import nixpkgs and nixpkgs.legacyPackages are bad for eval time, what should I use instead? I know legacyPackages is better, but is there a better way?

For example, I have the following flake because I need to patch a packages dependencies (awful, but works):

{
  description = "Typst - patched with newer hayagriva";

  inputs = {
    nixpkgs.url = "https://channels.nixos.org/nixpkgs-unstable/nixexprs.tar.xz";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = {
    self,
    nixpkgs,
    flake-utils,
    ...
  }:
    flake-utils.lib.eachDefaultSystem (
      system: let
        pkgs = nixpkgs.legacyPackages.${system};
        patchedTypst = pkgs.typst.overrideAttrs (old: {
          patches = [./hayagriva.patch];
          cargoDeps = old.cargoDeps.overrideAttrs (old: {
            vendorStaging = old.vendorStaging.overrideAttrs {
              patches = [./hayagriva.patch];
              outputHash = "sha256-5yOkNmnNJt/gLzU7Pwn751vzOxj0f6lriKj+NnUa1t4=";
            };
          });
        });
      in {
        packages.patched-typst = patchedTypst;
        defaultPackage = patchedTypst;
      }
    );
}

Is there a better (in terms of eval time) way of doing this?

8

Check your flake.lock for multiple instances of nixpkgs and use follows in your flake inputs to all make them point to the main nixpkgs.

9

I already do that and have confirmed I only have one instance of nixpkgs.

10

Either overlays or manually using pkgs.callPackage where pkgs is the nixpkgs instance from the module system. I should probably do a full writeup on these soon…

11

I’m not sure how to use that exactly (and noogle doesn’t have documentation or example usage: pkgs.callPackage - Nix function reference). Could you point me to something that uses pkgs.callPackage to do something similar?

12

It really depends on whatever other code is being called though, it difficult to tell without a full-on example (including how you’re using it in your NixOS config).

1 Like
13

Ah, didn’t think to check nix.dev lol. Will have a look when I have time, thank you!

14

Did you manage to figure out where the deprecation warning was coming from? Update: nvm it was the zen-browser flake I was using.

15

For me, it’s the binary ninja flake I use. Glad you figured yours out though :slight_smile:

1 Like