Skip to content
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

Open
infinisil opened this issue Jul 18, 2022 · 5 comments
Open

Inconsistent override mechanisms #295046

infinisil opened this issue Jul 18, 2022 · 5 comments
Labels
architecture Relating to code and API architecture of Nixpkgs

Comments

@infinisil
Copy link
Member

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.

@infinisil infinisil changed the title Consistency for override mechanisms Inconsistent override mechanisms Jul 18, 2022
@nbp
Copy link
Member

nbp commented Aug 3, 2022

All override mechanism can be replaced by the update operator //, if we were to move stdenv.mkDerivation to be applied after the fix-point of Nixpkgs.

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

@aameen-tulip
Copy link

This was one I've been working on a lot.
This is my prototype, certainly not perfect but I've been refining it a lot over the last month.
It's comprised of two sorts of recursive attrsets, one for an "entry" ( single package or element ) and entry-sets ( like a package-set or scope ). They share a common base ExtInfo that is an extensible attrset full of functors.
ExtInfo: https://github.com/aameen-tulip/at-node-nix/blob/292ba02b88e3251e3828c257c1c1ce5dd231fe90/lib/meta.nix#L148
metaEnt: https://github.com/aameen-tulip/at-node-nix/blob/292ba02b88e3251e3828c257c1c1ce5dd231fe90/lib/meta.nix#L390
metaSet: https://github.com/aameen-tulip/at-node-nix/blob/292ba02b88e3251e3828c257c1c1ce5dd231fe90/lib/meta.nix#L478

These are used for my Node.js routines that dynamically generate derivations from various types of Node.js metadata ( package[-lock].json, manifest.json, etc ).
https://github.com/aameen-tulip/at-node-nix/blob/224bdf7de6556e36f58b351699062726bf6298bf/pkgs/node-pkg-set.nix#L151 ( this is a branch with a slightly older definition of the "meta" constructs; but it illustrates the usage ).

@roberth
Copy link
Member

roberth commented Dec 12, 2023

Possible approach: #273815

@infinisil infinisil transferred this issue from nixpkgs-architecture/issues Mar 11, 2024
@infinisil infinisil added the architecture Relating to code and API architecture of Nixpkgs label Mar 11, 2024
@nixos-discourse
Copy link

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

@nixos-discourse
Copy link

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/override-derivation-with-overrideattrs-any-way-to-handle-let-in/47307/2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Relating to code and API architecture of Nixpkgs
Projects
None yet
Development

No branches or pull requests

5 participants