| 29 Aug 2024 |
 @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 |
| emily | I really dislike the custom builder functions. | 23:54:01 |
| emily | I don't know that hooks are my preferred abstraction either but the idea of 1 derivation : 1 language is just broken | 23:54:11 |
| emily | OTOH, any derivation that can easily be split up probably should be, and this is a perfect example | 23:54:23 |
| emily | so it works out | 23:54:33 |
| 30 Aug 2024 |
| Winter | for a long time, i've wanted to write Go setup hooks. but when i wanted to ask zowoq about it (since apparently they were also doing it), they told me to fuck off. it's been years since then, and it still hasn't happened... so... | 03:43:43 |
| Winter | * | 03:43:55 |
| Winter | not really interested in helping to improve the Go situation | 03:44:04 |
| Winter | i'm glad mostly everything else has switched to at least providing setup hooks, though | 03:46:15 |
| @adis:blad.is | I'm tempted to tackle that similarly to https://github.com/NixOS/nixpkgs/issues/333702 | 03:48:37 |
| emily | Node.js could use a bit of the same treatment, I've noticed | 03:50:08 |
| emily | though I think they had something closer to that in the past and replaced it? | 03:50:16 |
| @adis:blad.is | Yeah it was.. Terrible. | 03:50:37 |
| emily | what if it was good instead? :) | 03:50:45 |
| @adis:blad.is | Conceptually it doesn't have to be, but our setup was. | 03:50:50 |
| emily | ooh, we should start calling it "OBLF" so we have another acronym as confusing and misleading as "IFD". | 03:50:55 |
| emily | I didn't actually get around to starting to write the tool for Rust yet, but FWIW I wouldn't necessarily be opposed to extending it to work with other language package sets if that ends up being a thing that would be convenient | 03:51:42 |
| emily | (though I can understand if Go wants a tool written in Go, etc.) | 03:51:57 |
| @adis:blad.is | In reply to @emilazy:matrix.org
Node.js could use a bit of the same treatment, I've noticed I can't even conceptualize what that would look like for node | 03:53:45 |
