Conversation
|
Can you help me understand why having a custom function here is more desirable? |
|
The custom function here basically have the same functionality as the one Also removing |
zombiezen
left a comment
zombiezen
left a comment
There was a problem hiding this comment.
Thanks for the explanation. I'm always happy to eliminate a dependency, although I'm not sure that I fully grok the impact of a flake.lock dependency: they seem mostly lightweight.
I'm cautiously okay with this, but I'd like to address a couple maintenance concerns before going forward:
| packages = forEachSystem ( | ||
| system: pkgs: | ||
| let | ||
| buildGoModule = pkgs.buildGo125Module; |
There was a problem hiding this comment.
I don't like that this is separated from the Go up above and I'm worried it's going to get out of sync. Can we restructure this so that it is a top-level for-each like what's in main?
There was a problem hiding this comment.
Can we restructure this so that it is a top-level for-each like what's in main?
Then aren't we just trying to re-create flake-utils, which isnt really ideal imo.
I'll try to unify the behavior here.
|
|
||
| inherit (pkgs.lib.attrsets) optionalAttrs; | ||
| forEachSystem = | ||
| fn: lib.genAttrs lib.systems.flakeExposed (system: fn system nixpkgs.legacyPackages.${system}); |
There was a problem hiding this comment.
This attribute is considered experimental and is subject to change.
I also don't really want to expand to that potential set to what nixpkgs supports: zb is very OS-dependent, and so the exact set of targets is important. Let's use an explicit list of systems.
2 participants
Remove
flake-utilsfrom Flake inputs and replace with custom function that achieve similar result.