@piegamesde thank you so much for leading this effort! Are there any blockers preventing further progress on this PR?

I've been doing a somewhat ad-hoc version of this to allow for easier diagnoses of build failures, like so:

I would love to see this merged -- let me know if there's any way I can help!

Me and @piegamesde sat together at NixCon to discuss this, but my conclusion there was that mkDerivation's code is very messy, and this PR makes the mess worse. It would take considerable effort to make it not messy, but I think that's what we need if we want to have any chance of maintaining this over time. And I think currently @piegamesde's priorities are with NixOS/rfcs#166

@ConnorBaker This code does a minimal implementation, which I have hopes of getting merged eventually. The current bigger task to do here is QA, especially writing unit tests for the different conditions. That's why I factored out the business logic into its own file, as Infinisil requested back then. Feel free to take on that task, I won't be working on it for a bit probably. Apart from that this change has been heavily review-stalled for a lot of time, so simply watching here and giving review as necessary would be a big help too

It seems like I'm unintentionally blocking this from progressing. I'm just taking another look, and unless I'm just missing it, the PR changes itself really aren't bad. What I think needs to be done before merging:

• Very important: Have decent tests, there's currently none. Somewhere in pkgs/test would fit.
• Double-Check that this PR actually implements the RFC correctly.
• Try to make reasonably sure that CI (ofborg and Hydra) doesn't break. Can still be reverted if it does end up breaking CI

I'd also really like for somebody to think about how we could clean up check-meta.nix over time, because while this RFC introduces a more consistent mechanism, the old mechanism is also still there for now. I think that's what I was thinking of in the previous comment.

Unfortunately I'm pretty spread out with my availability, so I don't have time to do this myself, I'll dismiss my review and don't intend to interfere with this anymore.

I was asked by @AkechiShiro to help a bit with how to write tests for this, so here's some proof of concept for how it could work: tweag@9b55daf

Hello all,

Here are the tests cases, I've though of so far, this matrix needs to be made 3 times to cover for each handlers (ignore,warn,error), in total 39 tests would be needed for full coverage for all handlers, in case I'm missing anything feel free to let me know.

So far, I have almost full coverage on the error handler and partial coverage on the warn handler.

Thanks a lot for your help for establishing the ground work for the tests @infinisil

The new PR is ready for review, thanks to all involved

Closing in favor of #478539