[Ekapkgs] Remove .overrideDerivation from lib.mkOverridable

[jonringer]

.overrideAttrs has been preferred for a while (5yrs+), and it's almost never used.

[blaggacao]

I wonder: Is there room and, secondly, would this be the time for a leap into a baseline of more composable (e.g. module-based) override mechanisms?

[jonringer]

I wonder: Is there room and, secondly, would this be the time for a leap into a baseline of more composable (e.g. module-based) override mechanisms?

You would need the creation of a .drv to be module based to begin with for this to work.

I don' think the cpu pain is worth it. Also nix modules have a pretty poor UX once you get into infinite recursion territory

[adrian-gierakowski]

I don' think the cpu pain is worth it.

It might be possible to create a cut down version of module system to address this: https://gist.github.com/roberth/940dff88ca5f5f95949dc309dbe60a65

infinite recursion territory

This problem is not exclusive to the module system.

This topic probably deserves its own issue though

[jonringer]

I think it would be interesting to explore of using modules for drv's. I think Aux has dabbled with the concept, and seems to work, although a bit painfully verbose.

Right now I'm goal is more "what is a much more pleasurable nixpkgs experience" rather than, "re-thinking nix packaging from the ground up".

This topic probably deserves its own issue though

Agreed, but it is a UX issue which is very painful when encountered.

[whs-dot-hk]

Is turning the evalModules into runCommand an option?

[whs-dot-hk]

Just thinking, nix pipe into AI, then AI eval the modules, then give back a final nix code?

[jonringer]

Is turning the evalModules into runCommand an option?

No, evalModules does a lot to traverse all the options, then create a config fixed point. config.system.build.* stuff can be viewed as runcommands though