| 25 Jan 2024 |
|  sheep_empress joined the room. | 19:12:21 |
| sheep_empress | hi! i've been sent here from the nixpkgs group because i'm having a problem with ofborg that i can't replicate on my machine. i'm trying to package a program called autobrr. it's written in go with a web interface built in pnpm+vite+esbuild. i use a derivation to note what version of esbuild i need to grab, and this works on my machine, but ofborg says that it can't build my pr because it thinks this derivation is empty. | 19:24:41 |
| sheep_empress | could somebody help me out? my pull request is here, and the ofborg log that i'm referencing is here. | 19:26:15 |
 cole-h | One issue is that you're using import-from-derivation, which is not allowed in Nixpkgs (so as not to blow up the time it takes to evaluate) | 19:29:38 |
| cole-h | (If you run your build with --option allow-import-from-derivation false, you can see this happening) | 19:30:06 |
| sheep_empress | Ok, thanks, that's good to know that I can't use readFile to get anything from a nix store in nixpkgs. | 19:39:18 |
 K900 | Not "anything" | 19:40:07 |
| K900 | But only outputs of other derivations | 19:40:11 |
| sheep_empress | Am I able to use it to read from the same derivation I'm currently in? | 19:40:50 |
| K900 | No | 19:41:53 |
| K900 | Because you're not in a derivation | 19:41:58 |
| K900 | You're in eval | 19:42:02 |
| sheep_empress | Could you explain what you mean by that? | 19:43:54 |
| K900 | builtins.readFile happens at eval time | 19:44:51 |
| K900 | Nix computes a build plan first, then executes it | 19:45:03 |
| K900 | IFD is bad because you have to compute some build plan, then execute it, then use the output from that to compute more build plan | 19:45:19 |
| K900 | Which is slow and means you can't have a full build plan ahead of time | 19:45:28 |
| sheep_empress | I think part of the problem I'm having might be because I really don't know the full build plan ahead of time. I don't know what version of esbuild the build needs until I've run pnpm | 19:48:18 |
| K900 | Then you need to hardcode it in nixpkgs | 19:48:28 |
| K900 | And update it manually when updating the package | 19:48:34 |
| K900 | Because nixpkgs tooling does need to know the full build plan ahead of time | 19:48:42 |
| sheep_empress | Was worried that was going to be the answer. Thanks for all your help | 19:49:58 |
 7c6f434c | Nixpkgs has quite a few generated expression sets, actually | 19:52:55 |
| sheep_empress | Hardcoding the version lets it build fine without import-from-derivation, and it's what I might do for my first package for now 😅 | 19:56:02 |
| sheep_empress | Future me might change her mind after she's had to update it a few times though. Would love if you could point me towards docs on generated expressions if you think those could help me solve my problem | 19:57:44 |
|  Benedikt joined the room. | 20:10:15 |
| K900 | Generated expressions isn't a Nix feature | 20:11:32 |
| 7c6f434c | https://nixos.org/manual/nixpkgs/stable/#var-passthru-updateScript | 20:11:33 |
| K900 | You can just write a script that generates the data you need and writes it to a .nix file or a JSON file or whatever | 20:11:46 |
| K900 | And then you can at least automate away the manual editing | 20:11:57 |
