[RFC 0192] version pins for the pkgs/by-name structure

[quantenzitrone]

Rendered

Sorry if the RFC text is short, i don't know what else to write. The feature is quite simple.

[robsliwi]

Related: NixOS/nixpkgs#421201

[gepbird]

Maybe this is out of scope, but can we also pin dependencies that not just differ in their semantic versions like nodejs = nodejs_22, but have other overrides or logic?
Some example pins.nix:

{
  darwin,
  stdenv,
}@args:
{
  stdenv = if args.stdenv.hostPlatform.isDarwin then darwin.bootstrapStdenv else args.stdenv;
}

{
  luajit,
}@args:
{
  luajit = args.luajit.override { enable52Compat = true; };
}

This would be useful to keep compatibility with previous overrides of a package when removing by-name overrides.

[quantenzitrone]

i think we lose some of the usefulness if we allow that
also like with version pins we can already do that just in the package.nix with let in

[gepbird]

When overriding a package, will it override the the arguments of pins.nix or the arguments of package.nix?
Perhaps it could override package.nix and we could have an overridePins function.

[quantenzitrone]

.override {} overrides the package.nix
why would someone need to override the pins?

package.overridePins {
  dependency_3 = my-dependency_3;
}

would be the same as

package.override {
  dependency = my-dependency_3;
}

[7c6f434c]

I think there is an ambiguity here. Overrides relative to callPackage path/to/package.nix {} are not provided at all, because this would break more than help (and also override works relative to a package that is defined, and the package defined does use pins). You can just override all the pinned stuff one-by-one, though, if for some specific package it makes sense.

[quantenzitrone]

sorry, i don't understand what you are trying to say