| 17 Aug 2022 |
profpatsch | So you can’t look at modules in a vacuum, they might influence each other. | 13:56:49 |
Robert Hensing (roberth) | exactly, so only use it when that's what you need | 13:57:26 |
profpatsch | roberthensing: I’m not talking about only using the power when you need it, I’m saying because the power is there in the first place, the implementation will need to be slow. | 13:58:17 |
Robert Hensing (roberth) | I'm not suggesting that we put all logic together all the time like we do in NixOS | 13:59:06 |
profpatsch | It’s like taking the first element of a lazy list, which should be O(1), except the lazy list is generated in a way that you can only know the first element if you know the last element | 13:59:08 |
Robert Hensing (roberth) | you only add the stuff you need for a specific package or derivation | 13:59:20 |
profpatsch | I hope that makes sense | 13:59:24 |
Robert Hensing (roberth) | so then it is a good thing that we can create interfaces that allow extension rather than hardcoding everything into a huge object | 14:02:31 |
Robert Hensing (roberth) | we need to consider the context here. Do you know of an alternative way to reorganize mkDerivation to support polyglot projects with multiple language integrations in the same derivation? | 14:05:44 |
Alyssa Ross | uh, setup hooks? | 14:08:03 |
Alyssa Ross | (not saying they're good) | 14:08:30 |
Robert Hensing (roberth) | good point, but currently language integrations have a bunch of Nix-level logic too | 14:08:31 |
Alyssa Ross | yes, but we could try to get rid of that | 14:08:47 |
Alyssa Ross | that had been my plan, assuming I couldn't make fundamental changes to stdenv | 14:09:14 |
Robert Hensing (roberth) | in some cases that may cause rebuilds, because a conditional can not cause a dependency to be removed from the hash when the conditional is in the builder | 14:09:41 |
Robert Hensing (roberth) | * that will cause more rebuilds, because a conditional can not cause a dependency to be removed from the hash when the conditional is in the builder | 14:09:58 |
profpatsch | roberthensing: wait, I thought this was about the module system eval overhead | 14:17:51 |
profpatsch | mkDerivation is orthogonal imo | 14:18:14 |
Robert Hensing (roberth) |
Why strip down the module system? A module system for packaging would be awesome, but the current module system is too slow. This is ok for configuration management, but hurts packaging performance too much.
| 14:18:49 |
Robert Hensing (roberth) | https://gist.github.com/roberth/940dff88ca5f5f95949dc309dbe60a65 | 14:19:02 |
Robert Hensing (roberth) | modules quick enough for use in packaging | 14:19:11 |
Robert Hensing (roberth) | that's the niche for which I thought it's fitting | 14:19:59 |
profpatsch | okay I missed that part | 14:20:00 |
profpatsch | I think the module system is already too slow for nixos options | 14:20:16 |
profpatsch | Evalling my system takes like 5–10 seconds | 14:20:29 |
profpatsch | and that’s just one system | 14:20:31 |
Robert Hensing (roberth) | it's really quick if you don't load all of NixOS | 14:20:32 |
Robert Hensing (roberth) | I've revived RFC 22 a bit around the start of the year | 14:21:08 |
profpatsch | now you’ve got two import systems; who guarantees that some module that you are importing from nixos does not implicitely pull in the whole elephant? | 14:21:30 |
profpatsch | I had a thought that the first step to get an overview would be to generate a dot-graph of all option dependencies in nixpkgs | 14:22:18 |