By implementing a single package fixpoint in Nixpkgs, we could have both in the same file. That would make it easier for contributors to see what the pattern is (if they don't know it from Nixpkgs, presumably).
To compare:

• the default value
  • currently an argument in flake.nix
  • afterwards: an attribute in the deps attrset in the package.nix fixpoint (aka this.deps.libseccomp)
• the dependency declaration (not changed much)
  • currently a parameter in package.nix
  • afterwards: parameter in the lambda passed to the mkPackageWithDeps layer in package.nix (example)

Relevant bits of the new package.nix, the way it works in the proof of concept implementation:

{ mkPackageWithDeps, layers }:
mkPackageWithDeps ({ pkgs, stdenv, libseccomp, ... }: [
  (layers.derivation { inherit stdenv; })
  (this: old: {
    name = "nix";
    deps = old.deps // {
      libseccomp = pkgs.libseccomp.overrideAttrs ...;
      # ... more packages that aren't Nixpkgs top level attributes ...
    };
    setup.buildInputs = [ libseccomp ];
    # ... more attributes ...
  }
])

@roberth I do want the package function separate from the choice of dependencies however. These sorts of overrides will always be overfit -- instead of proper declarative things like version bounds and other constraints that characterize the contract/interface required of dependencies, they specify exact versions which fit the implicit, unstated contract.

@Ericson2314 it merely changes the location of the default, but behaves exactly the same (although I have to admit that's not obvious from the example).
You'd still be able to use the current pattern as well, which definitely makes sense to do when a custom package like this libseccomp is used in multiple places in the flake.

@roberth Erm but what is the type of import ./package.nix? (Also we could take this to the Nixpkgs PR.)

Let's move it to the implementation thread.