| 29 May 2023 |
 infinisil | In reply to @infinisil:matrix.org
Otherwise I'm actually really liking pkgs/top now.. (top-level existing ruins it though) | 13:15:23 |
 @piegames:matrix.org | In reply to @infinisil:matrix.org
(top-level existing ruins it though) Let's keep that in mind for the day where top-level is renamed/removed then | 13:15:55 |
| infinisil | piegames: Oh I'd actually say that it's weird that when you import nixpkgs {}, that the result points at ./pkgs. Arguably the top-level attribute should be defined outside ./pkgs | 13:16:44 |
| infinisil | nixos and lib are somewhat ignored and need to rely on people importing them directly (or indirectly through pkgs.lib and pkgs.nixos) | 13:17:31 |
| infinisil | I'd be interested in more cleanly separating the top-level nixpkgs attribute into e.g. import nixpkgs {} == { pkgs = { ... }; lib = { ... }; nixos = ...; } | 13:18:09 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: Oh I'd actually say that it's weird that when you import nixpkgs {}, that the result points at ./pkgs. Arguably the top-level attribute should be defined outside ./pkgs Wait is this true? | 13:18:19 |
| @piegames:matrix.org | Ah nvm I misunderstood | 13:18:41 |
| @piegames:matrix.org | I thought you meant the <nixpkgs> path, not the value of the import | 13:19:40 |
| infinisil | I'd say that we shouldn't be too afraid to pick the wrong name, because we can always rename it. Yes it will cause merge conflicts, but it's trivially resolveable | 13:21:06 |
| infinisil | * I'd say that we shouldn't be too afraid to pick the wrong name, because we can always rename it. Yes it will cause merge conflicts, but they're trivially resolveable | 13:23:35 |
| infinisil | The file structure is not an API | 13:23:58 |
| @piegames:matrix.org | Totally agreed. And I'm fine with ending up on unit, just does this not mean that I already give up the search | 13:24:03 |
| infinisil | Hehe yeah. At this point I feel like just calling it unit with all the arguments for it and only reconsidering when strong new arguments against up against it. And considering that a lot of people already looked at it and this hasn't happened, I don't think it will ever happen | 13:25:05 |
| infinisil | * Hehe yeah. At this point I feel like just calling it unit with all the arguments for it and only reconsidering when strong new arguments against up against it. And since a lot of people already looked at it and this hasn't happened, I don't think it will ever happen | 13:25:20 |
| infinisil | But, FCP is there for even more people to look at it, so it could happen. But if we as the authors and shepherds are okay with it, it's our job to be decisive about this, we shouldn't rely on FCP to make decisions for us. | 13:27:13 |
| infinisil | Oh and also, this is a rather minor aspect of the RFC, I'd rather people focus on reviewing the more important parts of it | 13:28:36 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
Oh and also, this is a rather minor aspect of the RFC, I'd rather people focus on reviewing the more important parts of it If a discussion gets stuck on names like this, then this usually means that the rest is generally approved | 13:30:44 |
 Robert Hensing (roberth) | In reply to @infinisil:matrix.org
I'd be interested in more cleanly separating the top-level nixpkgs attribute into e.g. import nixpkgs {} == { pkgs = { ... }; lib = { ... }; nixos = ...; } like the flake, but cleaner | 13:37:45 |
| Robert Hensing (roberth) | also fyi inputs.nixpkgs.lib.nixos == import ./nixos/lib | 13:38:34 |
| Robert Hensing (roberth) | it's not a complete representation of nixos entrypoints yet though | 13:38:50 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
All good to me, I haven't pushed anything to the RFC I wouldn't be okay with, would like to hear from Robert Hensing (roberth) as well though. I think niksnut's arguments have been properly addressed here, but it might be proper to add the new arguments to the RFC as well. Hi Robert Hensing (roberth), we've had quite a bit of backlog, but please have a look at | 13:39:20 |
| Robert Hensing (roberth) | I've followed along, and I don't feel strongly about the points raised | 13:40:03 |
 nbp | well … in principle I would agree, but as long as we do not have a clean way to selectively "update" without replacing all attributes in an attribute set, this would increase the complexity for overlays which are trying to both library and packages. | 13:40:17 |
| Robert Hensing (roberth) | Or I guess you're asking me to add to the alternatives text? | 13:40:32 |
| nbp | slectively update … like suggested in S.O.S. | 13:40:35 |
| @piegames:matrix.org | In reply to @roberthensing:matrix.org
I've followed along, and I don't feel strongly about the points raised So, go for FCP? | 13:40:55 |
| nbp | * well … in principle I would agree (cleanly separating the top-level of nixpkgs), but as long as we do not have a clean way to selectively "update" without replacing all attributes in an attribute set, this would increase the complexity for overlays which are trying to both library and packages. | 13:41:07 |
| Robert Hensing (roberth) | In reply to @roberthensing:matrix.org
Or I guess you're asking me to add to the alternatives text? infinisil has been taking care of that, so I'd have to sync up with him first; not sure if that's productive | 13:41:25 |
| infinisil | No the question is just whether you accept the state of the current RFC | 13:41:47 |
| Robert Hensing (roberth) | Oh, right hadn't read up on the messages before that. I'll have a final look | 13:42:28 |
