| 23 Aug 2024 |
 greg | OK, so I've mangled the file to get rid of the first few lines where it was complaining and choking. Now it can't parse the deps entries with their version numbers. 🤷 SyntaxError: Unknown token: { line: 3, col: 12, type: 'NUMBER', value: 1 } 3:12 in lockfile Where line 3 now looks like version: 1.2.6. It gets the digit 1 in the first spot and chokes. | 20:59:55 |
| greg | So I've moved on from it apparently not being able to handle empty lines to now it can't handle parsing numbers. So that's good, I guess? | 21:00:30 |
| greg | Oy. I am basically certain I am matching what other packages are doing, but for me it's not working. And the error doesn't mean anything to me. It's being thrown by this line offline> ++ prefetch-yarn-deps --verbose --builder /nix/store/3pj64cpdxi0nn84ip9lni677w82kh1v5-source/yarn.lock | 22:50:25 |
| greg | Looks like it might be a problem with yarn file versions. Apparently nothing later than Yarn v1 is supported | 23:08:30 |
| 24 Aug 2024 |
| greg | Yup, that's fixed by doing lots of messing around with the yarn file. Now, to find out why yarn won't accept the --offline option from the yarnConfigHook | 00:07:23 |
| greg | homarr> ++ [[ -z /nix/store/fm90bn9wyr4iralc8bsg9m0826jqsf1w-offline ]]
homarr> ++ yarn config --offline set yarn-offline-mirror /nix/store/fm90bn9wyr4iralc8bsg9m0826jqsf1w-offline
homarr> Unknown Syntax Error: Unsupported option name ("--offline").
| 00:11:42 |
| greg | That's straight out of the yarnConfigHook. so I'd love to know how I'm screwing that one up | 00:12:20 |
|  cafkafk changed their profile picture. | 07:02:13 |
| 25 Aug 2024 |
 felschr | Could somebody take a look at this PR?
https://github.com/NixOS/nixpkgs/pull/333759 | 17:19:19 |
 emily | any pnpm-knowers here? do we have any way of backporting pnpm-using things to 24.05? | 20:18:05 |
| 26 Aug 2024 |
| emily | (answer: yes, I backported it :P) | 21:53:36 |
| 27 Aug 2024 |
|  oliver.falvai joined the room. | 10:57:16 |
|  @mat:matrix.matmoa.xyz joined the room. | 13:24:30 |
|  @aloisw:kde.org left the room. | 17:20:21 |
| 29 Aug 2024 |
| @mat:matrix.matmoa.xyz | Hey, any idea if it's possible to build a npm project and then build a go module in a flake.nix ? I can't find anything at all about building web frontends as part of packages ... I can pre-build the frontend files and then use this flake to build the binary but having to commit pre-built static files is kinda silly ....
https://github.com/MathieuMoalic/amumax/blob/main/flake.nix | 13:04:13 |
 Winter | just build it in two derivations | 13:20:16 |
| @mat:matrix.matmoa.xyz | Thanks, I think I made it work using two derivations, I am really new to this and I didn't know it could be as simple as that ^^' | 14:39:47 |
| greg | There are several apps in nixpkgs that do exactly what you're discussing. I found them when I was trying and failing to get Homarr to build in Nix | 15:35:52 |
| greg | Cook CLI does that, but with Rust instead of Go. Gotify seems to do what you're suggesting, mat | 15:37:39 |
| greg | https://github.com/NixOS/nixpkgs/tree/master/pkgs/servers/gotify | 15:38:17 |
| @mat:matrix.matmoa.xyz | Thanks! | 16:04:25 |
 @adis:blad.is | It's actually not that hard to build it as one derivation.
buildGoModule {
npmDeps = fetchNpmDeps { ... }; # Or use importNpmLock
npmBuildScript = "build";
nativeBuildInputs = with npmHooks; [ npmConfigHook npmBuilidHook npmInstallHook nodejs.python ]; # Or importNpmLock.npmConfigHook
}
| 23:27:55 |
| @adis:blad.is | ^ This kinda thing is a reason why we should move away from functional abstractions a la buildNpmPackage to stdenv hooks instead | 23:29:27 |
| @adis:blad.is | It's a bit too hard to grok composition currently | 23:29:38 |
| emily | (but why build one derivation when you can build two?) | 23:30:26 |
| @adis:blad.is | In reply to @emilazy:matrix.org
(but why build one derivation when you can build two?) I'm a bit of a derivation collector myself | 23:34:11 |
| Winter | In reply to @adis:blad.is
It's actually not that hard to build it as one derivation.
buildGoModule {
npmDeps = fetchNpmDeps { ... }; # Or use importNpmLock
npmBuildScript = "build";
nativeBuildInputs = with npmHooks; [ npmConfigHook npmBuilidHook npmInstallHook nodejs.python ]; # Or importNpmLock.npmConfigHook
}
it's not i just forgot if buildGoModule fucks it up or not | 23:50:25 |
| Winter | In reply to @adis:blad.is
^ This kinda thing is a reason why we should move away from functional abstractions a la buildNpmPackage to stdenv hooks instead providing both isn't bad when you don't need composition, which is why i provided both and not just one (...like Go...) | 23:50:57 |
| @adis:blad.is | In reply to @winter:catgirl.cloud
providing both isn't bad when you don't need composition, which is why i provided both and not just one (...like Go...) I'm really of two minds about that. One the one hand, yes, you get more compact/convenient code.
OTOH it really gives you concept overload and it's actually harder to learn what's going on. | 23:52:41 |
| @adis:blad.is | The learning curve of the functional abstractions looks more like a cliff than a curve | 23:53:19 |
