Merge remote-tracking branch 'upstream/master' into staging

8 files changed, 267 insertions, 521 deletions

diff --git a/doc/languages-frameworks/go.section.md b/doc/languages-frameworks/go.section.md
new file mode 100644
index 0000000000000..b4228d9d313d9
--- /dev/null
+++ b/doc/languages-frameworks/go.section.md
@@ -0,0 +1,140 @@
+# Go {#sec-language-go}
+
+## Go modules {#ssec-language-go}
+
+The function `buildGoModule` builds Go programs managed with Go modules. It builds a [Go Modules](https://github.com/golang/go/wiki/Modules) through a two phase build:
+
+- An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
+- A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
+
+### Example for `buildGoModule` {#ex-buildGoModule}
+
+In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
+
+- `vendorSha256`: is the hash of the output of the intermediate fetcher derivation. `vendorSha256` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorSha256 = null;`
+- `runVend`: runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
+
+```nix
+pet = buildGoModule rec {
+  pname = "pet";
+  version = "0.3.4";
+
+  src = fetchFromGitHub {
+    owner = "knqyf263";
+    repo = "pet";
+    rev = "v${version}";
+    sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
+  };
+
+  vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j";
+
+  runVend = true;
+
+  meta = with lib; {
+    description = "Simple command-line snippet manager, written in Go";
+    homepage = "https://github.com/knqyf263/pet";
+    license = licenses.mit;
+    maintainers = with maintainers; [ kalbasit ];
+    platforms = platforms.linux ++ platforms.darwin;
+  };
+}
+```
+
+## `buildGoPackage` (legacy) {#ssec-go-legacy}
+
+The function `buildGoPackage` builds legacy Go programs, not supporting Go modules.
+
+### Example for `buildGoPackage`
+
+In the following is an example expression using buildGoPackage, the following arguments are of special significance to the function:
+
+- `goPackagePath` specifies the package's canonical Go import path.
+- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
+
+```nix
+deis = buildGoPackage rec {
+  pname = "deis";
+  version = "1.13.0";
+
+  goPackagePath = "github.com/deis/deis";
+
+  src = fetchFromGitHub {
+    owner = "deis";
+    repo = "deis";
+    rev = "v${version}";
+    sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
+  };
+
+  goDeps = ./deps.nix;
+}
+```
+
+The `goDeps` attribute can be imported from a separate `nix` file that defines which Go libraries are needed and should be included in `GOPATH` for `buildPhase`:
+
+```nix
+# deps.nix
+[ # goDeps is a list of Go dependencies.
+  {
+    # goPackagePath specifies Go package import path.
+    goPackagePath = "gopkg.in/yaml.v2";
+    fetch = {
+      # `fetch type` that needs to be used to get package source.
+      # If `git` is used there should be `url`, `rev` and `sha256` defined next to it.
+      type = "git";
+      url = "https://gopkg.in/yaml.v2";
+      rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
+      sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
+    };
+  }
+  {
+    goPackagePath = "github.com/docopt/docopt-go";
+    fetch = {
+      type = "git";
+      url = "https://github.com/docopt/docopt-go";
+      rev = "784ddc588536785e7299f7272f39101f7faccc3f";
+      sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
+    };
+  }
+]
+```
+
+To extract dependency information from a Go package in automated way use [go2nix](https://github.com/kamilchm/go2nix). It can produce complete derivation and `goDeps` file for Go programs.
+
+You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
+
+```bash
+for p in $NIX_PROFILES; do
+    GOPATH="$p/share/go:$GOPATH"
+done
+```
+
+## Attributes used by the builders {#ssec-go-common-attributes}
+
+Both `buildGoModule` and `buildGoPackage` can be tweaked to behave slightly differently, if the following attributes are used:
+
+### `buildFlagsArray` and `buildFlags`: {#ex-goBuildFlags-noarray}
+
+These attributes set build flags supported by `go build`. We recommend using `buildFlagsArray`. The most common use case of these attributes is to make the resulting executable aware of its own version. For example:
+
+```nix
+  buildFlagsArray = [
+    # Note: single quotes are not needed.
+    "-ldflags=-X main.Version=${version} -X main.Commit=${version}"
+  ];
+```
+
+```nix
+  buildFlagsArray = ''
+    -ldflags=
+    -X main.Version=${version}
+    -X main.Commit=${version}
+  '';
+```
+
+### `deleteVendor` {#var-go-deleteVendor}
+
+Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
+
+### `subPackages` {#var-go-subPackages}
+
+Limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
diff --git a/doc/languages-frameworks/go.xml b/doc/languages-frameworks/go.xml
deleted file mode 100644
index ebdcf616054c2..0000000000000
--- a/doc/languages-frameworks/go.xml
+++ /dev/null
@@ -1,248 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-language-go">
- <title>Go</title>
-
- <section xml:id="ssec-go-modules">
-  <title>Go modules</title>
-
-  <para>
-   The function <varname> buildGoModule </varname> builds Go programs managed with Go modules. It builds a <link xlink:href="https://github.com/golang/go/wiki/Modules">Go modules</link> through a two phase build:
-   <itemizedlist>
-    <listitem>
-     <para>
-      An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
-     </para>
-    </listitem>
-    <listitem>
-     <para>
-      A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
-     </para>
-    </listitem>
-   </itemizedlist>
-  </para>
-
-  <example xml:id='ex-buildGoModule'>
-   <title>buildGoModule</title>
-<programlisting>
-pet = buildGoModule rec {
-  pname = "pet";
-  version = "0.3.4";
-
-  src = fetchFromGitHub {
-    owner = "knqyf263";
-    repo = "pet";
-    rev = "v${version}";
-    sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
-  };
-
-  vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j"; <co xml:id='ex-buildGoModule-1' />
-
-  runVend = true; <co xml:id='ex-buildGoModule-2' />
-
-  meta = with lib; {
-    description = "Simple command-line snippet manager, written in Go";
-    homepage = "https://github.com/knqyf263/pet";
-    license = licenses.mit;
-    maintainers = with maintainers; [ kalbasit ];
-    platforms = platforms.linux ++ platforms.darwin;
-  };
-}
-</programlisting>
-  </example>
-
-  <para>
-   <xref linkend='ex-buildGoModule'/> is an example expression using buildGoModule, the following arguments are of special significance to the function:
-   <calloutlist>
-    <callout arearefs='ex-buildGoModule-1'>
-     <para>
-      <varname>vendorSha256</varname> is the hash of the output of the intermediate fetcher derivation.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoModule-2'>
-     <para>
-      <varname>runVend</varname> runs the vend command to generate the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build.
-     </para>
-    </callout>
-   </calloutlist>
-  </para>
-
-  <para>
-   <varname>vendorSha256</varname> can also take <varname>null</varname> as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set 'vendorSha256 = null;'
-  </para>
- </section>
-
- <section xml:id="ssec-go-legacy">
-  <title>Go legacy</title>
-
-  <para>
-   The function <varname> buildGoPackage </varname> builds legacy Go programs, not supporting Go modules.
-  </para>
-
-  <example xml:id='ex-buildGoPackage'>
-   <title>buildGoPackage</title>
-<programlisting>
-deis = buildGoPackage rec {
-  pname = "deis";
-  version = "1.13.0";
-
-  goPackagePath = "github.com/deis/deis"; <co xml:id='ex-buildGoPackage-1' />
-
-  src = fetchFromGitHub {
-    owner = "deis";
-    repo = "deis";
-    rev = "v${version}";
-    sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
-  };
-
-  goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-2' />
-}
-</programlisting>
-  </example>
-
-  <para>
-   <xref linkend='ex-buildGoPackage'/> is an example expression using buildGoPackage, the following arguments are of special significance to the function:
-   <calloutlist>
-    <callout arearefs='ex-buildGoPackage-1'>
-     <para>
-      <varname>goPackagePath</varname> specifies the package's canonical Go import path.
-     </para>
-    </callout>
-    <callout arearefs='ex-buildGoPackage-2'>
-     <para>
-      <varname>goDeps</varname> is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate <varname>deps.nix</varname> file for readability. The dependency data structure is described below.
-     </para>
-    </callout>
-   </calloutlist>
-  </para>
-
-  <para>
-   The <varname>goDeps</varname> attribute can be imported from a separate <varname>nix</varname> file that defines which Go libraries are needed and should be included in <varname>GOPATH</varname> for <varname>buildPhase</varname>.
-  </para>
-
-  <example xml:id='ex-goDeps'>
-   <title>deps.nix</title>
-<programlisting>
-[ <co xml:id='ex-goDeps-1' />
-  {
-    goPackagePath = "gopkg.in/yaml.v2"; <co xml:id='ex-goDeps-2' />
-    fetch = {
-      type = "git"; <co xml:id='ex-goDeps-3' />
-      url = "https://gopkg.in/yaml.v2";
-      rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
-      sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
-    };
-  }
-  {
-    goPackagePath = "github.com/docopt/docopt-go";
-    fetch = {
-      type = "git";
-      url = "https://github.com/docopt/docopt-go";
-      rev = "784ddc588536785e7299f7272f39101f7faccc3f";
-      sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
-    };
-  }
-]
-</programlisting>
-  </example>
-
-  <para>
-   <calloutlist>
-    <callout arearefs='ex-goDeps-1'>
-     <para>
-      <varname>goDeps</varname> is a list of Go dependencies.
-     </para>
-    </callout>
-    <callout arearefs='ex-goDeps-2'>
-     <para>
-      <varname>goPackagePath</varname> specifies Go package import path.
-     </para>
-    </callout>
-    <callout arearefs='ex-goDeps-3'>
-     <para>
-      <varname>fetch type</varname> that needs to be used to get package source. If <varname>git</varname> is used there should be <varname>url</varname>, <varname>rev</varname> and <varname>sha256</varname> defined next to it.
-     </para>
-    </callout>
-   </calloutlist>
-  </para>
-
-  <para>
-   To extract dependency information from a Go package in automated way use <link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can produce complete derivation and <varname>goDeps</varname> file for Go programs.
-  </para>
-
-  <para>
-   You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
-<screen>
-for p in $NIX_PROFILES; do
-    GOPATH="$p/share/go:$GOPATH"
-done
-</screen>
-  </para>
- </section>
-
- <section xml:id="ssec-go-common-attributes">
-  <title>Attributes used by the builders</title>
-
-  <para>
-   Both <link xlink:href="#ssec-go-modules"><varname>buildGoModule</varname></link> and <link xlink:href="#ssec-go-modules"><varname>buildGoPackage</varname></link> can be tweaked to behave slightly differently, if the following attributes are used:
-  </para>
-
-  <variablelist>
-   <varlistentry xml:id="var-go-buildFlagsArray">
-    <term>
-     <varname>buildFlagsArray</varname> and <varname>buildFlags</varname>
-    </term>
-    <listitem>
-     <para>
-      These attributes set build flags supported by <varname>go build</varname>. We recommend using <varname>buildFlagsArray</varname>. The most common use case of these attributes is to make the resulting executable aware of its own version. For example:
-     </para>
-     <example xml:id='ex-goBuildFlags-nospaces'>
-      <title>buildFlagsArray</title>
-<programlisting>
-  buildFlagsArray = [
-    "-ldflags=-X main.Version=${version} -X main.Commit=${version}" <co xml:id='ex-goBuildFlags-1' />
-  ];
-</programlisting>
-     </example>
-     <calloutlist>
-      <callout arearefs='ex-goBuildFlags-1'>
-       <para>
-        Note: single quotes are not needed.
-       </para>
-      </callout>
-     </calloutlist>
-     <example xml:id='ex-goBuildFlags-noarray'>
-      <title>buildFlagsArray</title>
-<programlisting>
-  buildFlagsArray = ''
-    -ldflags=
-    -X main.Version=${version}
-    -X main.Commit=${version}
-  '';
-</programlisting>
-     </example>
-    </listitem>
-   </varlistentry>
-   <varlistentry xml:id="var-go-deleteVendor">
-    <term>
-     <varname>deleteVendor</varname>
-    </term>
-    <listitem>
-     <para>
-      Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
-     </para>
-    </listitem>
-   </varlistentry>
-   <varlistentry xml:id="var-go-subPackages">
-    <term>
-     <varname>subPackages</varname>
-    </term>
-    <listitem>
-     <para>
-      Limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
-     </para>
-    </listitem>
-   </varlistentry>
-  </variablelist>
- </section>
-</section>
diff --git a/doc/languages-frameworks/index.xml b/doc/languages-frameworks/index.xml
index 300c4cd2687a8..7a4c54fca8d03 100644
--- a/doc/languages-frameworks/index.xml
+++ b/doc/languages-frameworks/index.xml
@@ -13,7 +13,7 @@
  <xi:include href="crystal.section.xml" />
  <xi:include href="emscripten.section.xml" />
  <xi:include href="gnome.xml" />
- <xi:include href="go.xml" />
+ <xi:include href="go.section.xml" />
  <xi:include href="haskell.section.xml" />
  <xi:include href="idris.section.xml" />
  <xi:include href="ios.section.xml" />
@@ -27,7 +27,7 @@
  <xi:include href="python.section.xml" />
  <xi:include href="qt.xml" />
  <xi:include href="r.section.xml" />
- <xi:include href="ruby.xml" />
+ <xi:include href="ruby.section.xml" />
  <xi:include href="rust.section.xml" />
  <xi:include href="texlive.xml" />
  <xi:include href="titanium.section.xml" />
diff --git a/doc/languages-frameworks/python.section.md b/doc/languages-frameworks/python.section.md
index 59f7389b9ad3c..8a2fe2711c7a6 100644
--- a/doc/languages-frameworks/python.section.md
+++ b/doc/languages-frameworks/python.section.md
@@ -153,7 +153,7 @@ The dot product of [1 2] and [3 4] is: 11
 But if we maintain the script ourselves, and if there are more dependencies, it
 may be nice to encode those dependencies in source to make the script re-usable
 without that bit of knowledge. That can be done by using `nix-shell` as a
-[shebang](https://en.wikipedia.org/wiki/Shebang_(Unix), like so:
+[shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)), like so:
 
 ```python
 #!/usr/bin/env nix-shell
diff --git a/doc/languages-frameworks/ruby.section.md b/doc/languages-frameworks/ruby.section.md
index e4c4ffce04325..e292b3110ff4c 100644
--- a/doc/languages-frameworks/ruby.section.md
+++ b/doc/languages-frameworks/ruby.section.md
@@ -1,74 +1,38 @@
----
-title: Ruby
-author: Michael Fellinger
-date: 2019-05-23
----
+# Ruby {#sec-language-ruby}
 
-# Ruby
+## Using Ruby
 
-## User Guide
+Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The attribute `ruby` refers to the default Ruby interpreter, which is currently MRI 2.6. It's also possible to refer to specific versions, e.g. `ruby_2_y`, `jruby`, or `mruby`.
 
-### Using Ruby
+In the Nixpkgs tree, Ruby packages can be found throughout, depending on what they do, and are called from the main package set. Ruby gems, however are separate sets, and there's one default set for each interpreter (currently MRI only).
 
-#### Overview
+There are two main approaches for using Ruby with gems. One is to use a specifically locked `Gemfile` for an application that has very strict dependencies. The other is to depend on the common gems, which we'll explain further down, and rely on them being updated regularly.
 
-Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby.
-The attribute `ruby` refers to the default Ruby interpreter, which is currently
-MRI 2.5. It's also possible to refer to specific versions, e.g. `ruby_2_6`, `jruby`, or `mruby`.
+The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_2_6.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
 
-In the nixpkgs tree, Ruby packages can be found throughout, depending on what
-they do, and are called from the main package set. Ruby gems, however are
-separate sets, and there's one default set for each interpreter (currently MRI
-only).
+Since not all gems have executables like `nokogiri`, it's usually more convenient to use the `withPackages` function like this: `ruby.withPackages (p: with p; [ nokogiri ])`. This will also make sure that the Ruby in your environment will be able to find the gem and it can be used in your Ruby code (for example via `ruby` or `irb` executables) via `require "nokogiri"` as usual.
 
-There are two main approaches for using Ruby with gems.
-One is to use a specifically locked `Gemfile` for an application that has very strict dependencies.
-The other is to depend on the common gems, which we'll explain further down, and
-rely on them being updated regularly.
+### Temporary Ruby environment with `nix-shell`
 
-The interpreters have common attributes, namely `gems`, and `withPackages`. So
-you can refer to `ruby.gems.nokogiri`, or `ruby_2_5.gems.nokogiri` to get the
-Nokogiri gem already compiled and ready to use.
+Rather than having a single Ruby environment shared by all Ruby development projects on a system, Nix allows you to create separate environments per project. `nix-shell` gives you the possibility to temporarily load another environment akin to a combined `chruby` or `rvm` and `bundle exec`.
 
-Since not all gems have executables like `nokogiri`, it's usually more
-convenient to use the `withPackages` function like this:
-`ruby.withPackages (p: with p; [ nokogiri ])`. This will also make sure that the
-Ruby in your environment will be able to find the gem and it can be used in your
-Ruby code (for example via `ruby` or `irb` executables) via `require "nokogiri"`
-as usual.
+There are two methods for loading a shell with Ruby packages. The first and recommended method is to create an environment with `ruby.withPackages` and load that.
 
-#### Temporary Ruby environment with `nix-shell`
-
-Rather than having a single Ruby environment shared by all Ruby
-development projects on a system, Nix allows you to create separate
-environments per project.  `nix-shell` gives you the possibility to
-temporarily load another environment akin to a combined `chruby` or
-`rvm` and `bundle exec`.
-
-There are two methods for loading a shell with Ruby packages. The first and
-recommended method is to create an environment with `ruby.withPackages` and load
-that.
-
-```shell
-nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
+```ShellSession
+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
 ```
 
-The other method, which is not recommended, is to create an environment and list
-all the packages directly.
+The other method, which is not recommended, is to create an environment and list all the packages directly.
 
-```shell
-nix-shell -p ruby.gems.nokogiri ruby.gems.pry
+```ShellSession
+$ nix-shell -p ruby.gems.nokogiri ruby.gems.pry
 ```
 
-Again, it's possible to launch the interpreter from the shell. The Ruby
-interpreter has the attribute `gems` which contains all Ruby gems for that
-specific interpreter.
+Again, it's possible to launch the interpreter from the shell. The Ruby interpreter has the attribute `gems` which contains all Ruby gems for that specific interpreter.
 
-##### Load environment from `.nix` expression
+#### Load Ruby environment from `.nix` expression
 
-As explained in the Nix manual, `nix-shell` can also load an expression from a
-`.nix` file. Say we want to have Ruby 2.5, `nokogori`, and `pry`. Consider a
-`shell.nix` file with:
+As explained in the Nix manual, `nix-shell` can also load an expression from a `.nix` file. Say we want to have Ruby 2.6, `nokogori`, and `pry`. Consider a `shell.nix` file with:
 
 ```nix
 with import <nixpkgs> {};
@@ -77,43 +41,33 @@ ruby.withPackages (ps: with ps; [ nokogiri pry ])
 
 What's happening here?
 
-1. We begin with importing the Nix Packages collections. `import <nixpkgs>`
-   imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
-   brings all attributes of `nixpkgs` in the local scope. These attributes form
-   the main package set.
+1. We begin with importing the Nix Packages collections. `import <nixpkgs>` imports the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. These attributes form the main package set.
 2. Then we create a Ruby environment with the `withPackages` function.
-3. The `withPackages` function expects us to provide a function as an argument
-   that takes the set of all ruby gems and returns a list of packages to include
-   in the environment. Here, we select the packages `nokogiri` and `pry` from
-   the package set.
+3. The `withPackages` function expects us to provide a function as an argument that takes the set of all ruby gems and returns a list of packages to include in the environment. Here, we select the packages `nokogiri` and `pry` from the package set.
 
-##### Execute command with `--run`
+#### Execute command with `--run`
 
-A convenient flag for `nix-shell` is `--run`. It executes a command in the
-`nix-shell`. We can e.g. directly open a `pry` REPL:
+A convenient flag for `nix-shell` is `--run`. It executes a command in the `nix-shell`. We can e.g. directly open a `pry` REPL:
 
-```shell
-nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry"
+```ShellSession
+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry"
 ```
 
 Or immediately require `nokogiri` in pry:
 
-```shell
-nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri"
+```ShellSession
+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri"
 ```
 
 Or run a script using this environment:
 
-```shell
-nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb"
+```ShellSession
+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb"
 ```
 
-##### Using `nix-shell` as shebang
+#### Using `nix-shell` as shebang
 
-In fact, for the last case, there is a more convenient method. You can add a
-[shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) to your script
-specifying which dependencies `nix-shell` needs. With the following shebang, you
-can just execute `./example.rb`, and it will run with all dependencies.
+In fact, for the last case, there is a more convenient method. You can add a [shebang](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) to your script specifying which dependencies `nix-shell` needs. With the following shebang, you can just execute `./example.rb`, and it will run with all dependencies.
 
 ```ruby
 #! /usr/bin/env nix-shell
@@ -126,35 +80,24 @@ body = RestClient.get('http://example.com').body
 puts Nokogiri::HTML(body).at('h1').text
 ```
 
-### Developing with Ruby
+## Developing with Ruby
 
-#### Using an existing Gemfile
+### Using an existing Gemfile
 
-In most cases, you'll already have a `Gemfile.lock` listing all your dependencies.
-This can be used to generate a `gemset.nix` which is used to fetch the gems and
-combine them into a single environment.
-The reason why you need to have a separate file for this, is that Nix requires
-you to have a checksum for each input to your build.
-Since the `Gemfile.lock` that `bundler` generates doesn't provide us with
-checksums, we have to first download each gem, calculate its SHA256, and store
-it in this separate file.
+In most cases, you'll already have a `Gemfile.lock` listing all your dependencies. This can be used to generate a `gemset.nix` which is used to fetch the gems and combine them into a single environment. The reason why you need to have a separate file for this, is that Nix requires you to have a checksum for each input to your build. Since the `Gemfile.lock` that `bundler` generates doesn't provide us with checksums, we have to first download each gem, calculate its SHA256, and store it in this separate file.
 
 So the steps from having just a `Gemfile` to a `gemset.nix` are:
 
-```shell
-bundle lock
-bundix
+```ShellSession
+$ bundle lock
+$ bundix
 ```
 
-If you already have a `Gemfile.lock`, you can simply run `bundix` and it will
-work the same.
+If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.
 
-To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag,
-which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent
-time of modification.
+To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.
 
-Once the `gemset.nix` is generated, it can be used in a
-`bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
+Once the `gemset.nix` is generated, it can be used in a `bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
 
 ```nix
 # ...
@@ -166,41 +109,26 @@ let
 in mkShell { buildInputs = [ gems gems.wrappedRuby ]; }
 ```
 
-With this file in your directory, you can run `nix-shell` to build and use the gems.
-The important parts here are `bundlerEnv` and `wrappedRuby`.
+With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.
 
-The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that
-all the `/lib` and `/bin` directories will be available, and the executables of
-all gems (even of indirect dependencies) will end up in your `$PATH`.
-The `wrappedRuby` provides you with all executables that come with Ruby itself,
-but wrapped so they can easily find the gems in your gemset.
+The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
 
-One common issue that you might have is that you have Ruby 2.6, but also
-`bundler` in your gemset. That leads to a conflict for `/bin/bundle` and
-`/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems
-in a `lowPrio` call. So in order to give the `bundler` from your gemset
-priority, it would be used like this:
+One common issue that you might have is that you have Ruby 2.6, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
 
 ```nix
 # ...
 mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
 ```
 
+### Gem-specific configurations and workarounds
 
-#### Gem-specific configurations and workarounds
+In some cases, especially if the gem has native extensions, you might need to modify the way the gem is built.
 
-In some cases, especially if the gem has native extensions, you might need to
-modify the way the gem is built.
+This is done via a common configuration file that includes all of the workarounds for each gem.
 
-This is done via a common configuration file that includes all of the
-workarounds for each gem.
+This file lives at `/pkgs/development/ruby-modules/gem-config/default.nix`, since it already contains a lot of entries, it should be pretty easy to add the modifications you need for your needs.
 
-This file lives at `/pkgs/development/ruby-modules/gem-config/default.nix`,
-since it already contains a lot of entries, it should be pretty easy to add the
-modifications you need for your needs.
-
-In the meanwhile, or if the modification is for a private gem, you can also add
-the configuration to only your own environment.
+In the meanwhile, or if the modification is for a private gem, you can also add the configuration to only your own environment.
 
 Two places that allow this modification are the `ruby` derivation, or `bundlerEnv`.
 
@@ -261,10 +189,9 @@ let
 in pkgs.ruby.withPackages (ps: with ps; [ pg ])
 ```
 
-Then we can get whichever postgresql version we desire and the `pg` gem will
-always reference it correctly:
+Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:
 
-```shell
+```ShellSession
 $ nix-shell --argstr pg_version 9_4 --run 'ruby -rpg -e "puts PG.library_version"'
 90421
 
@@ -272,24 +199,15 @@ $ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
 100007
 ```
 
-Of course for this use-case one could also use overlays since the configuration
-for `pg` depends on the `postgresql` alias, but for demonstration purposes this
-has to suffice.
+Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
 
-#### Adding a gem to the default gemset
+### Adding a gem to the default gemset
 
-Now that you know how to get a working Ruby environment with Nix, it's time to
-go forward and start actually developing with Ruby.
-We will first have a look at how Ruby gems are packaged on Nix. Then, we will
-look at how you can use development mode with your code.
+Now that you know how to get a working Ruby environment with Nix, it's time to go forward and start actually developing with Ruby. We will first have a look at how Ruby gems are packaged on Nix. Then, we will look at how you can use development mode with your code.
 
-All gems in the standard set are automatically generated from a single
-`Gemfile`. The dependency resolution is done with `bundler` and makes it more
-likely that all gems are compatible to each other.
+All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible to each other.
 
-In order to add a new gem to nixpkgs, you can put it into the
-`/pkgs/development/ruby-modules/with-packages/Gemfile` and run
-`./maintainers/scripts/update-ruby-packages`.
+In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
 
 To test that it works, you can then try using the gem with:
 
@@ -297,16 +215,11 @@ To test that it works, you can then try using the gem with:
 NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-your-gem ])"
 ```
 
-#### Packaging applications
+### Packaging applications
 
-A common task is to add a ruby executable to nixpkgs, popular examples would be
-`chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp`
-function, that allows you to make a package that only exposes the listed
-executables, otherwise the package may cause conflicts through common paths like
-`bin/rake` or `bin/bundler` that aren't meant to be used.
+A common task is to add a ruby executable to nixpkgs, popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables, otherwise the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
 
-The absolute easiest way to do that is to write a
-`Gemfile` along these lines:
+The absolute easiest way to do that is to write a `Gemfile` along these lines:
 
 ```ruby
 source 'https://rubygems.org' do
@@ -314,10 +227,7 @@ source 'https://rubygems.org' do
 end
 ```
 
-If you want to package a specific version, you can use the standard Gemfile
-syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable
-version anyway, it's easier to update by simply running the `bundle lock` and
-`bundix` steps again.
+If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.
 
 Now you can also also make a `default.nix` that looks like this:
 
@@ -331,20 +241,15 @@ bundlerApp {
 }
 ```
 
-All that's left to do is to generate the corresponding `Gemfile.lock` and
-`gemset.nix` as described above in the `Using an existing Gemfile` section.
+All that's left to do is to generate the corresponding `Gemfile.lock` and `gemset.nix` as described above in the `Using an existing Gemfile` section.
 
-##### Packaging executables that require wrapping
+#### Packaging executables that require wrapping
 
-Sometimes your app will depend on other executables at runtime, and tries to
-find it through the `PATH` environment variable.
+Sometimes your app will depend on other executables at runtime, and tries to find it through the `PATH` environment variable.
 
-In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the
-gem in another script that prefixes the `PATH`.
+In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
 
-Of course you could also make a custom `gemConfig` if you know exactly how to
-patch it, but it's usually much easier to maintain with a simple wrapper so the
-patch doesn't have to be adjusted for each version.
+Of course you could also make a custom `gemConfig` if you know exactly how to patch it, but it's usually much easier to maintain with a simple wrapper so the patch doesn't have to be adjusted for each version.
 
 Here's another example:
 
diff --git a/doc/languages-frameworks/ruby.xml b/doc/languages-frameworks/ruby.xml
deleted file mode 100644
index 9b579d6804f44..0000000000000
--- a/doc/languages-frameworks/ruby.xml
+++ /dev/null
@@ -1,107 +0,0 @@
-<section xmlns="http://docbook.org/ns/docbook"
-         xmlns:xlink="http://www.w3.org/1999/xlink"
-         xml:id="sec-language-ruby">
- <title>Ruby</title>
-
- <para>
-  There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.
- </para>
-
- <para>
-  For example, to package sensu, we did:
- </para>
-
-<screen>
-<prompt>$ </prompt>cd pkgs/servers/monitoring
-<prompt>$ </prompt>mkdir sensu
-<prompt>$ </prompt>cd sensu
-<prompt>$ </prompt>cat > Gemfile
-source 'https://rubygems.org'
-gem 'sensu'
-<prompt>$ </prompt>$(nix-build '&lt;nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
-<prompt>$ </prompt>cat > default.nix
-{ lib, bundlerEnv, ruby }:
-
-bundlerEnv rec {
-  name = "sensu-${version}";
-
-  version = (import gemset).sensu.version;
-  inherit ruby;
-  # expects Gemfile, Gemfile.lock and gemset.nix in the same directory
-  gemdir = ./.;
-
-  meta = with lib; {
-    description = "A monitoring framework that aims to be simple, malleable, and scalable";
-    homepage    = "http://sensuapp.org/";
-    license     = with licenses; mit;
-    maintainers = with maintainers; [ theuni ];
-    platforms   = platforms.unix;
-  };
-}
-</screen>
-
- <para>
-  Please check in the <filename>Gemfile</filename>, <filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily.
- </para>
-
- <para>
-  Updating Ruby packages can then be done like this:
- </para>
-
-<screen>
-<prompt>$ </prompt>cd pkgs/servers/monitoring/sensu
-<prompt>$ </prompt>nix-shell -p bundler --run 'bundle lock --update'
-<prompt>$ </prompt>nix-shell -p bundix --run 'bundix'
-</screen>
-
- <para>
-  For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
- </para>
-
-<programlisting>
-<![CDATA[{ lib, bundlerApp }:
-
-bundlerApp {
-  pname = "corundum";
-  gemdir = ./.;
-  exes = [ "corundum-skel" ];
-
-  meta = with lib; {
-    description = "Tool and libraries for maintaining Ruby gems.";
-    homepage    = "https://github.com/nyarly/corundum";
-    license     = licenses.mit;
-    maintainers = [ maintainers.nyarly ];
-    platforms   = platforms.unix;
-  };
-}]]>
-</programlisting>
-
- <para>
-  The chief advantage of <literal>bundlerApp</literal> over <literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.
- </para>
-
- <para>
-  Resulting derivations for both builders also have two helpful attributes, <literal>env</literal> and <literal>wrappedRuby</literal>. The first one allows one to quickly drop into <command>nix-shell</command> with the specified environment present. E.g. <command>nix-shell -A sensu.env</command> would give you an environment with Ruby preset so it has all the libraries necessary for <literal>sensu</literal> in its paths. The second one can be used to make derivations from custom Ruby scripts which have <filename>Gemfile</filename>s with their dependencies specified. It is a derivation with <command>ruby</command> wrapped so it can find all the needed dependencies. For example, to make a derivation <literal>my-script</literal> for a <filename>my-script.rb</filename> (which should be placed in <filename>bin</filename>) you should run <command>bundix</command> as specified above and then use <literal>bundlerEnv</literal> like this:
- </para>
-
-<programlisting>
-<![CDATA[let env = bundlerEnv {
-  name = "my-script-env";
-
-  inherit ruby;
-  gemfile = ./Gemfile;
-  lockfile = ./Gemfile.lock;
-  gemset = ./gemset.nix;
-};
-
-in stdenv.mkDerivation {
-  name = "my-script";
-  buildInputs = [ env.wrappedRuby ];
-  script = ./my-script.rb;
-  buildCommand = ''
-    install -D -m755 $script $out/bin/my-script
-    patchShebangs $out/bin/my-script
-  '';
-}]]>
-</programlisting>
-</section>
diff --git a/doc/languages-frameworks/rust.section.md b/doc/languages-frameworks/rust.section.md
index 400f39c345cd9..0230993d3f083 100644
--- a/doc/languages-frameworks/rust.section.md
+++ b/doc/languages-frameworks/rust.section.md
@@ -63,9 +63,52 @@ The fetcher will verify that the `Cargo.lock` file is in sync with the `src`
 attribute, and fail the build if not. It will also will compress the vendor
 directory into a tar.gz archive.
 
-### Building a crate for a different target
-
-To build your crate with a different cargo `--target` simply specify the `target` attribute:
+### Cross compilation
+
+By default, Rust packages are compiled for the host platform, just like any
+other package is.  The `--target` passed to rust tools is computed from this.
+By default, it takes the `stdenv.hostPlatform.config` and replaces components
+where they are known to differ. But there are ways to customize the argument:
+
+ - To choose a different target by name, define
+   `stdenv.hostPlatform.rustc.config` as that name (a string), and that
+   name will be used instead.
+
+   For example:
+   ```nix
+   import <nixpkgs> {
+     crossSystem = (import <nixpkgs/lib>).systems.examples.armhf-embedded // {
+       rustc.config = "thumbv7em-none-eabi";
+     };
+   }
+   ```
+   will result in:
+   ```shell
+   --target thumbv7em-none-eabi
+   ```
+
+ - To pass a completely custom target, define
+   `stdenv.hostPlatform.rustc.config` with its name, and
+   `stdenv.hostPlatform.rustc.platform` with the value.  The value will be
+   serialized to JSON in a file called
+   `${stdenv.hostPlatform.rustc.config}.json`, and the path of that file
+   will be used instead.
+
+   For example:
+   ```nix
+   import <nixpkgs> {
+     crossSystem = (import <nixpkgs/lib>).systems.examples.armhf-embedded // {
+       rustc.config = "thumb-crazy";
+       rustc.platform = { foo = ""; bar = ""; };
+     };
+   }
+   will result in:
+   ```shell
+   --target /nix/store/asdfasdfsadf-thumb-crazy.json # contains {"foo":"","bar":""}
+   ```
+
+Finally, as an ad-hoc escape hatch, a computed target (string or JSON file
+path) can be passed directly to `buildRustPackage`:
 
 ```nix
 pkgs.rustPlatform.buildRustPackage {
@@ -74,6 +117,15 @@ pkgs.rustPlatform.buildRustPackage {
 }
 ```
 
+This is useful to avoid rebuilding Rust tools, since they are actually target
+agnostic and don't need to be rebuilt. But in the future, we should always
+build the Rust tools and standard library crates separately so there is no
+reason not to take the `stdenv.hostPlatform.rustc`-modifying approach, and the
+ad-hoc escape hatch to `buildRustPackage` can be removed.
+
+Note that currently custom targets aren't compiled with `std`, so `cargo test`
+will fail. This can be ignored by adding `doCheck = false;` to your derivation.
+
 ### Running package tests
 
 When using `buildRustPackage`, the `checkPhase` is enabled by default and runs
@@ -524,12 +576,13 @@ For example, you might want to add `latest.rustChannels.stable.rust` to the list
 
 Imperatively, the latest stable version can be installed with the following command:
 
-    $ nix-env -Ai nixos.latest.rustChannels.stable.rust
+    $ nix-env -Ai nixpkgs.latest.rustChannels.stable.rust
 
 Or using the attribute with nix-shell:
 
-    $ nix-shell -p nixos.latest.rustChannels.stable.rust
+    $ nix-shell -p nixpkgs.latest.rustChannels.stable.rust
 
+Substitute the `nixpkgs` prefix with `nixos` on NixOS.
 To install the beta or nightly channel, "stable" should be substituted by
 "nightly" or "beta", or
 use the function provided by this overlay to pull a version based on a
diff --git a/doc/using/configuration.xml b/doc/using/configuration.xml
index 3e21b0e22843d..336bdf5b26566 100644
--- a/doc/using/configuration.xml
+++ b/doc/using/configuration.xml
@@ -169,6 +169,9 @@
 }
 </programlisting>
     </para>
+    <para>
+      Note that <literal>whitelistedLicenses</literal> only applies to unfree licenses unless <literal>allowUnfree</literal> is enabled. It is not a generic whitelist for all types of licenses. <literal>blacklistedLicenses</literal> applies to all licenses.
+    </para>
    </listitem>
   </itemizedlist>