| 6 Apr 2025 |
 emily | kind of at odds with the dynamic-derivations model, right? | 11:51:49 |
| emily | (not saying that I necessarily disagree, just that it seems like there's a commitment to some serialized derivation form at this point) | 11:52:21 |
 p14 | In reply to @roberthensing:matrix.org
Maybe nix.overrideAttrs could throw a useful error referring to a monolithic nixVersions.nix_mono package to ease the transition Just hit this and would have appreciated such an error. | 11:54:32 |
| p14 | Actually struggling a bit to untangle what is going on and why I can’t apply a patch. Does nix mono exist yet? | 11:55:32 |
 Las | In reply to @flokli:matrix.org
You shouldn't be manually adding your own derivations, especially if you're not also calculating Output paths (correctly) I’m doing dyn drvs | 12:39:18 |
| Las | I don’t want to depend on the nix evaluator in my drv | 12:39:27 |
| emily | (are you sure your problem is not just missing ^*?) | 12:51:09 |
| Las | In reply to @emilazy:matrix.org
(are you sure your problem is not just missing ^*?) What | 13:25:30 |
| Las | I never considered that | 13:25:41 |
| Las | Why would you need that | 13:25:46 |
| emily | nix build /nix/store/foo.drv builds that drv, …^out builds that output | 13:25:52 |
| emily | there was a warning for it for many releases but it got removed | 13:25:58 |
| emily | the idea is that nix build X always produces X | 13:26:03 |
| emily | so nix build /nix/build/non-drv-store-path will try to substitute that path, e.g. | 13:26:16 |
| Las | Makes sense | 13:37:12 |
