-
-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent override mechanisms #295046
Comments
All override mechanism can be replaced by the update operator Making override would be easy within Nixpkgs or within an overlay. On the other hand, these functions would still be required for everybody who want to externally extend Nixpkgs. In which case, it might be preferable to highly recommend overlays as the only mean of extending Nixpkgs with custom packages, rather than extending Nixpkgs externally. See also NixOS/rfcs#3 |
This was one I've been working on a lot. These are used for my Node.js routines that dynamically generate derivations from various types of Node.js metadata ( |
Possible approach: #273815 |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/is-this-the-current-state-of-things/45944/13 |
This issue has been mentioned on NixOS Discourse. There might be relevant details there: |
Issue description
There's too many ways to override packages and they're confusing users. This includes overlays,
.override
,.overrideAttrs
,.extend
,.overrideScope'
,overrideDerivation
,packageOverrides
and probably more, each of which is needed for very specific use cases. Knowing which one is the right one to use is very hard and typically requires reading the nixpkgs source code.Goal
This issue is done when users aren't confused anymore about overrides.
The text was updated successfully, but these errors were encountered: