Skip to content
This repository was archived by the owner on Apr 12, 2021. It is now read-only.
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: NixOS/nixpkgs-channels
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 8070a6333f3f
Choose a base ref
...
head repository: NixOS/nixpkgs-channels
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 1fd8625eae97
Choose a head ref
57 contributors
Loading
Showing 1,081 changed files with 23,210 additions and 15,581 deletions.
17 changes: 13 additions & 4 deletions doc/functions/overrides.xml
View file
Original file line number Diff line number Diff line change
@@ -6,8 +6,14 @@

<para>
Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
derivation attributes, the results of derivations or even the whole package
set.
derivation attributes, the results of derivations.
</para>

<para>
These functions are used to make changes to packages, returning only single
packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other
hand, can be used to combine the overridden packages across the entire
package set of Nixpkgs.
</para>

<section xml:id="sec-pkg-override">
@@ -25,6 +31,9 @@
<para>
Example usages:
<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
<!-- TODO: move below programlisting to a new section about extending and overlays
and reference it
-->
<programlisting>
import pkgs.path { overlays = [ (self: super: {
foo = super.foo.override { barSupport = true ; };
@@ -86,11 +95,11 @@ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
in this case, as it overrides only the attributes of the final derivation.
It is for this reason that <varname>overrideAttrs</varname> should be
preferred in (almost) all cases to <varname>overrideDerivation</varname>,
i.e. to allow using <varname>sdenv.mkDerivation</varname> to process input
i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input
arguments, as well as the fact that it is easier to use (you can use the
same attribute names you see in your Nix code, instead of the ones
generated (e.g. <varname>buildInputs</varname> vs
<varname>nativeBuildInputs</varname>, and involves less typing.
<varname>nativeBuildInputs</varname>), and it involves less typing).
</para>
</note>
</section>
7 changes: 3 additions & 4 deletions doc/languages-frameworks/coq.xml
View file
Original file line number Diff line number Diff line change
@@ -11,10 +11,9 @@
</para>

<para>
Some libraries require OCaml and sometimes also Camlp5 or findlib. The exact
versions that were used to build Coq are saved in the
<literal>coq.ocaml</literal> and <literal>coq.camlp5</literal> and
<literal>coq.findlib</literal> attributes.
Some extensions (plugins) might require OCaml and sometimes other OCaml
packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
depend on the same package set Coq was built against.
</para>

<para>
4 changes: 4 additions & 0 deletions doc/languages-frameworks/vim.section.md
View file
Original file line number Diff line number Diff line change
@@ -23,6 +23,7 @@ Adding custom .vimrc lines can be done using the following code:

```
vim_configurable.customize {
# `name` specifies the name of the executable and package
name = "vim-with-plugins";
vimrcConfig.customRC = ''
@@ -31,6 +32,8 @@ vim_configurable.customize {
}
```

This configuration is used when vim is invoked with the command specified as name, in this case `vim-with-plugins`.

For Neovim the `configure` argument can be overridden to achieve the same:

```
@@ -83,6 +86,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
{
packageOverrides = pkgs: with pkgs; {
myVim = vim_configurable.customize {
# `name` specifies the name of the executable and package
name = "vim-with-plugins";
# add here code from the example section
};
191 changes: 111 additions & 80 deletions doc/overlays.xml
View file
Original file line number Diff line number Diff line change
@@ -17,91 +17,122 @@
<title>Installing overlays</title>

<para>
The list of overlays is determined as follows.
The list of overlays can be set either explicitly in a Nix expression, or
through <literal>&lt;nixpkgs-overlays></literal> or user configuration
files.
</para>

<para>
If the <varname>overlays</varname> argument is not provided explicitly, we
look for overlays in a path. The path is determined as follows:
<orderedlist>
<listitem>
<para>
First, if an <varname>overlays</varname> argument to the nixpkgs function
itself is given, then that is used.
</para>
<para>
This can be passed explicitly when importing nipxkgs, for example
<literal>import &lt;nixpkgs> { overlays = [ overlay1 overlay2 ];
}</literal>.
</para>
</listitem>
<listitem>
<para>
Otherwise, if the Nix path entry <literal>&lt;nixpkgs-overlays></literal>
exists, we look for overlays at that path, as described below.
</para>
<para>
See the section on <literal>NIX_PATH</literal> in the Nix manual for more
details on how to set a value for
<literal>&lt;nixpkgs-overlays>.</literal>
</para>
</listitem>
<listitem>
<para>
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look for
overlays at that path, as described below. It is an error if both exist.
</para>
</listitem>
</orderedlist>
</para>
<section xml:id="sec-overlays-argument">
<title>Set overlays in NixOS or Nix expressions</title>

<para>
If we are looking for overlays at a path, then there are two cases:
<itemizedlist>
<listitem>
<para>
If the path is a file, then the file is imported as a Nix expression and
used as the list of overlays.
</para>
</listitem>
<listitem>
<para>
If the path is a directory, then we take the content of the directory,
order it lexicographically, and attempt to interpret each as an overlay
by:
<itemizedlist>
<listitem>
<para>
Importing the file, if it is a <literal>.nix</literal> file.
</para>
</listitem>
<listitem>
<para>
Importing a top-level <filename>default.nix</filename> file, if it is
a directory.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>
<para>
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
option, if present, is passed to the system Nixpkgs directly as an
argument. Note that this does not affect the overlays for non-NixOS
operations (e.g. <literal>nix-env</literal>), which are
<link xlink:href="#sec-overlays-lookup">looked</link> up independently.
</para>

<para>
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
option, if present, is passed to the system Nixpkgs directly as an argument.
Note that this does not affect the overlays for non-NixOS operations (e.g.
<literal>nix-env</literal>), which are looked up independently.
</para>
<para>
The list of overlays can be passed explicitly when importing nixpkgs, for
example <literal>import &lt;nixpkgs> { overlays = [ overlay1 overlay2 ];
}</literal>.
</para>

<para>
The <filename>overlays.nix</filename> option therefore provides a convenient
way to use the same overlays for a NixOS system configuration and user
configuration: the same file can be used as
<filename>overlays.nix</filename> and imported as the value of
<literal>nixpkgs.overlays</literal>.
</para>
<para>
Further overlays can be added by calling the <literal>pkgs.extend</literal>
or <literal>pkgs.appendOverlays</literal>, although it is often preferable
to avoid these functions, because they recompute the Nixpkgs fixpoint,
which is somewhat expensive to do.
</para>
</section>

<section xml:id="sec-overlays-lookup">
<title>Install overlays via configuration lookup</title>

<para>
The list of overlays is determined as follows.
</para>

<para>
<orderedlist>
<listitem>
<para>
First, if an
<link xlink:href="#sec-overlays-argument"><varname>overlays</varname>
argument</link> to the nixpkgs function itself is given, then that is
used and no path lookup will be performed.
</para>
</listitem>
<listitem>
<para>
Otherwise, if the Nix path entry
<literal>&lt;nixpkgs-overlays></literal> exists, we look for overlays at
that path, as described below.
</para>
<para>
See the section on <literal>NIX_PATH</literal> in the Nix manual for
more details on how to set a value for
<literal>&lt;nixpkgs-overlays>.</literal>
</para>
</listitem>
<listitem>
<para>
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look
for overlays at that path, as described below. It is an error if both
exist.
</para>
</listitem>
</orderedlist>
</para>

<para>
If we are looking for overlays at a path, then there are two cases:
<itemizedlist>
<listitem>
<para>
If the path is a file, then the file is imported as a Nix expression and
used as the list of overlays.
</para>
</listitem>
<listitem>
<para>
If the path is a directory, then we take the content of the directory,
order it lexicographically, and attempt to interpret each as an overlay
by:
<itemizedlist>
<listitem>
<para>
Importing the file, if it is a <literal>.nix</literal> file.
</para>
</listitem>
<listitem>
<para>
Importing a top-level <filename>default.nix</filename> file, if it is
a directory.
</para>
</listitem>
</itemizedlist>
</para>
</listitem>
</itemizedlist>
</para>

<para>
Because overlays that are set in NixOS configuration do not affect
non-NixOS operations such as <literal>nix-env</literal>, the
<filename>overlays.nix</filename> option provides a convenient way to use
the same overlays for a NixOS system configuration and user configuration:
the same file can be used as <filename>overlays.nix</filename> and imported
as the value of <literal>nixpkgs.overlays</literal>.
</para>

<!-- TODO: Example of sharing overlays between NixOS configuration
and configuration lookup. Also reference the example
from the sec-overlays-argument paragraph about NixOS.
-->
</section>
</section>
<!--============================================================-->
<section xml:id="sec-overlays-definition">
8 changes: 4 additions & 4 deletions doc/package-notes.xml
View file
Original file line number Diff line number Diff line change
@@ -681,10 +681,10 @@ overrides = self: super: rec {
</para>

<para>
The python plugin allows the addition of extra libraries. For instance, the
<literal>inotify.py</literal> script in weechat-scripts requires D-Bus or
libnotify, and the <literal>fish.py</literal> script requires pycrypto. To
use these scripts, use the <literal>python</literal> plugin's
The python and perl plugins allows the addition of extra libraries. For
instance, the <literal>inotify.py</literal> script in weechat-scripts
requires D-Bus or libnotify, and the <literal>fish.py</literal> script
requires pycrypto. To use these scripts, use the plugin's
<literal>withPackages</literal> attribute:
<programlisting>weechat.override { configure = {availablePlugins, ...}: {
plugins = with availablePlugins; [
38 changes: 30 additions & 8 deletions doc/stdenv.xml
View file
Original file line number Diff line number Diff line change
@@ -372,7 +372,7 @@ let f(h, h + 1, i) = i + h
They are programs/libraries used at build time that furthermore produce
programs/libraries also used at build time. If the dependency doesn't
care about the target platform (i.e. isn't a compiler or similar tool),
put it in <varname>nativeBuildInputs</varname>instead. The most common
put it in <varname>nativeBuildInputs</varname> instead. The most common
use for this <literal>buildPackages.stdenv.cc</literal>, the default C
compiler for this role. That example crops up more than one might think
in old commonly used C libraries.
@@ -2099,13 +2099,13 @@ someVar=$(stripHash $name)
</para>

<para>
In order to alleviate this burden, the <firstterm>setup
hook></firstterm>mechanism was written, where any package can include a
shell script that [by convention rather than enforcement by Nix], any
downstream reverse-dependency will source as part of its build process. That
allows the downstream dependency to merely specify its dependencies, and
lets those dependencies effectively initialize themselves. No boilerplate
mirroring the list of dependencies is needed.
In order to alleviate this burden, the <firstterm>setup hook</firstterm>
mechanism was written, where any package can include a shell script that [by
convention rather than enforcement by Nix], any downstream
reverse-dependency will source as part of its build process. That allows the
downstream dependency to merely specify its dependencies, and lets those
dependencies effectively initialize themselves. No boilerplate mirroring the
list of dependencies is needed.
</para>

<para>
@@ -2445,6 +2445,28 @@ addEnvHooks "$hostOffset" myBashFunction
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
breakpointHook
</term>
<listitem>
<para>
This hook will make a build pause instead of stopping when a failure
happen. It prevents nix to cleanup the build environment immediatly and
allows the user to attach to a build environment using the
<command>cntr</command> command. On build error it will print the
instruction that are neccessary for <command>cntr</command>. Installing
cntr and running the command will provide shell access to the build
sandbox of failed build. At <filename>/var/lib/cntr</filename> the
sandbox filesystem is mounted. All commands and files of the system are
still accessible within the shell. To execute commands from the sandbox
use the cntr exec subcommand. Note that <command>cntr</command> also
needs to be executed on the machine that is doing the build, which might
be not the case when remote builders are enabled.
<command>cntr</command> is only supported on linux based platforms.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</section>
5 changes: 5 additions & 0 deletions lib/licenses.nix
View file
Original file line number Diff line number Diff line change
@@ -585,6 +585,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "Ruby License";
};

sendmail = spdx {
spdxId = "Sendmail";
fullName = "Sendmail License";
};

sgi-b-20 = spdx {
spdxId = "SGI-B-2.0";
fullName = "SGI Free Software License B v2.0";
19 changes: 19 additions & 0 deletions lib/systems/default.nix
View file
Original file line number Diff line number Diff line change
@@ -46,6 +46,25 @@ rec {
# Misc boolean options
useAndroidPrebuilt = false;
useiOSPrebuilt = false;

# Output from uname
uname = {
# uname -s
system = {
"linux" = "Linux";
"windows" = "Windows";
"darwin" = "Darwin";
"netbsd" = "NetBSD";
"freebsd" = "FreeBSD";
"openbsd" = "OpenBSD";
}.${final.parsed.kernel.name} or null;

# uname -p
processor = final.parsed.cpu.name;

# uname -r
release = null;
};
} // mapAttrs (n: v: v final.parsed) inspect.predicates
// args;
in assert final.useAndroidPrebuilt -> final.isAndroid;
Loading