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

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

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

In reply to @kevincox:matrix.org

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 @kevincox:matrix.org
At this point how is this different from regular package arguments that can be overridden? Sounds like you can have python.override { version = "2.7" } if we wanted to.

In reply to @profpatsch:augsburg.one
I feel like many people here are rediscovering that an attrset and a function are synonymous things :P

nix-repl> {}
{ }

nix-repl> {} // { hello = "world"; }
{ hello = "world"; }

nix-repl> (a: b: a + b)
«lambda @ (string):1:2»

nix-repl> (a: b: a + b) // { hello = "world"; }
error: value is a function while a set was expected

well they're a bit different