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:

1. Builders - functions that return derivation. builders :: pkgs -> attrsOf (attrs -> derivation)
2. 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.

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:

1. Builders - functions that return derivation. builders :: pkgs -> attrsOf (attrs -> derivation)
2. 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.

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.

In reply to @k900:0upti.me
It's better to have a fixed convention than to argue about it every time