Hi all, It seems the way we currently handle nodePackages has become a bit monolithic, making it very hard to override the stuff that gets generated by npm2nix.
2 simple reasons why one wants to override: - Add an optional dependency (runtime check) - Patch/disable tests (that got enabled by recent prepublish change) The packages themselves are overridable, but there is no clean way to plug those overrides back into "self", other than a cumbersome manual deep-merge through packageOverrides [1]. This is necessary in case you need to fix a dependency that is used by other generated packages. node-packages.nix has a comment line mentioning manual packages could go below it, but those will be overriden (by //) by anything in node-packages-generated.nix and the current "by-spec" and "by-version" attrset structures complicate this even further. I can think of 3 solutions: - provide more hooks in the generated stuff we already do this for "nativeDeps", but we can extend this for optional dependencies, flags and preConfigure hooks. This will work, but gives a lot of dynamic checks and makes the generated sources quite verbose. - store hooks/overrides in npm2nix this is the route that cabal2nix uses. Main issue is that source/logic will be in 2 places and npm2nix itself becomes a cyclic dependency even more. People using an older version of npm2nix might overwrite the customizations any time they add a new package or perform upgrades. - something involving "recursiveUpdate". But the lazy "self" seems to become problematic in case you want to refer to "the original". These solutions feel suboptimal. I think this kind of thing (nested attrset override / looped-back "self") happens more, but the current best practise changed a few times over time. Does anyone know of a way to improve the current situation? Thanks, Mathijs [1] https://github.com/bluescreen303/bluenix/blob/master/pkgs/overrides.nix scroll down to nodePackages. first 2 overrides are just for the sed fix, last one adds 1 optional dependency _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
