Merge commit '5d3fd3674a66c5b1ada63e2eace140519849c967'

3 files changed, 21 insertions, 7 deletions

diff --git a/nixpkgs/doc/cross-compilation.xml b/nixpkgs/doc/cross-compilation.xml
index 40cf11304eae..324fe5bdd02a 100644
--- a/nixpkgs/doc/cross-compilation.xml
+++ b/nixpkgs/doc/cross-compilation.xml
@@ -96,7 +96,7 @@
        compiler resulting from a single build can itself only produce binaries
        for a single platform. The task of specifying this single "target
        platform" is thus pushed to build time of the compiler. The root cause of
-       this that the compiler (which will be run on the host) and the standard
+       this is that the compiler (which will be run on the host) and the standard
        library/runtime (which will be run on the target) are built by a single
        build process.
       </para>
diff --git a/nixpkgs/doc/functions/dockertools.xml b/nixpkgs/doc/functions/dockertools.xml
index ff446cbfffdd..2c8eb2cb7743 100644
--- a/nixpkgs/doc/functions/dockertools.xml
+++ b/nixpkgs/doc/functions/dockertools.xml
@@ -47,7 +47,7 @@ buildImage {
 
   contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
   runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
-    #!${stdenv.shell}
+    #!${pkgs.runtimeShell}
     mkdir -p /data
   '';
 
@@ -544,7 +544,7 @@ buildImage {
   name = "shadow-basic";
 
   runAsRoot = ''
-    #!${stdenv.shell}
+    #!${pkgs.runtimeShell}
     ${shadowSetup}
     groupadd -r redis
     useradd -r -g redis redis
diff --git a/nixpkgs/doc/languages-frameworks/python.section.md b/nixpkgs/doc/languages-frameworks/python.section.md
index acd2bf769b0d..1c9f9fdebe42 100644
--- a/nixpkgs/doc/languages-frameworks/python.section.md
+++ b/nixpkgs/doc/languages-frameworks/python.section.md
@@ -602,11 +602,10 @@ as the interpreter unless overridden otherwise.
 All parameters from `stdenv.mkDerivation` function are still supported. The following are specific to `buildPythonPackage`:
 
 * `catchConflicts ? true`: If `true`, abort package build if a package name appears more than once in dependency tree. Default is `true`.
-* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These are added to `buildInputs` when `doCheck = true`.
 * `disabled` ? false: If `true`, package is not build for the particular Python interpreter version.
 * `dontWrapPythonPrograms ? false`: Skip wrapping of python programs.
-* `installFlags ? []`: A list of strings. Arguments to be passed to `pip install`. To pass options to `python setup.py install`, use `--install-option`. E.g., `installFlags=["--install-option='--cpp_implementation'"].
-* `format ? "setuptools"`: Format of the source. Valid options are `"setuptools"`, `"flit"`, `"wheel"`, and `"other"`. `"setuptools"` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. Use `other` when a custom `buildPhase` and/or `installPhase` is needed.
+* `installFlags ? []`: A list of strings. Arguments to be passed to `pip install`. To pass options to `python setup.py install`, use `--install-option`. E.g., `installFlags=["--install-option='--cpp_implementation'"]`.
+* `format ? "setuptools"`: Format of the source. Valid options are `"setuptools"`, `"pyproject"`, `"flit"`, `"wheel"`, and `"other"`. `"setuptools"` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. Use `other` when a custom `buildPhase` and/or `installPhase` is needed.
 * `makeWrapperArgs ? []`: A list of strings. Arguments to be passed to `makeWrapper`, which wraps generated binaries. By default, the arguments to `makeWrapper` set `PATH` and `PYTHONPATH` environment variables before calling the binary. Additional arguments here can allow a developer to set environment variables which will be available when the binary is run. For example, `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
 * `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this defaults to `"python3.5-"` for Python 3.5, etc., and in case of applications to `""`.
 * `pythonPath ? []`: List of packages to be added into `$PYTHONPATH`. Packages in `pythonPath` are not propagated (contrary to `propagatedBuildInputs`).
@@ -615,6 +614,14 @@ All parameters from `stdenv.mkDerivation` function are still supported. The foll
 * `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only created when the filenames end with `.py`.
 * `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command.
 
+The `stdenv.mkDerivation` function accepts various parameters for describing build inputs (see "Specifying dependencies"). The following are of special
+interest for Python packages, either because these are primarily used, or because their behaviour is different:
+
+* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables as well as the items listed in `setup_requires`.
+* `buildInputs ? []`: Build and/or run-time dependencies that need to be be compiled for the host machine. Typically non-Python libraries which are being linked.
+* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These are added to `nativeBuildInputs` when `doCheck = true`. Items listed in `tests_require` go here.
+* `propagatedBuildInputs ? []`: Aside from propagating dependencies, `buildPythonPackage` also injects code into and wraps executables with the paths included in this list. Items listed in `install_requires` go here.
+
 ##### Overriding Python packages
 
 The `buildPythonPackage` function has a `overridePythonAttrs` method that
@@ -874,7 +881,6 @@ example of such a situation is when `py.test` is used.
     '';
   }
   ```
-- Unicode issues can typically be fixed by including `glibcLocales` in `buildInputs` and exporting `LC_ALL=en_US.utf-8`.
 - Tests that attempt to access `$HOME` can be fixed by using the following work-around before running tests (e.g. `preCheck`): `export HOME=$(mktemp -d)`
 
 ## FAQ
@@ -1123,6 +1129,14 @@ LLVM implementation. To use that one instead, Intel recommends users set it with
 Note that `mkl` is only available on `x86_64-{linux,darwin}` platforms;
 moreover, Hydra is not building and distributing pre-compiled binaries using it.
 
+### What inputs do `setup_requires`, `install_requires` and `tests_require` map to?
+
+In a `setup.py` or `setup.cfg` it is common to declare dependencies:
+
+* `setup_requires` corresponds to `nativeBuildInputs`
+* `install_requires` corresponds to `propagatedBuildInputs`
+* `tests_require` corresponds to `checkInputs`
+
 ## Contributing
 
 ### Contributing guidelines