purism/librem/5r4: make it usuable without an overlay

[Mic92]

In larger installations nixpkgs.overlays adds significant overhead because it's harder to share nixpkgs between different NixOS machines i.e. using nixpkgs.pkgs

Description of changes

Things done

• Tested the changes in your own NixOS Configuration
• Tested the changes end-to-end by using your fork of nixos-hardware and
  importing it via <nixos-hardware> or Flake input

[SuperSandro2000]

Hiding packages in let ins blocks any overlays and you have no way to access the package without reimporting it (if that is possible).

I think you are the only person I know which hacks around overlays like that and we've seen in the past, that silently overwriting any option under nixpkgs. is not that great or straight forward.

[Mic92]

Hiding packages in let ins blocks any overlays and you have no way to access the package without reimporting it (if that is possible).

I think you are the only person I know which hacks around overlays like that and we've seen in the past, that silently overwriting any option under nixpkgs. is not that great or straight forward.

Hiding overlays inside a NixOS is also not great, because you if you use flakes you will always end up with two nixpkgs instances, if you also include packages imported in your flake:

  inputs.nixpkgs.url = "github:foo/nixpkgs";
  
  inputs.some-package-flake.url = "github:Mic92/some-package-flake";
  inputs.some-package-flake.follows = "nixpkgs";

  outputs = { nixpkgs, some-package-flake, ... }: {
    nixosConfigurations.foo = nixpkgs.lib.nixosSystem {
      modules = [
        {
          # This is the second copy of nixpkgs, NixOS creates the other copy with `nixpkgs.overlays`
          # It's also inconsistent because nixpkgs.overlays is applied in one case but not the other.
          environment.systemPackages = [ inputs.some-package-flake.packages.mypackage ];
        }
      ];
    };
  }; 

How do solve that? Also each overlay makes nixpkgs signifantly slower. Here is a micro benchmark:

# ./hello.nix
 with import <nixpkgs> {
   overlays = [];
 };
 hello

And than with 10, 20, 30 overlays:

# ./hello-slow10.nix
with import <nixpkgs> {
  overlays = builtins.map (_:
    (self: super: {
      foo = super.foo.overrideAttrs (oldAttrs: {});
    })) [ 1 2 3 4 5 6 7 8 9 10 ];
};
hello

Here is the benchmark when running with [hyperfine] like this:

taskset -c 0 hyperfine "nix-instantiate ./hello.nix" "nix-instantiate ./hello-slow10.nix" "nix-instantiate ./hello-slow20.nix" "nix-instantiate ./hello-slow30.nix"

Command	Mean [ms]	Relative
nix-instantiate ./hello.nix	228.5 ± 7.8	1.00
nix-instantiate ./hello-slow10.nix	243.9 ± 3.9	1.07 ± 0.04
nix-instantiate ./hello-slow20.nix	253.7 ± 2.8	1.11 ± 0.04
nix-instantiate ./hello-slow30.nix	268.1 ± 6.3	1.17 ± 0.05

[Mic92]

I think you are the only person I know which hacks around overlays like that and we've seen in the past, that silently overwriting any option under nixpkgs. is not that great or straight forward.

Most large scale deployments of NixOS are not so open in the public, but it's certainly a well-known trick to get 30% faster evaluation speeds even if you just have 5 machines.

[Mic92]

@SuperSandro2000 Please check again. Packages are now accessible through NixOS options.

[Mic92]

Linux kernels should be always accessed via config.kernelPackages.kernel, so no need for an overlay here.

[Mic92]

With that the package is no longer hidden.

[SuperSandro2000]

@SuperSandro2000 Please check again. Packages are now accessible through NixOS options.

that looks a lot better. Thanks for taking that time.

[Mic92]

@mergify queue

[mergify]

queue

☑️ GitHub can't merge the pull request for now.

GitHub can't merge the pull request for an unknown reason. You should retry later.

[Mic92]

@mergify rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[Mic92]

@mergify queue

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at a4e2b79