Interesting idea. Two observations come to mind:
- Modules are already functions.
types.deferredModulein particular can be used as a function (although functions are of course unidiomatic for configuration systems where all configuration is data, which is why you won’t see it often, and it didn’t exist when this conversation was initially held) - Functions lead to UX problems with overriding, and possibly also with merging (although I haven’t full explored that difference in this context). As an example, consider the
pkg.overridemethod andpkg.overrideAttrs. Let’s call the function we pass tocallPackagea package function.overrideandoverrideAttrsare separated by the package function: the prior changes it arguments, whereas the latter overrides the result. The trouble comes when you start combining these. What if you calloverrideafteroverrideAttrs? By default this wouldn’t be even be supported, socallPackagehas special code to supportoverrideAttrs. This is clumsy and error prone because it creates coupling, really bad coupling. We haven’t solved this architectural problem, and I don’t think it’s for a lack of trying. Certainly I’ve spent some time to fix that, but there didn’t seem to be an easy fix in the confines of what can be done in Nixpkgs without “too significant” changes. I’d love to be proven wrong, and maybe it really does take an interface change like [RFC 0067] Common override interface derivations by FRidh · Pull Request #67 · NixOS/rfcs · GitHub, although I don’t know if that RFC is backed by a solution to this problem, and even then it might not scale to overriding methods likewithPackagesthat could be defined inpassthruusingfinalAttrs.overrideAttrs.
Just some insights in case anyone wants to go off and play around with such an idea. There could still be an interesting idea hiding here somewhere, and I guess deferredModule and that rfc are actually proof of that, but there could be more!
Sorry for reviving this old thread, to those who take offense ![]()