| 8 Jul 2022 |
|  Gytis Ivaskevicius joined the room. | 08:24:24 |
 tomberek | In reply to @infinisil:matrix.org
Ping tomberek I’m camping this week. The overall idea sounds good. The one recommendation I’d have is to have two kinds of sessions. One for meetings/discussion and one for actually working/hacking/pair-programming/etc. Time set aside for each. This worked well (when we adhere to it) on the UX team. | 10:54:10 |
|  Sandro 🐧 joined the room. | 12:26:37 |
|  Théophane joined the room. | 13:14:36 |
|  mkaito joined the room. | 13:17:45 |
|  biohazard6743 joined the room. | 17:58:25 |
| 9 Jul 2022 |
|  nbathum (he or they) joined the room. | 02:27:07 |
| nbathum (he or they) | infinisil: please invite me nick@bathumsphere.com | 02:28:32 |
|  mstone joined the room. | 03:26:46 |
 infinisil | nbathum (he or they): Done :) | 08:02:12 |
|  yinfeng joined the room. | 09:44:50 |
|  jiegec joined the room. | 09:49:06 |
|  linj joined the room. | 09:52:01 |
| Gytis Ivaskevicius | Hi all, yesterday this idea popped into my mind, has no business value just a cleanup. Maybe someone could evolve this idea further. Anyways here I go:
pkgs is a large complex recursive structure that should be simplified.
Solution: Create several 'simple' namespaces which together could be evaluated to pkgs
One of the examples would be lib structure, while it contains basically anything - it is nice and flat lib :: attrsOf any
So off the top of my head, there are 2 that could be separated:
- Builders - functions that return derivation.
builders :: pkgs -> attrsOf (attrs -> derivation)
- Package groups - attribute sets of packages like
python.<derivation> or gnome.<derivation>. Sometimes they include builders, not sure how to deal with that. packageGroups :: pkgs -> attrsOf derivation
pkgs evaluation:
let
result = fancyPkgsBuilder [
(builders result)
(packageGroups result)
(rootPackages result)
];
in result
And yeah, for the record I have not thought all this through and there will be edge cases, just maybe if there ever is going to be some large refactoring someone will keep this in mind.
| 16:50:03 |
| 10 Jul 2022 |
 Artturin | Redacted or Malformed Event | 11:46:17 |
| Artturin | https://github.com/NixOS/nixpkgs/issues/172008 | 11:48:22 |
| infinisil | In reply to @gytis-ivaskevicius:matrix.org
Hi all, yesterday this idea popped into my mind, has no business value just a cleanup. Maybe someone could evolve this idea further. Anyways here I go:
pkgs is a large complex recursive structure that should be simplified.
Solution: Create several 'simple' namespaces which together could be evaluated to pkgs
One of the examples would be lib structure, while it contains basically anything - it is nice and flat lib :: attrsOf any
So off the top of my head, there are 2 that could be separated:
- Builders - functions that return derivation.
builders :: pkgs -> attrsOf (attrs -> derivation)
- Package groups - attribute sets of packages like
python.<derivation> or gnome.<derivation>. Sometimes they include builders, not sure how to deal with that. packageGroups :: pkgs -> attrsOf derivation
pkgs evaluation:
let
result = fancyPkgsBuilder [
(builders result)
(packageGroups result)
(rootPackages result)
];
in result
And yeah, for the record I have not thought all this through and there will be edge cases, just maybe if there ever is going to be some large refactoring someone will keep this in mind.
I haven't thought of making a separation like that, but it's an interesting thought. I guess this also goes a bit into the direction of what flakes does, to have separate output attributes for different things, like derivations in packages, library functions in lib, nixos modules in nixosModules, etc. | 15:01:20 |
 kevincox | We kinda already have separation for a few things like lib and python packages. But to be honest I generally find that anything more complex leads to pretty meaningless grouping.
For example with the nixpkgs directory structure I always feel like I'm picking a vaguely related directory when adding a package and I've never actually got any value from the topic directory a package was in. In fact it is just annoying because the longer path makes false positives in my IDE's fuzzy finder. | 15:17:07 |
 K900 | We should just do a crates.io and organize packages by name | 15:26:35 |
| K900 | pkgs/h/he/hello/default.nix | 15:26:52 |
| K900 | (no) | 15:26:54 |
| K900 | (unless?) | 15:26:57 |
| infinisil | I've wanted something like this for a while. I think it would be a good idea | 15:27:41 |
| K900 | * `pkgs/h/e/hello/default.nix` | 15:27:59 |
| K900 | The more I think about it, the more I'm starting to like it tbh | 15:28:16 |
| K900 | It's kind of the same thing as having a consistent formatter (no. drop the pitchforks.) | 15:29:04 |
| K900 | It's better to have a fixed convention than to argue about it every time | 15:29:24 |
 Rick (Mindavi) | In reply to @k900:0upti.me
It's better to have a fixed convention than to argue about it every time Yes, but indeed always hard to enforce/add retroactively | 15:30:30 |
| infinisil | It should probably be pkgs/prefixed/h/e/hello/default.nix, so a slow transition is possible | 15:30:52 |
| infinisil | Also I like the idea of introducing tags, like meta.tags = [ "gui" "audio" "networking" ], and then having some functions/tools to filter/search by category | 15:31:53 |
