Cheaper nixpkgs.lib for flake users

Announcements
1

  • Some projects choose to not depend on nixpkgs for a variety of reasons.

  • Such projects often re-implement library function just to work around that restriction.

Trying to alleviate the bending-over-backwards I’ve seen out in the wild, I set up a github workflow that extracts lib from NixOS/nixpkgs every Sunday.

Use it like so:

{
  inputs.lib.url = "https://github.com/divnix/nixpkgs.lib";
}

Any feedback welcome, we’ll see if it entirely works as intended by next sunday, I guess — if there are changes to ./lib available upstream. :wink:

9 Likes
2

You beat me to it! Good work.

3

I realized it’s actually somewhat dumb what I did.

We’d rather want to have that flake.nix within nixpkgs/lib folder.

Wouldn’t that be equivalent when used with inputs.lib = github:NixOS/nixpkgs?dir=lib;?

And so I did: init: lib/flake by blaggacao · Pull Request #119967 · NixOS/nixpkgs · GitHub

1 Like
5

For the interested parties, @Pacman99 derived a valid use case for divnix/nixpkgs.lib that on my quick opinion cannot be implemented via a NixOS/nixpkgs/lib/flake.nix in:

https://github.com/divnix/digga/pull/7

Since flake inputs are lazily fetched, it might make sense for example for a library flake (like the above) to even declare nixpkgs.lib + nixpkgs (for pkgs) in parrallel.

That’s what “cheaper” in the title of this thread stands for.

Edit: the github workflow seems to do a great job.

1 Like
6

PR below merged.
Now users can:

  • get a direct handle on the upstream flake
  • use a handle on the divnix/nixpkgs.lib (still a lot lighter to fetch)

In both cases, projects can depend explicitly on lib without also depending on the whole of nixpkgs.

That’s a big step in the direction of cleaner dependency definition.

https://github.com/NixOS/nixpkgs/pull/119967

3 Likes