| 29 May 2023 |
 infinisil | I think it was also mentioned somewhere that a name that doesn't particularly mean anything is better because it makes it so people don't assume anything about it | 12:59:29 |
| infinisil | Oh yeah it was mentioned here: https://github.com/NixOS/rfcs/pull/140#issuecomment-1565609228 | 13:02:28 |
 @piegames:matrix.org | In reply to @infinisil:matrix.org
I think it was also mentioned somewhere that a name that doesn't particularly mean anything is better because it makes it so people don't assume anything about it I wouldn't say "better", but "acceptable". I'm not against looking for a good name that actually relates to its concept | 13:07:04 |
| @piegames:matrix.org | Some more hip shots: pkgs/packages, pkgs/main | 13:07:28 |
| infinisil | Immediate thoughts: pkgs/packages -> it's weird to have the same thing twice in a row, what should go into pkgs but not pkgs/packages? If it's a package it should definitely go into pkgs, but then why not pkgs/packages because that also means packages | 13:10:02 |
| infinisil | pkgs/main feels like it's the main packages, who decides which packages are the main ones? Or alternatively it looks like an entry-point, but it's not where the entry-point is. | 13:11:17 |
| infinisil | piegames: What about pkgs/top? | 13:11:37 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: What about pkgs/top? IMO that's even more confusable with "top-level" than "main" | 13:13:08 |
| infinisil | The one problem there is that while only top-level packages are included in the standard, it's not all top-level packages. In particular only packages defined using callPackage are included, but we can imagine wanting those to be included in the future once we figure out a better specification for package declarations | 13:13:18 |
| infinisil | piegames: Ah true, though I'd argue that top-level should eventually be renamed to e.g. package-sets or so | 13:14:29 |
| infinisil | Otherwise I'm actually really liking pkgs/top now.. | 13:14:50 |
| @piegames:matrix.org | For folder names, there's always some ambiguity to how to interpret their name. Is "top-level" the place to put all top-level packages, or where the top-level is defined? Is "main" the entry point of the code, or the main place to put packages? | 13:15:15 |
| 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 |
