1000 instances of nixpkgs

Links
28

I am currently thinking about the same issue and @zimbatm’s post and this discussion cleared a lot of things up for me already. However I am still struggling to arrive at a best practice to default to when creating a new flake. Basically I was wondering the same thing asked here (Good practice for Nix Flakes) by @techieAgnostic, to which it seems the exact opposite to what’s proposed here is recommended.

My current default is to

  1. expose on overlay
  2. (optionally) expose a nixos module applying that overlay, e.g.

(assume flake-utils is used in the examples)

...
{
  overlay.default = import ./overlay.nix;
  nixosModule = {
    imports = [ ./module.nix ];
    config.nixpkgs.overlays = [ self.overlay.default ];
  };
};
...
  1. expose a package applying that same overlay.

For 3. the natural thing to do is probably what @zimbatm proposes in (Good practice for Nix Flakes):

...
let
  pkgs = import nixpkgs {
    inherit system;
    overlays = [ self.overlay ];
  };
in   
{
  packages.default = pkgs.my-package;
}

From my point of view this has a few benefits:

  1. I do not need to make an assumption on how this flake is used. Downstream users can either choose to use the overlay to avoid the “1000 nixpkgs”-problem, or decide they don’t care (e.g. because usage is at the root of the dependency tree, like nix run) and use the provided package.
  2. It’s easy to expose the package to the provided nixos module. If I understand correctly using specialArgs requires extra ritual when constructing the system configuration, while with this approach the provided nixos module is more or less usable “standalone”.

Of course it comes with the usual drawbacks of using overlays already discussed here. Most importantly:

  • overlays are opaque, ie. I cannot know what packages are exposed by the overlay without reading the flake
  • some say it is a misuse of overlays to only provide leaf packages
  • it has the potential of accidentally overwriting existing attributes in nixpkgs. Even if a name is currently not taken, that might easily change in the future.

Another drawback is that it is not at all clear to newcomers when to use the overlay and when to use the packages output of my flake. With which we’re basically back to the 1000 nixpkgs problem.

Now I wonder if at least for simple cases (ie. packages that do not need to modify nixpkgs, which is probably the majority?) I could instead expose my package as

...
let
  pkgs = import nixpkgs.legacyPackages.${system};
in   
{
  packages.default = (self.overlay.default pkgs pkgs).my-package;
}

and only fall back to importing nixpkgs when really necessary. Is there something obviously wrong with that approach?

5 Likes