!djTaTBQyWEPRQxrPTb:nixos.org

Nixpkgs Architecture

216 Members
Discussions about Nixpkgs' architecture - https://github.com/NixOS/nixpkgs/labels/architecture47 Servers

Load older messages


SenderMessageTime
8 Mar 2024
@jonringer:matrix.org@jonringer:matrix.org

This is a heavy distortion of what actually happened at best.

All I have to go on is that post-fallout chatter, and what srid released publicly. There's was little transparency to clarify the reasoning behind the ban.

18:00:26
@jonringer:matrix.org@jonringer:matrix.orgAnyway, to prevent further noise in this thread. I'll stop my responses.18:01:43
@infinisil:matrix.orginfinisilIf you start discussing this elsewhere you can post a link here for reference :)18:02:11
@zimbatm:numtide.comJonas ChevalierOne of the hard part of getting large projects done is to find the right people. People you get along with and that are going to augment you. One bad apple can easily disrupt a project. That bad apple might be a good fit for other people so it's not a judgement. But it makes sense to me to select people in private.18:10:40
@patka_123:matrix.org@patka_123:matrix.org joined the room.18:14:08
@nbp:mozilla.orgnbpFor having joined NixOS when there was less people than this channel has, … sometimes you just deal we who is there. But I do agree that when you have the luxury of making a cohesive team which can work well together this can yield a better outcome, but I am not sure this can easily be judged without already knowing the persons.18:15:04
@nbp:mozilla.orgnbp * For having joined NixOS when there was less people than this channel has, … sometimes you just deal we who is there. But I do agree that when you have the luxury of making a cohesive team which can work well together this can yield a better outcome, however I am not sure this can easily be judged without already knowing the persons.18:15:30
@hexa:lossy.networkhexa joined the room.18:15:43
@nbp:mozilla.orgnbp(and I should have stopped commenting as this room is about Nixpkgs Architecture)18:16:12
@zimbatm:numtide.comJonas Chevaliergood call, what is the next architecture change we should make?18:16:45
@nbp:mozilla.orgnbpS.O.S. then grafting 🙄18:17:15
@infinisil:matrix.orginfinisil I'll personally finish pkgs/by-name first, then improving it to also be usable for multiple package versions and other package sets :) 18:18:27
@Minijackson:matrix.orgMinijackson about pkgs/by-name, is there a way to use that pattern outside of nixpkgs? Are the utility functions exported somewhere? 18:20:03
@Minijackson:matrix.orgMinijacksonI think it'd be a really nice improvements in my own projects18:20:34
@infinisil:matrix.orginfinisil Minijackson: You can fairly easily use the basic pattern. The tricky bit is ensuring it's correct, though even that can be implemented fairly easily just in Nix. Nixpkgs has unique constraints that make it much trickier to do that 18:22:11
@infinisil:matrix.orginfinisil

Minijackson: This is the most basic thing you could use/copy: https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/by-name-overlay.nix

The sharding doesn't make a lot of sense when you don't have a lot of packages, so I recommend just removing that for personal use

18:23:16
@infinisil:matrix.orginfinisil Really at that point it's just a mapAttrs (name: _: callPackage (./ + "${name}") { }) (readDir ./.) 18:23:56
@infinisil:matrix.orginfinisilFairly standard pattern already :)18:24:08
@Minijackson:matrix.orgMinijacksonthanks a lot!18:24:27
@julienmalka:matrix.org@julienmalka:matrix.org joined the room.18:39:37
@janik0:matrix.org@janik0:matrix.org joined the room.18:55:10
@jakegrin:matrix.orgjakegrin joined the room.19:30:57
@rick.special:matrix.orgrick.special joined the room.19:31:35
@me:indeednotjames.com@me:indeednotjames.com joined the room.19:40:34
@jade_:matrix.org@jade_:matrix.orgI just filed: https://github.com/NixOS/nixpkgs/pull/294353 In writing this I realized that we have both makeExtensible and makeScope. Is there any reason to use makeScope over makeExtensible? Have we written down somewhere secret which one to use in which cases?20:46:54
@jade_:matrix.org@jade_:matrix.orgRelated question: in things like the nix packaging, what is the best practice for exposing internals like the boehmgc-nix package while avoiding unnecessarily confusing users with bonus attributes they probably don't care about? https://github.com/nixos/nixpkgs/blob/9080c3655bf8094f99c8c7cb548fd0ee75928260/pkgs/tools/package-management/nix/default.nix#L17-L16220:49:33
@jade_:matrix.org@jade_:matrix.org (specifically, I want to do a refactor where you can actually use the Nix common here from outside nixpkgs, which is currently not possible) 20:50:11
@infinisil:matrix.orginfinisil
In reply to @jade_:matrix.org
I just filed: https://github.com/NixOS/nixpkgs/pull/294353

In writing this I realized that we have both makeExtensible and makeScope. Is there any reason to use makeScope over makeExtensible? Have we written down somewhere secret which one to use in which cases?
makeScope allows nested scopes to be created that somewhat compose
20:50:29
@infinisil:matrix.orginfinisil That said, I don't think makeExtensible has any benefit over makeScope 20:50:51
@qyriad:katesiria.orgQyriad there is also makeScopeWithSplicing, I definitely don't think there is documentation on which of the three to use in what cases 20:51:03

Show newer messages


Back to Room ListRoom Version: 9