doc/python: replace buildEnv usage by withPackages
This commit is contained in:
parent
3bdf167619
commit
bad156a0d5
|
@ -78,18 +78,16 @@ containing
|
||||||
```nix
|
```nix
|
||||||
with import <nixpkgs> {};
|
with import <nixpkgs> {};
|
||||||
|
|
||||||
(pkgs.python35.buildEnv.override {
|
(pkgs.python35.withPackages (ps: [ps.numpy ps.toolz])).env
|
||||||
extraLibs = with pkgs.python35Packages; [ numpy toolz ];
|
|
||||||
}).env
|
|
||||||
```
|
```
|
||||||
executing `nix-shell` gives you again a Nix shell from which you can run Python.
|
executing `nix-shell` gives you again a Nix shell from which you can run Python.
|
||||||
|
|
||||||
What's happening here?
|
What's happening here?
|
||||||
|
|
||||||
1. We begin with importing the Nix Packages collections. `import <nixpkgs>` import the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. Therefore we can now use `pkgs`.
|
1. We begin with importing the Nix Packages collections. `import <nixpkgs>` import the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. Therefore we can now use `pkgs`.
|
||||||
2. Then we create a Python 3.5 environment with `pkgs.buildEnv`. Because we want to use it with a custom set of Python packages, we override it.
|
2. Then we create a Python 3.5 environment with the `withPackages` function.
|
||||||
3. The `extraLibs` argument of the original `buildEnv` function can be used to specify which packages should be included. We want `numpy` and `toolz`. Again, we use the `with` statement to bring a set of attributes into the local scope.
|
3. The `withPackages` function expects us to provide a function as an argument that takes the set of all python packages and returns a list of packages to include in the environment. Here, we select the packages `numpy` and `toolz` from the package set.
|
||||||
4. And finally, for in interactive use we return the environment.
|
4. And finally, for in interactive use we return the environment by using the `env` attribute.
|
||||||
|
|
||||||
### Developing with Python
|
### Developing with Python
|
||||||
|
|
||||||
|
@ -187,10 +185,7 @@ with import <nixpkgs> {};
|
||||||
};
|
};
|
||||||
};
|
};
|
||||||
|
|
||||||
in pkgs.python35.buildEnv.override rec {
|
in pkgs.python35.withPackages (ps: [ps.numpy toolz])
|
||||||
|
|
||||||
extraLibs = [ pkgs.python35Packages.numpy toolz ];
|
|
||||||
}
|
|
||||||
).env
|
).env
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -199,8 +194,11 @@ locally defined package as well as `numpy` which is build according to the
|
||||||
definition in Nixpkgs. What did we do here? Well, we took the Nix expression
|
definition in Nixpkgs. What did we do here? Well, we took the Nix expression
|
||||||
that we used earlier to build a Python environment, and said that we wanted to
|
that we used earlier to build a Python environment, and said that we wanted to
|
||||||
include our own version of `toolz`. To introduce our own package in the scope of
|
include our own version of `toolz`. To introduce our own package in the scope of
|
||||||
`buildEnv.override` we used a
|
`withPackages` we used a
|
||||||
[`let`](http://nixos.org/nix/manual/#sec-constructs) expression.
|
[`let`](http://nixos.org/nix/manual/#sec-constructs) expression.
|
||||||
|
You can see that we used `ps.numpy` to select numpy from the nixpkgs package set (`ps`).
|
||||||
|
But we do not take `toolz` from the nixpkgs package set this time.
|
||||||
|
Instead, `toolz` will resolve to our local definition that we introduced with `let`.
|
||||||
|
|
||||||
### Handling dependencies
|
### Handling dependencies
|
||||||
|
|
||||||
|
@ -359,7 +357,7 @@ own packages. The important functions here are `import` and `callPackage`.
|
||||||
|
|
||||||
### Including a derivation using `callPackage`
|
### Including a derivation using `callPackage`
|
||||||
|
|
||||||
Earlier we created a Python environment using `buildEnv`, and included the
|
Earlier we created a Python environment using `withPackages`, and included the
|
||||||
`toolz` package via a `let` expression.
|
`toolz` package via a `let` expression.
|
||||||
Let's split the package definition from the environment definition.
|
Let's split the package definition from the environment definition.
|
||||||
|
|
||||||
|
@ -394,9 +392,7 @@ with import <nixpkgs> {};
|
||||||
|
|
||||||
( let
|
( let
|
||||||
toolz = pkgs.callPackage ~/path/to/toolz/release.nix { pkgs=pkgs; buildPythonPackage=pkgs.python35Packages.buildPythonPackage; };
|
toolz = pkgs.callPackage ~/path/to/toolz/release.nix { pkgs=pkgs; buildPythonPackage=pkgs.python35Packages.buildPythonPackage; };
|
||||||
in pkgs.python35.buildEnv.override rec {
|
in pkgs.python35.withPackages (ps: [ ps.numpy toolz ])
|
||||||
extraLibs = [ pkgs.python35Packages.numpy toolz ];
|
|
||||||
}
|
|
||||||
).env
|
).env
|
||||||
```
|
```
|
||||||
|
|
||||||
|
@ -450,6 +446,7 @@ Each interpreter has the following attributes:
|
||||||
- `libPrefix`. Name of the folder in `${python}/lib/` for corresponding interpreter.
|
- `libPrefix`. Name of the folder in `${python}/lib/` for corresponding interpreter.
|
||||||
- `interpreter`. Alias for `${python}/bin/${executable}`.
|
- `interpreter`. Alias for `${python}/bin/${executable}`.
|
||||||
- `buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
|
- `buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
|
||||||
|
- `withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
|
||||||
- `sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
|
- `sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
|
||||||
- `executable`. Name of the interpreter executable, ie `python3.4`.
|
- `executable`. Name of the interpreter executable, ie `python3.4`.
|
||||||
|
|
||||||
|
@ -680,9 +677,8 @@ newpkgs = pkgs.overridePackages(self: super: rec {
|
||||||
self = python35Packages // { pandas = python35Packages.pandas.override{name="foo";};};
|
self = python35Packages // { pandas = python35Packages.pandas.override{name="foo";};};
|
||||||
};
|
};
|
||||||
});
|
});
|
||||||
in newpkgs.python35.buildEnv.override{
|
in newpkgs.python35.withPackages (ps: [ps.blaze])
|
||||||
extraLibs = [newpkgs.python35Packages.blaze ];
|
).env
|
||||||
}).env
|
|
||||||
```
|
```
|
||||||
A typical use case is to switch to another version of a certain package. For example, in the Nixpkgs repository we have multiple versions of `django` and `scipy`.
|
A typical use case is to switch to another version of a certain package. For example, in the Nixpkgs repository we have multiple versions of `django` and `scipy`.
|
||||||
In the following example we use a different version of `scipy`. All packages in `newpkgs` will now use the updated `scipy` version.
|
In the following example we use a different version of `scipy`. All packages in `newpkgs` will now use the updated `scipy` version.
|
||||||
|
@ -696,9 +692,8 @@ newpkgs = pkgs.overridePackages(self: super: rec {
|
||||||
self = python35Packages // { scipy = python35Packages.scipy_0_16;};
|
self = python35Packages // { scipy = python35Packages.scipy_0_16;};
|
||||||
};
|
};
|
||||||
});
|
});
|
||||||
in pkgs.python35.buildEnv.override{
|
in newpkgs.python35.withPackages (ps: [ps.blaze])
|
||||||
extraLibs = [newpkgs.python35Packages.blaze ];
|
).env
|
||||||
}).env
|
|
||||||
```
|
```
|
||||||
The requested package `blaze` depends upon `pandas` which itself depends on `scipy`.
|
The requested package `blaze` depends upon `pandas` which itself depends on `scipy`.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue