support mkDerivation `finalAttrs` call pattern?

[abathur]

I won't pretend to have the firmest grasp of this, but nixpkgs reviewers are leaning heavily on PR authors to use the mkDerivation (finalAttrs: ...) pattern first added in:

• stdenv.mkDerivation: overlay style overridable recursive attributes NixOS/nixpkgs#119942

After skimming related PRs, my best guess is that I'll want to wait to tackle this until the following PR implementing lib.extendMkDerivation lands:

• lib.extendMkDerivation: init NixOS/nixpkgs#234651

Since resholve's mkDerivation will need work to support this and it doesn't look immediately tractable, there'll probably be an increasing number of people getting asked to implement this (as in NixOS/nixpkgs#224881 (comment)) only to run into a dead end for now.

[D3vil0p3r]

Any news about it?

[quinneden]

Any news about it?

[abathur]

It looks like this was unblocked earlier this year, but I hadn't noticed that PR finally landed until you asked.

I'll need to find time to implement unless someone can PR a fix.

It's been long enough that I've forgotten how involved it was, but I'll try to find time to look and get it done if it's straightforward. Busy lately--no promises if it turns into a slog.

[winterqt]

I think the biggest challenge here (after taking a stab at it for a bit) is maintaining the “we resholve in a separate drv” bit — I think you’d have to do A Lot Of Crimes to get that to work well with lib.extendMkDerivation. e.g. a constructDrv defined as

a: let u = stdenv.mkDerivation a; inherit (u.passthru) solutions; in stdenv.mkDerivation …

(poorly formatted because mobile, sorry!)

Maybe @ShamrockLee has a better idea, but that was about as best as I could come up with in the half an hour I spent poking at it.

[ShamrockLee]

Thanks for pinning.

I'm not familiar with reshove's internal. From the above discussion, it looks like you have your own mkDerivation. Is that the case?

If so, I think it might be hacky to implenemt, and the complexity comes from the inherent complexity of recursive resolution instead of the design of stdenv.mkDerivation or lib.extendMkDerivation.

lib.extendMkDerivation is just a stdenv.mkDerivation-friendly decorator that applies extenstion to the function input before feeding it to the undecorated function.
It's core logic makes no asumption to the output of the function it decorates.

{
  extendInputWithExclusion =
    f: # <- consteuctDrv
    {
      extenstion, # <- extendDrvArgs
      excludeNames, # <- excludeDrvArgNames
    }:
    fpArgs:
    f (extendWithExclusion { inherit extenstion excludeNames; } fpArgs)
}

[winterqt]

I'm not familiar with reshove's internal. From the above discussion, it looks like you have your own mkDerivation. Is that the case?

Kind of: resholve.mkDerivation simply builds a derivation using the args passed, but then makes a wrapper derivation transforming the output of that inner derivation.

Given we’re still just using stdenv.mkDerivation under the hood, the thing that’s giving me trouble is that I can’t extract solutions from the attrset unless I do some cursed passthru hacks. (Hopefully the example I posted above makes more sense now, or at least you now understand why I wrote it like that.)

[ShamrockLee]

For such interface, the wrapper derivation should be defined in transformDrv, which extract solutions from drv.solutions or drv.__reshoveSolutions. excludeDrvArgName should list "solutions" and extendDrvArgs should insert solutions to passthru.

The transformation should be quite straightforward and with little hacks.