Add an "addPackages" utility to python buildEnv #97467
Conversation
|
I am against adding this to with import (fetchTarball "channel:nixos-20.03") {};
with python3.pkgs;
let
#env = python3.buildEnv.override {
# extraLibs = [ pytest ];
#};
env = python3.withPackages(ps: with ps; [ pytest ]); # Equivalent to the commented `buildEnv.override`
env2 = env.override (old: {
extraLibs = old.extraLibs ++ [ numpy ];
});
in env2 |
|
Thanks FRidh for reviewing this and for the alternative. I've tried for a few hours to provide a low code-impact replacement based on your suggestion, but what I am coming up with seems to need to something like the following added to I've not got it working, and I need to get on to other things, so I wanted to ask if it is worth pursuing. You said you are against adding this to |
|
I marked this as stale due to inactivity. → More info |
|
FWIW, I really think chained IMO the addition of a separate I was able to make it work using the override of |
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/override-function-no-longer-accepts-parameter-in-python-env/40964/1 |
|
A bit of a follow-up question here. Does anyone know a robust way to check if a Python derivation is already "wrapped", i.e. the result of a # Add packages to a Python environment. Works if you pass something like either
# a) python3
# b) python3.withPackages (ps: [...])
# See https://github.com/NixOS/nixpkgs/pull/97467#issuecomment-689315186
addPackagesToPython =
python: packages:
# TODO: checking python ? "env" by itself stopped working because "env" ended up
# being a key of the base derivation "python3" as well. Is there a robust way
# to determine if this Python is already wrapped?
if python ? "env" && lib.isDerivation python.env then
python.override (old: {
extraLibs = old.extraLibs ++ packages;
})
else
python.withPackages (ps: packages); |
Motivation for this change
This change adds the ability to add packages to an existing python env. That is, if
s1ands2are some functions that select python packages, andpy1 = python.withPackages s1is a python environment, this change allowspy2 = py1.addPackages s2. The resulting environment is the same aspython.withPackages s1-and-s2, wheres1-and-s2is the function that selects the packages froms1ands2.This feature would help provide more modular python environments. I'm developing a nix lib for modular and portable shell environments, env-th. A change such as the one proposed here would allow multiple such shell environments to be merged together.
Things done
I've tested this in the nix repl. Below shows a session where I defined a python environment with
numpyandpyzmqin two ways. The first way,py2a, uses awithPackages. The second way,py2b, uses the new utility. I show in the output below that they return the same derivation.This is a new feature, so there shouldn't be a problem with breaking existing packages. However, it is a change to a very significant feature, so I do expect a lot of scrutiny. For one, there is already a shortcoming in my approach in that it will only
work with environments made with
withPackages. Changing thebuildEnvattribute would need to be targeted otherwise and I haven't found a clean way to do that yet.sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)