In reply to @k900:0upti.me
Maybe in a special top-level directory

I noticed that I sparked quite a discussion 😄 So I ideally would see:

• Folder structure representing attrs structure. If package is in top level - under root directory. If there is a package group (gnome, pythonPackages, etc) - then it should be under directory with the same name
• I got a feeling that all-packages.nix is necessary otherwise we would be impacting performance but I have not tested it (also we could autogenerate such file)
• all these overrides should be separated from all-packages.nix I'd say one file for 'dumb package definitions' and another for overwrites
• Consider exposing blueprints https://github.com/gytis-ivaskevicius/nix-patterns/blob/master/blueprints/flake.nix#L7-L10 instead of derivations and mapAttrs when necessary (is it more work than its worth?)0

nix-repl> length (attrNames pkgs)
16563

I wonder if we need overrides in nixpkgs. Maybe we can give every modified package a name and let the called package use that name. (basically no more python = python38). But that does add some API instability for user overrides. Maybe a multi-level approach can work?

I like the look of blueprints but how does this work for user-overrides?

In reply to @k900:0upti.me
I feel like we need something like overrideAttrs, but stuff like override should be exposed as (args) -> derivation functions

I think there are probably two main scenarios.

1. Building a small closure with only a few deps.
2. Building a large closure (a full-featured desktop NixOS system with lots of packages installed?)

I think having all-packages.nix probably doesn't hurt 2 much but costs 1 a lot.

In reply to @infinisil:matrix.org
Another idea I played around with is to extend the notion of packages and their versions. One of the goals of it is to clean up handling of versions, aka getting rid of the python, python2, python27, ffmpeg, ffmpeg_full, etc. inconsistencies

In reply to @kevincox:matrix.org
I think we need to provide user overrides. For example I use a custom libvte in my system and it is important to me that all packages pick that up.

Also for overrides I think we can probably handle this basically the same we do today in all-packages.nix for now. We can think about changing those as a different project. For now it could look something like:

# foo.nix
{pkgs}: pkgs.callPackage foo/impl.nix { python = pkgs.python27 }

That isn't the prettiest but allows us to do overrides and maintains the current API. Then I think we can probably clean it up as a separate effort if we wanted too. Unless I am also missing a way that merging both projects returns a better result here.

In reply to @infinisil:matrix.org
As implied with the "full", this can go a bit further, versions don't need to be a single string, but it can be something more abstract. A version could be a combination of: Multiple forks of a project, multiple semantic versions, different variants and more