Function parameter reflection aka callPackage support

[amarshall]

Is your feature request related to a problem? Please describe.
Nixpkgs’s callPackage is a nice pattern, I think, that reduces boilerplate. It doesn’t seem to be possible to implement currently in Nickel as it lacks an equivalent to Nix’s builtin.functionArgs.

Describe the solution you'd like
Ability to implement callPackage, possibly through the creation of a builtin function to reflect on a function’s parameters.

Describe alternatives you've considered
That this already exists and I just cannot find it, in which case documentation may be in order.

Additional context
I presume that folks here are familiar with Nix and callPackage 🙂

[yannham]

Hello,

Indeed, callPackage is currently not implementable in Nickel. Such a builtin may be technically possible, but not trivial, as the destructuring function arguments is desugared to a plain functions and let bindings, so the information about the shape of function arguments is lost at runtime, at least at the moment.

Beside technical considerations, I remember some discussions about: should we do as Nixpkgs does currently on a number of points, or take the occasion to fix or improve on certain patterns. I hereby summon @garbas @thufschmitt @edolstra and anyone who has an opinion about this: should we also have callPackage in Nickel, or do things differently, and why?

[yannham]

Revisiting this issue, we don't plan on supporting this feature currently, as there isn't a clear need for it. As explained in part in #693, the privileged model for writing and combining packages in Nickel is to expose packages as recursive records rather than functions. As such, their inputs are easy to inspect, discover (they are just record fields) and override as it is.