Option or default to prefer existing python packages from nixpkgs
Closed this issue · 1 comments
At first, I must thank you about pip2nix. I've been trying many generators and even had my own years ago, but pip2nix seems to fit me best, because it allows reusing existing python package derivations from nixpkgs.
I wonder, is there any reason to not always prefer the existing nixpkgs derivation when a derivation with matching name could be found, only to override it with updated sources?
For example, in my overrides, I need to manually reuse the existing derivation to get pip2nix generated versions of "hard to build" packages:
self: super: {
pillow = pythonPackages.pillow.overrideDerivation(old:
with super.pillow; { inherit name src; }
);
setuptools being an exception to avoid collisions
self: super: {
setuptools = pythonPackages.setuptools;
}
Have you thought about this before? I'm not sure, what would the best approach. Possibly this could be done just by adding a re-using logic into requirements.nix, but that would definitely make it more complex and ugly...
The current situation is not bad, it's just that I have to manually write / reuse overrides that could be automatically avoided by reusing the existing expressions.
I tried this out and decide to close this for now.
Defaulting to
self: super: {
pillow = pythonPackages.pillow.overrideDerivation(old:
with super.pillow; { inherit name src; }
);
expressions would indeed solve many missing buildInputs and otherwise broken packages automatically without manual overrides, but could lead to hard-to-debug collision issues (when e.g. package implicitly used from pythonPackages would require "pytestrunner" and generated requirements defines "pytest-runner" with different version).
There are easier to debug when exiting packages are reused explicitly in custom overrides.