You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In nixpkgs today, we have many mkDerivation "helpers" which expose a facade to mkDerivation. Instead of having overrideAttrs just affect the attrs which were passed to mkDerivation, I would instead prefer for the mkDerivation's overrideAttrs to be replaced by the downstream helper.
The goal is to make the interface which was used by an individual to be most reflective of what overrideAttrs would be targeting.
Specifically:
mkDerivation should alias the current .overrideAttrs function to .overrideMkDerivationAttrs
overrideAttrs still exists
"mkDerivation helpers" (e.g. buildPythonPackage) will overwrite .overrideAttrs with their own usage.
They can also expose their specific override attrs as well (E.g. overridePythonAttrs).
The text was updated successfully, but these errors were encountered:
In nixpkgs today, we have many mkDerivation "helpers" which expose a facade to
mkDerivation
. Instead of havingoverrideAttrs
just affect the attrs which were passed tomkDerivation
, I would instead prefer for the mkDerivation'soverrideAttrs
to be replaced by the downstream helper.The goal is to make the interface which was used by an individual to be most reflective of what
overrideAttrs
would be targeting.Specifically:
mkDerivation
should alias the current.overrideAttrs
function to.overrideMkDerivationAttrs
overrideAttrs
still exists.overrideAttrs
with their own usage.overridePythonAttrs
).The text was updated successfully, but these errors were encountered: