Call for Discussion: why and how much should we care about the `.override` interfaces? (Part I: Duckstation and PCSX2)

Development Nixpkgs Architecture
4

I’ve made some progress towards changing callPackage here, but pay attention mostly to the first line of hello/package.nix. Before we do anything radical like that PR, I think we need to create a migration path away from the current callPackage definition. The PR shows a possible way to achieve that in makeOverridable (which is basically the half of callPackage where the problem is). It allows a package file to bring its own call package, bootstrapping off the legacy callPackage.

That PR doesn’t actually solve the problem yet, but I think it could be solved with a user facing syntax like:

{ callPackageWithDefaults }: callPackageWithDefaults
({ git_minimal }: { git = git_minimal; })
({
  git 
}:

stdenv.mkDerivation {
  # ...
})

or even

{ callPackageWithDefaults }: callPackageWithDefaults ({
  pkgs,
  git ? pkgs.git_minimal
}:

stdenv.mkDerivation {
  # ...
})

So this would achieve the desired effect of having usable default values defined inside package files, without breaking existing callPackage invocations, and it would provide a path forward for more cleanups, and better support for packages that aren’t typical mkDerivation packages.

4 Likes