Right now, many packages produced with wrappers around stdenv.mkDerivation (like buildRustPackage) effectively cannot be overridden. See, for example, "Is it possible to override cargoSha256 in buildRustPackage?" on the NixOS Discourse instance.
I believe this is a significant issue with the Nixpkgs APIs, especially since it makes it impossible to apply many sorts of (even trivial) overrides and patches to packages without forking Nixpkgs or vendoring the relevant package definitions. I would like any solution to this problem, even an imperfect one, to be made available as soon as possible.
There have been many attempts to fix this, which have (to date) all failed due to reviews not being performed, bikeshedding, or UX issues. Many current attempts have been stalled for more than two years. Something has to change.
Fixing this issue would fix issues like #107070.
Proposed solutions
Individual-finalAttrs
In this approach, an individual helper like buildRustPackage is extended to support overlay-style attributes (finalAttrs), introduced in #119942. This seems to be the preferred approach at the moment (e.g., #194475 (comment)), with some implementations even being merged.
Note that this approach seems to have fairly serious developer experience issues: @amesgen "ran into difficult-to-debug 'infinite recursion' errors when trying to refactor" buildRustPackage to support the finalAttrs style (#194475 (comment)).
Examples:
Generic-finalAttrs
Alternatively, a higher-level helper which enables defining finalAttrs-style stdenv.mkDerivation wrappers with a standard interface can be introduced, and then the "Individual-finalAttrs" approach can be implemented in terms of that new helper.
Example:
Individual-override-attribute
In this approach, a helper like buildRustPackage is extended so that the returned packages include a new attribute (like overrideRust) which acts like overrideAttrs but for the buildRustPackage arguments rather than the stdenv.mkDerivation arguments.
This is the approach taken historically by e.g. the Nixpkgs Python tooling, which provides an overridePythonAttrs attribute on Python packages.
Example:
Generic-override-attribute
Alternatively, a higher-level helper which enables defining "Individual-override-attribute" functions can be introduced. Like "Generic-finalAttrs", this makes it possible to implement the "Individual-override-attribute" approach with the new helper.
Example:
Right now, many packages produced with wrappers around
stdenv.mkDerivation(likebuildRustPackage) effectively cannot be overridden. See, for example, "Is it possible to override cargoSha256 in buildRustPackage?" on the NixOS Discourse instance.I believe this is a significant issue with the Nixpkgs APIs, especially since it makes it impossible to apply many sorts of (even trivial) overrides and patches to packages without forking Nixpkgs or vendoring the relevant package definitions. I would like any solution to this problem, even an imperfect one, to be made available as soon as possible.
There have been many attempts to fix this, which have (to date) all failed due to reviews not being performed, bikeshedding, or UX issues. Many current attempts have been stalled for more than two years. Something has to change.
Fixing this issue would fix issues like #107070.
Proposed solutions
Individual-
finalAttrsIn this approach, an individual helper like
buildRustPackageis extended to support overlay-style attributes (finalAttrs), introduced in #119942. This seems to be the preferred approach at the moment (e.g., #194475 (comment)), with some implementations even being merged.Note that this approach seems to have fairly serious developer experience issues: @amesgen "ran into difficult-to-debug 'infinite recursion' errors when trying to refactor"
buildRustPackageto support thefinalAttrsstyle (#194475 (comment)).Examples:
finalAttrsstyle #194475Generic-
finalAttrsAlternatively, a higher-level helper which enables defining
finalAttrs-stylestdenv.mkDerivationwrappers with a standard interface can be introduced, and then the "Individual-finalAttrs" approach can be implemented in terms of that new helper.Example:
Individual-override-attribute
In this approach, a helper like
buildRustPackageis extended so that the returned packages include a new attribute (likeoverrideRust) which acts likeoverrideAttrsbut for thebuildRustPackagearguments rather than thestdenv.mkDerivationarguments.This is the approach taken historically by e.g. the Nixpkgs Python tooling, which provides an
overridePythonAttrsattribute on Python packages.Example:
Generic-override-attribute
Alternatively, a higher-level helper which enables defining "Individual-override-attribute" functions can be introduced. Like "Generic-
finalAttrs", this makes it possible to implement the "Individual-override-attribute" approach with the new helper.Example: