A (sad?) state of Nixpkgs

doronbehar · July 21, 2024, 1:23pm

That one is easily override-able:

nautilus = pkgs.nautilus.override {
  gnome-user-share = null;
};

I too support the concept of maintaining such flags, and I try to do my best in some of my own packages were these flags are meaningful in my opinion. However, indeed that can become hard for some packages, so in your case I can only recommend to you to try to fix those issues yourself:).

Also relevant:

github.com/NixOS/nixpkgs

package overrides using a mini module system

NixOS:master ← Atemu:package-overrides-mini-module-system

opened 12:01PM - 17 May 24 UTC

Atemu

+985 -631

## Description of changes  Putting a package's configuration options into function arguments in order to expose them via `override` is a well established pattern but has major issues: - No discoverablilty/documentation of available options - Namespace collisions (calling an option "xorg" would result in callPackage inserting the xorg package set) - Odd syntax and scoping limitations when declaring options (`?` and no ability to use let bindings) - No type checking - No good error messages - No sane way to transparently communicate breaking changes But we have a well-established solution to all those problems: The module system. This is a little thought that came to my mind while thinking about [RFC 169](https://github.com/NixOS/rfcs/pull/169): Why couldn't we just use the module system for configuring packages? The extent to which this is done here is merely the configuration options that were explicitly exposed by the package before which is similar to how modules are used NixOS; explicit options provided by the package maintainer to customise some specific aspect of the package. The only limitation I currently see is that it is a bit awkward to compose multiple overrides: ```Nix # This is fine (mlterm.override { configuration = { gui = { wayland = false; sdl2 = false; }; }; }).override # This requires advanced knowledge of the moule system and overrides (prev: { configuration = { imports = [ prev.configuration ]; gui.sdl2 = true; }; }) ``` This could however be remedied using a dedicated `overrideFeatures` function. As for performance: Edit: Out of date. See below. Previous: ``` [atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 1 -r 30 'nix-instantiate -A ffmpeg' Benchmark 1: nix-instantiate -A ffmpeg Time (mean ± σ): 716.5 ms ± 13.9 ms [User: 430.6 ms, System: 143.5 ms] Range (min … max): 658.7 ms … 738.2 ms 30 runs [atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 10 -r 30 'nix-instantiate -A mlterm' Benchmark 1: nix-instantiate -A mlterm Time (mean ± σ): 739.5 ms ± 33.0 ms [User: 445.2 ms, System: 151.8 ms] Range (min … max): 688.9 ms … 792.6 ms 30 runs ``` With modules: ``` [atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 1 -r 30 'nix-instantiate -A ffmpeg' Benchmark 1: nix-instantiate -A ffmpeg Time (mean ± σ): 712.8 ms ± 21.4 ms [User: 428.8 ms, System: 143.0 ms] Range (min … max): 657.3 ms … 748.0 ms 30 runs [atemu@HEPHAISTOS nixpkgs]$ hyperfine --warmup 10 -r 30 'nix-instantiate -A mlterm' Benchmark 1: nix-instantiate -A mlterm Time (mean ± σ): 740.9 ms ± 35.9 ms [User: 446.8 ms, System: 152.2 ms] Range (min … max): 687.8 ms … 795.2 ms 30 runs ``` There might be a slight difference here but none that I could measure using runtime. ## 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](https://nixos.org/manual/nix/stable/command-ref/conf-file.html)) - [ ] `sandbox = relaxed` - [ ] `sandbox = true` - [ ] Tested, as applicable: - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests)) - and/or [package tests](https://github.com/NixOS/nixpkgs/blob/master/pkgs/README.md#package-tests) - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test) - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) 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](https://github.com/Mic92/nixpkgs-review#usage) - [ ] Tested basic functionality of all binary files (usually in `./result/bin/`) - [24.05 Release Notes](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2405.section.md) (or backporting [23.05](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2305.section.md) and [23.11](https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2311.section.md) 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](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).  --- Add a :+1: [reaction] to [pull requests you find important]. [reaction]: https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/ [pull requests you find important]: https://github.com/NixOS/nixpkgs/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc

Given such a module system laid out in Nixpkgs, it would be interesting to explore the automation of testing combinations of such flags via a passthru.tests by using lib.mapCartesianProduct.