feat: allow extra args to be passed

[brianmcgee]

I tend to customise nixpkgs.lib in my projects using extensions. To accommodate this in a 'blueprint' style I've added extraArgs rather than trying to further customise nixpkgs. This has the added benefit of accommodating wider use cases.

  outputs =
    inputs:
    inputs.blueprint {
      inherit inputs;
      extraArgs = {
        lib = inputs.nixpkgs.lib.extend (import ./lib.nix);
      };
    };

[phaer]

Only saw this now, needs a rebase

[zimbatm]

Still mulling a bit over this.

Notice how the ./lib.nix is loaded with no inputs, so it can only deal with builtins.

Maybe something like this would be better:

extraArgs = { flake, ... }: {
  lib = inputs.nixpkgs.lib.extend flake.lib;
};

We're slowly converging towards a module system.

[ccdunder]

Hi, is there anything in the way of merging this? I was just about to make a FR/PR for adding lib to extraArgs and thought I'd check first :)

Honestly, given how conventional it is to have nixpkgs' lib as a module arg, I'd be inclined to include it by default to save everyone the boilerplate. That's just my 2 cents.

We're slowly converging towards a module system.

Wouldn't that be nice...

[phaer]

Hi, is there anything in the way of merging this?

I guess the main question is whether to add inputs to lib.nix and/or allow users to pass them in.

Feel free to open another PR if you think you've got something that works :)

[ccdunder]

I guess the main question is whether to add inputs to lib.nix and/or allow users to pass them in.

This is a really interesting discussion; it seems simple on the surface but I think there's actually a ton of implication for the direction of a project like this.

I arrived here thinking "I want access to these things. Why not give users access to these things?" The more I've thought about this question the more I think there's some very good reasons.

Assumption: A primary goal of blueprint is to obviate boilerplate. This is accomplished by giving users convenient access to tools (so that they don't need boilerplate to make "missing" ones).

Corollary: If you give users too many tools, the layer of abstraction breaks down, or they make a whole new layer of boilerplate on top. To the extent that users want something in order to write boilerplate, it ought not be made convenient. Instead, give users what they actually need (e.g. "to what end do they want inputs and extraArgs?")

Bear in mind that folks can already modify extraArgs, pass inputs to libs, etc. without changes to blueprint. I'm doing it myself. It's just not convenient.

In looking at my own usage of libs and extraArgs I realize they're all things that better serve users by upstreaming rather than fixing it for only myself:

• standalone home-manager support: I've now seen 3 other impls of this, which quacks like boilerplate. Luckily there's a PR out.
• "./libs vs. nixpkgs.libs": This seems like a collision in the pseudo-module system of blueprint that's worth solving for everyone.

Disclaimer: this is a strong opinion loosely held. Maybe it turns out that there are just some things that can't be better served by shared, higher-level tools. Maybe this turns out like overlays. I don't know for sure, but I've seen a lot of layers of abstraction break down and my current opinion is it's worth being more ... opinionated.

[ccdunder]

I guess the main question is whether to add inputs to lib.nix and/or allow users to pass them in.

tl;dr / concretely, my 2 cents:

• Give them extraArgs and a big caveat that you ought upstream instead or not use it (like overlays). Name it extraArgsThatIShouldFigureOutABetterSolutionForThatWontBeAMaintenanceHassleForever.
• Give them inputs in lib. Too much useful stuff in nixpkgs.lib. Making a pkgs/libs seems like overkill.
• (in a new thread) Figure out what to do about "./libs vs. nixpkgs.lib" in the existing args.

[ccdunder]

Small revision: after playing around with it, it seems necessary & useful to have a ~pkgs/libs separate from lib; something equivalent to perSystem.nixpkgs.lib vs. lib & nixpkgs.lib. Making perSystem available in lib would mean it could no longer be used in a system-less scope.