| 6 Apr 2025 |
 Las | Honestly it’s not clear to me why the output path is in the derivation at all | 11:18:56 |
| Las | Doing content addressed drvs only btw | 11:19:11 |
 flokli | You shouldn't be manually adding your own derivations, especially if you're not also calculating Output paths (correctly) | 11:24:22 |
| flokli | The only "official" way to do is by writing nix code, and having the evaluator emit it. For everything else, you're off the well-tested path. | 11:25:10 |
| flokli | It's unfortunate derivations are added as aterm into the store in first place. IMHO they should only be valid for the lifetime of the evaluation itself, and not be put in the store
| 11:26:05 |
|  sinan changed their profile picture. | 11:32:59 |
 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 |
| Las | I think it’s a misnomer | 13:37:44 |
| Las | Should be nix realize | 13:37:49 |
 vcunat | FYI, some (cross-)builds got broken now on Hydra, e.g.
https://hydra.nixos.org/build/294450042/nixlog/1/tail | 14:59:18 |
| vcunat | I'm a bit surprised myself that -Wundef triggers on preprocessor this way. | 15:00:08 |
| vcunat | I suppose you'd simply do #ifdef __APPLE__ and #elif defined(__APPLE__). Most likely easier than fighting what compiler considers a warning. | 15:03:47 |
| vcunat | * I suppose you'd simply do #ifdef __APPLE__ and #elif defined(__APPLE__). Most likely it's easier than fighting what compiler considers a warning. | 15:04:00 |
| 7 Apr 2025 |
 SomeoneSerge (back on matrix) | In reply to @flokli:matrix.org
It's unfortunate derivations are added as aterm into the store in first place. IMHO they should only be valid for the lifetime of the evaluation itself, and not be put in the store RE: validity
Resolved drvs are ok though, aside from aterm? In the sense their contents are inherently consistent with path. Assuming nix doesn't change. | 06:37:08 |
 Mic92 | https://github.com/NixOS/nixpkgs/pull/396773 nixVersions.latest: 2.26 -> 2.28 | 11:30:47 |
| Mic92 | https://github.com/NixOS/nixpkgs/pull/396750 John Ericson nix-eval-jobs: 2.26.0 -> 2.28.0 | 12:14:46 |
