Merge remote-tracking branch 'nixpkgs/master' into master

3 files changed, 91 insertions, 47 deletions

diff --git a/doc/languages-frameworks/haskell.section.md b/doc/languages-frameworks/haskell.section.md
index be5c7b7c8d1..b485ec583ec 100644
--- a/doc/languages-frameworks/haskell.section.md
+++ b/doc/languages-frameworks/haskell.section.md
@@ -84,37 +84,36 @@ nix-env -qaP -A nixos.haskellPackages
 nix-env -iA nixos.haskellPackages.cabal-install
 ```
 
-Our current default compiler is GHC 7.10.x and the `haskellPackages` set
-contains packages built with that particular version. Nixpkgs contains the
-latest major release of every GHC since 6.10.4, however, and there is a whole
-family of package sets available that defines Hackage packages built with each
-of those compilers, too:
+Our current default compiler is GHC 8.6.x and the `haskellPackages` set
+contains packages built with that particular version. Nixpkgs contains the last
+three major releases of GHC and there is a whole family of package sets
+available that defines Hackage packages built with each of those compilers,
+too:
 ```shell
-nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc6123
-nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc763
+nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc844
+nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc882
 ```
 
 The name `haskellPackages` is really just a synonym for
-`haskell.packages.ghc7102`, because we prefer that package set internally and
+`haskell.packages.ghc865`, because we prefer that package set internally and
 recommend it to our users as their default choice, but ultimately you are free
 to compile your Haskell packages with any GHC version you please. The following
 command displays the complete list of available compilers:
 ```
 $ nix-env -f "<nixpkgs>" -qaP -A haskell.compiler
-haskell.compiler.ghc822                  ghc-8.2.2
-haskell.compiler.integer-simple.ghc822   ghc-8.2.2
+haskell.compiler.ghc8101                 ghc-8.10.0.20191210
+haskell.compiler.integer-simple.ghc8101  ghc-8.10.0.20191210
+haskell.compiler.ghcHEAD                 ghc-8.10.20191119
+haskell.compiler.integer-simple.ghcHEAD  ghc-8.10.20191119
 haskell.compiler.ghc822Binary            ghc-8.2.2-binary
 haskell.compiler.ghc844                  ghc-8.4.4
 haskell.compiler.ghc863Binary            ghc-8.6.3-binary
-haskell.compiler.ghc864                  ghc-8.6.4
-haskell.compiler.integer-simple.ghc864   ghc-8.6.4
 haskell.compiler.ghc865                  ghc-8.6.5
 haskell.compiler.integer-simple.ghc865   ghc-8.6.5
 haskell.compiler.ghc881                  ghc-8.8.1
 haskell.compiler.integer-simple.ghc881   ghc-8.8.1
-haskell.compiler.ghcHEAD                 ghc-8.9.20190601
-haskell.compiler.integer-simple.ghcHEAD  ghc-8.9.20190601
-haskell.compiler.ghcjs84                 ghcjs-8.4.0.1
+haskell.compiler.ghc882                  ghc-8.8.1.20191211
+haskell.compiler.integer-simple.ghc882   ghc-8.8.1.20191211
 haskell.compiler.ghcjs                   ghcjs-8.6.0.1
 ```
 
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index 9cb0e1eecc1..9b6de47c8e8 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -496,8 +496,8 @@ and in this case the `python35` interpreter is automatically used.
 
 ### Interpreters
 
-Versions 2.7, 3.5, 3.6 and 3.7 of the CPython interpreter are available as
-respectively `python27`, `python35`, `python36` and `python37`. The aliases
+Versions 2.7, 3.5, 3.6, 3.7 and 3.8 of the CPython interpreter are available as
+respectively `python27`, `python35`, `python36`, `python37` and `python38`. The aliases
 `python2` and `python3` correspond to respectively `python27` and
 `python37`. The default interpreter, `python`, maps to `python2`. The PyPy
 interpreters compatible with Python 2.7 and 3 are available as `pypy27` and
@@ -821,6 +821,9 @@ should be used with `ignoreCollisions = true`.
 The following are setup hooks specifically for Python packages. Most of these are
 used in `buildPythonPackage`.
 
+- `eggUnpackhook` to move an egg to the correct folder so it can be installed with the `eggInstallHook`
+- `eggBuildHook` to skip building for eggs.
+- `eggInstallHook` to install eggs.
 - `flitBuildHook` to build a wheel using `flit`.
 - `pipBuildHook` to build a wheel using `pip` and PEP 517. Note a build system (e.g. `setuptools` or `flit`) should still be added as `nativeBuildInput`.
 - `pipInstallHook` to install wheels.
@@ -830,6 +833,7 @@ used in `buildPythonPackage`.
 - `pythonRemoveBinBytecode` to remove bytecode from the `/bin` folder.
 - `setuptoolsBuildHook` to build a wheel using `setuptools`.
 - `setuptoolsCheckHook` to run tests with `python setup.py test`.
+- `venvShellHook` to source a Python 3 `venv` at the `venvDir` location. A `venv` is created if it does not yet exist.
 - `wheelUnpackHook` to move a wheel to the correct folder so it can be installed with the `pipInstallHook`.
 
 ### Development mode
@@ -1025,36 +1029,43 @@ If you want to create a Python environment for development, then the recommended
 method is to use `nix-shell`, either with or without the `python.buildEnv`
 function.
 
-### How to consume python modules using pip in a virtualenv like I am used to on other Operating Systems ?
+### How to consume python modules using pip in a virtual environment like I am used to on other Operating Systems?
 
-This is an example of a `default.nix` for a `nix-shell`, which allows to consume a `virtualenv` environment,
+While this approach is not very idiomatic from Nix perspective, it can still be useful when dealing with pre-existing
+projects or in situations where it's not feasible or desired to write derivations for all required dependencies.
+
+This is an example of a `default.nix` for a `nix-shell`, which allows to consume a virtual environment created by `venv`,
 and install python modules through `pip` the traditional way.
 
 Create this `default.nix` file, together with a `requirements.txt` and simply execute `nix-shell`.
 
 ```nix
-with import <nixpkgs> {};
+with import <nixpkgs> { };
 
 let
-  pythonPackages = python27Packages;
-in
-
-stdenv.mkDerivation {
+  pythonPackages = python3Packages;
+in pkgs.mkShell rec {
   name = "impurePythonEnv";
+  venvDir = "./.venv";
+  buildInputs = [
+    # A python interpreter including the 'venv' module is required to bootstrap
+    # the environment.
+    pythonPackages.python
 
-  src = null;
+    # This execute some shell code to initialize a venv in $venvDir before
+    # dropping into the shell
+    pythonPackages.venvShellHook
+
+    # Those are dependencies that we would like to use from nixpkgs, which will
+    # add them to PYTHONPATH and thus make them accessible from within the venv.
+    pythonPackages.numpy
+    pythonPackages.requests
 
-  buildInputs = [
-    # these packages are required for virtualenv and pip to work:
-    #
-    pythonPackages.virtualenv
-    pythonPackages.pip
     # the following packages are related to the dependencies of your python
     # project.
     # In this particular example the python modules listed in the
     # requirements.txt require the following packages to be installed locally
     # in order to compile any binary extensions they may require.
-    #
     taglib
     openssl
     git
@@ -1064,11 +1075,47 @@ stdenv.mkDerivation {
     zlib
   ];
 
+  # Now we can execute any commands within the virtual environment
+  postShellHook = ''
+    pip install -r requirements.txt
+  '';
+
+}
+```
+
+In case the supplied venvShellHook is insufficient, or when python 2 support is needed,
+you can define your own shell hook and adapt to your needs like in the following example:
+
+```nix
+with import <nixpkgs> { };
+
+let
+  venvDir = "./.venv";
+in pkgs.mkShell rec {
+  name = "impurePythonEnv";
+  buildInputs = [
+    python3Packages.python
+    python3Packages.virtualenv
+    ...
+  ];
+
+  # This is very close to how venvShellHook is implemented, but
+  # adapted to use 'virtualenv'
   shellHook = ''
-    # set SOURCE_DATE_EPOCH so that we can use python wheels
     SOURCE_DATE_EPOCH=$(date +%s)
-    virtualenv --python=${pythonPackages.python.interpreter} --no-setuptools venv
-    export PATH=$PWD/venv/bin:$PATH
+
+    if [ -d "${venvDir}" ]; then
+      echo "Skipping venv creation, '${venvDir}' already exists"
+    else
+      echo "Creating new venv environment in path: '${venvDir}'"
+      ${pythonPackages.python.interpreter} -m venv "${venvDir}"
+    fi
+
+    # Under some circumstances it might be necessary to add your virtual
+    # environment to PYTHONPATH, which you can do here too;
+    # PYTHONPATH=$PWD/${venvDir}/${python.sitePackages}/:$PYTHONPATH
+
+    source "${venvDir}/bin/activate"
     pip install -r requirements.txt
   '';
 }
diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md
index 709a0d504cf..3332dff1eb0 100644
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@@ -16,12 +16,6 @@ cargo
 into the `environment.systemPackages` or bring them into
 scope with `nix-shell -p rustc cargo`.
 
-> If you are using NixOS and you want to use rust without a nix expression you
-> probably want to add the following in your `configuration.nix` to build
-> crates with C dependencies.
->
->     environment.systemPackages = [binutils gcc gnumake openssl pkgconfig]
-
 For daily builds (beta and nightly) use either rustup from
 nixpkgs or use the [Rust nightlies
 overlay](#using-the-rust-nightlies-overlay).
@@ -32,17 +26,17 @@ Rust applications are packaged by using the `buildRustPackage` helper from `rust
 
 ```
 rustPlatform.buildRustPackage rec {
-  name = "ripgrep-${version}";
-  version = "0.4.0";
+  pname = "ripgrep";
+  version = "11.0.2";
 
   src = fetchFromGitHub {
     owner = "BurntSushi";
-    repo = "ripgrep";
-    rev = "${version}";
-    sha256 = "0y5d1n6hkw85jb3rblcxqas2fp82h3nghssa4xqrhqnz25l799pj";
+    repo = pname;
+    rev = version;
+    sha256 = "1iga3320mgi7m853la55xip514a3chqsdi1a1rwv25lr9b1p7vd3";
   };
 
-  cargoSha256 = "0q68qyl2h6i0qsz82z840myxlnjay8p1w5z7hfyr8fqp7wgwa9cx";
+  cargoSha256 = "17ldqr3asrdcsh4l29m3b5r37r5d0b3npq1lrgjmxb6vlx6a36qh";
   verifyCargoDeps = true;
 
   meta = with stdenv.lib; {
@@ -66,7 +60,11 @@ added in `cargoPatches` will also be prepended to the patches in `patches` at
 build-time.
 
 When `verifyCargoDeps` is set to `true`, the build will also verify that the
-`cargoSha256` is not out of date by comparing the `Cargo.lock` file in both the `cargoDeps` and `src`. Note that this option changes the value of `cargoSha256` since it also copies the `Cargo.lock` in it. To avoid breaking backward-compatibility this option is not enabled by default but hopefully will be in the future.
+`cargoSha256` is not out of date by comparing the `Cargo.lock` file in both the
+`cargoDeps` and `src`. Note that this option changes the value of `cargoSha256`
+since it also copies the `Cargo.lock` in it. To avoid breaking
+backward-compatibility this option is not enabled by default but hopefully will
+be in the future.
 
 ### Building a crate for a different target