diff --git a/.editorconfig b/.editorconfig
new file mode 100644
index 000000000000..969e613536b4
--- /dev/null
+++ b/.editorconfig
@@ -0,0 +1,24 @@
+# EditorConfig configuration for nixpkgs
+# http://EditorConfig.org
+
+# Top-most EditorConfig file
+root = true
+
+# Unix-style newlines with a newline ending every file, utf-8 charset
+[*]
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+charset = utf-8
+
+# see https://nixos.org/nixpkgs/manual/#chap-conventions
+
+# Match nix/ruby files, set indent to spaces with width of two
+[*.{nix,rb}]
+indent_style = space
+indent_size = 2
+
+# Match shell/python/perl scripts, set indent to spaces with width of four
+[*.{sh,py,pl}]
+indent_style = space
+indent_size = 4
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index fb8c6b53cb5d..8400aa5c684f 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -28,5 +28,8 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
* Not start with the package name
* Not have a dot at the end
-See the nixpkgs manual for more details on how to [Submit changes to nixpkgs](http://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download-by-type/doc/manual#chap-submitting-changes).
+See the nixpkgs manual for more details on how to [Submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
+## Reviewing contributions
+
+See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions).
diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 5d13d3086f73..3482ae16e263 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -4,12 +4,12 @@
###### Things done
- [ ] Tested using sandboxing
- ([nix.useChroot](http://nixos.org/nixos/manual/options.html#opt-nix.useChroot) on NixOS,
- or option `build-use-chroot` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file)
+ ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS,
+ or option `build-use-sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file)
on non-NixOS)
- Built on platform(s)
- [ ] NixOS
- - [ ] OS X
+ - [ ] macOS
- [ ] Linux
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
diff --git a/.mention-bot b/.mention-bot
index 40e57f996606..d8529bd9123e 100644
--- a/.mention-bot
+++ b/.mention-bot
@@ -1,6 +1,13 @@
{
"userBlacklist": [
"civodul",
- "jhasse"
- ]
+ "jhasse",
+ "shlevy"
+ ],
+ "alwaysNotifyForPaths": [
+ { "name": "FRidh", "files": ["pkgs/top-level/python-packages.nix", "pkgs/development/interpreters/python/*", "pkgs/development/python-modules/*" ] },
+ { "name": "LnL7", "files": ["pkgs/stdenv/darwin/*", "pkgs/os-specific/darwin/*"] },
+ { "name": "copumpkin", "files": ["pkgs/stdenv/darwin/*", "pkgs/os-specific/darwin/apple-source-releases/*"] }
+ ],
+ "fileBlacklist": ["pkgs/top-level/all-packages.nix"]
}
diff --git a/.travis.yml b/.travis.yml
index e1cc9890df25..802af69834d0 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -4,7 +4,7 @@ matrix:
- os: linux
sudo: false
script:
- - ./maintainers/scripts/travis-nox-review-pr.sh nixpkgs-verify nixpkgs-manual nixpkgs-tarball
+ - ./maintainers/scripts/travis-nox-review-pr.sh nixpkgs-verify nixpkgs-manual nixpkgs-tarball nixpkgs-unstable
- ./maintainers/scripts/travis-nox-review-pr.sh nixos-options nixos-manual
- os: linux
sudo: required
@@ -15,8 +15,6 @@ matrix:
- os: osx
osx_image: xcode7.3
script: ./maintainers/scripts/travis-nox-review-pr.sh nox pr
-git:
- depth: 1
env:
global:
- GITHUB_TOKEN=5edaaf1017f691ed34e7f80878f8f5fbd071603f
diff --git a/.version b/.version
index 18fc8443eecf..6879fa566dd8 100644
--- a/.version
+++ b/.version
@@ -1 +1 @@
-16.09
\ No newline at end of file
+17.03
\ No newline at end of file
diff --git a/COPYING b/COPYING
index 0408a7e40b7a..a632d6f58b12 100644
--- a/COPYING
+++ b/COPYING
@@ -1,4 +1,4 @@
-Copyright (c) 2003-2016 Eelco Dolstra and the Nixpkgs/NixOS contributors
+Copyright (c) 2003-2017 Eelco Dolstra and the Nixpkgs/NixOS contributors
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
diff --git a/README.md b/README.md
index 88610f17388f..002caa3a1719 100644
--- a/README.md
+++ b/README.md
@@ -2,8 +2,6 @@
[](https://travis-ci.org/NixOS/nixpkgs)
[](https://www.codetriage.com/nixos/nixpkgs)
-[](http://www.issuestats.com/github/nixos/nixpkgs)
-[](http://www.issuestats.com/github/nixos/nixpkgs)
Nixpkgs is a collection of packages for the [Nix](https://nixos.org/nix/) package
manager. It is periodically built and tested by the [hydra](http://hydra.nixos.org/)
@@ -15,12 +13,12 @@ build daemon as so-called channels. To get channel information via git, add
```
For stability and maximum binary package support, it is recommended to maintain
-custom changes on top of one of the channels, e.g. `nixos-16.03` for the latest
+custom changes on top of one of the channels, e.g. `nixos-16.09` for the latest
release and `nixos-unstable` for the latest successful build of master:
```
% git remote update channels
-% git rebase channels/nixos-16.03
+% git rebase channels/nixos-16.09
```
For pull-requests, please rebase onto nixpkgs `master`.
@@ -34,9 +32,9 @@ For pull-requests, please rebase onto nixpkgs `master`.
* [Manual (NixOS)](https://nixos.org/nixos/manual/)
* [Nix Wiki](https://nixos.org/wiki/) (deprecated, see milestone ["Move the Wiki!"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Move+the+wiki%21%22))
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
-* [Continuous package builds for 16.03 release](https://hydra.nixos.org/jobset/nixos/release-16.03)
+* [Continuous package builds for 16.09 release](https://hydra.nixos.org/jobset/nixos/release-16.09)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
-* [Tests for 16.03 release](https://hydra.nixos.org/job/nixos/release-16.03/tested#tabs-constituents)
+* [Tests for 16.09 release](https://hydra.nixos.org/job/nixos/release-16.09/tested#tabs-constituents)
Communication:
diff --git a/doc/default.nix b/doc/default.nix
index f4f467b1f5a0..625c716b0319 100644
--- a/doc/default.nix
+++ b/doc/default.nix
@@ -60,6 +60,10 @@ pkgs.stdenv.mkDerivation {
inputFile = ../pkgs/development/idris-modules/README.md;
outputFile = "languages-frameworks/idris.xml";
}
+ + toDocbook {
+ inputFile = ../pkgs/development/node-packages/README.md;
+ outputFile = "languages-frameworks/node.xml";
+ }
+ toDocbook {
inputFile = ../pkgs/development/r-modules/README.md;
outputFile = "languages-frameworks/r.xml";
@@ -93,7 +97,9 @@ pkgs.stdenv.mkDerivation {
cp -r $dst/images $dst/epub/OEBPS
echo "application/epub+zip" > mimetype
- zip -0Xq "$dst/Nixpkgs Contributors Guide - NixOS community.epub" mimetype
- zip -Xr9D "$dst/Nixpkgs Contributors Guide - NixOS community.epub" $dst/epub/*
+ manual="$dst/nixpkgs-manual.epub"
+ zip -0Xq "$manual" mimetype
+ cd $dst/epub && zip -Xr9D "$manual" *
+ rm -rf $dst/epub
'';
}
diff --git a/doc/functions.xml b/doc/functions.xml
index 908e9571ed69..70326936a570 100644
--- a/doc/functions.xml
+++ b/doc/functions.xml
@@ -8,177 +8,295 @@
The nixpkgs repository has several utility functions to manipulate Nix expressions.
-
- pkgs.overridePackages
+
+ Overriding
- This function inside the nixpkgs expression (pkgs)
- can be used to override the set of packages itself.
-
-
- Warning: this function is expensive and must not be used from within
- the nixpkgs repository.
-
-
- Example usage:
-
- let
- pkgs = import <nixpkgs> {};
- newpkgs = pkgs.overridePackages (self: super: {
- foo = super.foo.override { ... };
- };
-in ...
+ Sometimes one wants to override parts of
+ nixpkgs, e.g. derivation attributes, the results of
+ derivations or even the whole package set.
-
- The resulting newpkgs will have the new foo
- expression, and all other expressions depending on foo will also
- use the new foo expression.
-
+
+ pkgs.overridePackages
-
- The behavior of this function is similar to config.packageOverrides.
-
-
-
- The self parameter refers to the final package set with the
- applied overrides. Using this parameter may lead to infinite recursion if not
- used consciously.
-
-
-
- The super parameter refers to the old package set.
- It's equivalent to pkgs in the above example.
-
-
-
-
-
- <pkg>.override
-
-
- The function override is usually available for all the
- derivations in the nixpkgs expression (pkgs).
-
-
- It is used to override the arguments passed to a function.
-
-
- Example usages:
-
- pkgs.foo.override { arg1 = val1; arg2 = val2; ... }
- pkgs.overridePackages (self: super: {
- foo = super.foo.override { barSupport = true ; };
-})
- mypkg = pkgs.callPackage ./mypkg.nix {
- mydep = pkgs.mydep.override { ... };
-})
-
-
-
- In the first example, pkgs.foo is the result of a function call
- with some default arguments, usually a derivation.
- Using pkgs.foo.override will call the same function with
- the given new arguments.
-
-
-
-
-
- <pkg>.overrideDerivation
-
-
- Do not use this function in Nixpkgs as it evaluates a Derivation
- before modifying it, which breaks package abstraction and removes
- error-checking of function arguments. In addition, this
- evaluation-per-function application incurs a performance penalty,
- which can become a problem if many overrides are used.
- It is only intended for ad-hoc customisation, such as in
- ~/.nixpkgs/config.nix.
-
-
-
-
- The function overrideDerivation creates a new derivation
- based on an existing one by overriding the original's attributes with
- the attribute set produced by the specified function.
- This function is available on all
- derivations defined using the makeOverridable function.
- Most standard derivation-producing functions, such as
- stdenv.mkDerivation, are defined using this
- function, which means most packages in the nixpkgs expression,
- pkgs, have this function.
-
-
-
- Example usage:
-
- mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
- name = "sed-4.2.2-pre";
- src = fetchurl {
- url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
- sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
- };
- patches = [];
-});
-
-
-
- In the above example, the name, src,
- and patches of the derivation will be overridden, while
- all other attributes will be retained from the original derivation.
-
-
-
- The argument oldAttrs is used to refer to the attribute set of
- the original derivation.
-
-
-
- A package's attributes are evaluated *before* being modified by
- the overrideDerivation function.
- For example, the name attribute reference
- in url = "mirror://gnu/hello/${name}.tar.gz";
- is filled-in *before* the overrideDerivation function
- modifies the attribute set. This means that overriding the
- name attribute, in this example, *will not* change the
- value of the url attribute. Instead, we need to override
- both the name *and* url attributes.
+ This function inside the nixpkgs expression (pkgs)
+ can be used to override the set of packages itself.
-
+
+ Warning: this function is expensive and must not be used from within
+ the nixpkgs repository.
+
+
+ Example usage:
+
+ let
+ pkgs = import <nixpkgs> {};
+ newpkgs = pkgs.overridePackages (self: super: {
+ foo = super.foo.override { ... };
+ };
+ in ...
+
+
+
+ The resulting newpkgs will have the new foo
+ expression, and all other expressions depending on foo will also
+ use the new foo expression.
+
+
+
+ The behavior of this function is similar to config.packageOverrides.
+
+
+
+ The self parameter refers to the final package set with the
+ applied overrides. Using this parameter may lead to infinite recursion if not
+ used consciously.
+
+
+
+ The super parameter refers to the old package set.
+ It's equivalent to pkgs in the above example.
+
+
+
+ Note that in previous versions of nixpkgs, this method replaced any changes from config.packageOverrides,
+ along with that from previous calls if this function was called repeatedly.
+ Now those previous changes will be preserved so this function can be "chained" meaningfully.
+ To recover the old behavior, make sure config.packageOverrides is unset,
+ and call this only once off a "freshly" imported nixpkgs:
+
+ let
+ pkgs = import <nixpkgs> { config: {}; };
+ newpkgs = pkgs.overridePackages ...;
+ in ...
+
+
+
+
+
+ <pkg>.override
+
+
+ The function override is usually available for all the
+ derivations in the nixpkgs expression (pkgs).
+
+
+ It is used to override the arguments passed to a function.
+
+
+ Example usages:
+
+ pkgs.foo.override { arg1 = val1; arg2 = val2; ... }
+ pkgs.overridePackages (self: super: {
+ foo = super.foo.override { barSupport = true ; };
+ })
+ mypkg = pkgs.callPackage ./mypkg.nix {
+ mydep = pkgs.mydep.override { ... };
+ })
+
+
+
+ In the first example, pkgs.foo is the result of a function call
+ with some default arguments, usually a derivation.
+ Using pkgs.foo.override will call the same function with
+ the given new arguments.
+
+
+
+
+
+ <pkg>.overrideAttrs
+
+
+ The function overrideAttrs allows overriding the
+ attribute set passed to a stdenv.mkDerivation call,
+ producing a new derivation based on the original one.
+ This function is available on all derivations produced by the
+ stdenv.mkDerivation function, which is most packages
+ in the nixpkgs expression pkgs.
+
+
+
+ Example usage:
+
+ helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
+ separateDebugInfo = true;
+ });
+
+
+
+ In the above example, the separateDebugInfo attribute is
+ overriden to be true, thus building debug info for
+ helloWithDebug, while all other attributes will be
+ retained from the original hello package.
+
+
+
+ The argument oldAttrs is conventionally used to refer to
+ the attr set originally passed to stdenv.mkDerivation.
+
+
+
+
+ Note that separateDebugInfo is processed only by the
+ stdenv.mkDerivation function, not the generated, raw
+ Nix derivation. Thus, using overrideDerivation will
+ not work in this case, as it overrides only the attributes of the final
+ derivation. It is for this reason that overrideAttrs
+ should be preferred in (almost) all cases to
+ overrideDerivation, i.e. to allow using
+ sdenv.mkDerivation 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.
+ buildInputs vs nativeBuildInputs,
+ and involves less typing.
+
+
+
+
+
+
+
+ <pkg>.overrideDerivation
+
+
+ You should prefer overrideAttrs in almost all
+ cases, see its documentation for the reasons why.
+ overrideDerivation is not deprecated and will continue
+ to work, but is less nice to use and does not have as many abilities as
+ overrideAttrs.
+
+
+
+
+ Do not use this function in Nixpkgs as it evaluates a Derivation
+ before modifying it, which breaks package abstraction and removes
+ error-checking of function arguments. In addition, this
+ evaluation-per-function application incurs a performance penalty,
+ which can become a problem if many overrides are used.
+ It is only intended for ad-hoc customisation, such as in
+ ~/.nixpkgs/config.nix.
+
+
+
+
+ The function overrideDerivation creates a new derivation
+ based on an existing one by overriding the original's attributes with
+ the attribute set produced by the specified function.
+ This function is available on all
+ derivations defined using the makeOverridable function.
+ Most standard derivation-producing functions, such as
+ stdenv.mkDerivation, are defined using this
+ function, which means most packages in the nixpkgs expression,
+ pkgs, have this function.
+
+
+
+ Example usage:
+
+ mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
+ name = "sed-4.2.2-pre";
+ src = fetchurl {
+ url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
+ sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
+ };
+ patches = [];
+ });
+
+
+
+ In the above example, the name, src,
+ and patches of the derivation will be overridden, while
+ all other attributes will be retained from the original derivation.
+
+
+
+ The argument oldAttrs is used to refer to the attribute set of
+ the original derivation.
+
+
+
+
+ A package's attributes are evaluated *before* being modified by
+ the overrideDerivation function.
+ For example, the name attribute reference
+ in url = "mirror://gnu/hello/${name}.tar.gz";
+ is filled-in *before* the overrideDerivation function
+ modifies the attribute set. This means that overriding the
+ name attribute, in this example, *will not* change the
+ value of the url attribute. Instead, we need to override
+ both the name *and* url attributes.
+
+
+
+
+
+
+ lib.makeOverridable
+
+
+ The function lib.makeOverridable is used to make the result
+ of a function easily customizable. This utility only makes sense for functions
+ that accept an argument set and return an attribute set.
+
+
+
+ Example usage:
+
+ f = { a, b }: { result = a+b; }
+ c = lib.makeOverridable f { a = 1; b = 2; }
+
+
+
+
+ The variable c is the value of the f function
+ applied with some default arguments. Hence the value of c.result
+ is 3, in this example.
+
+
+
+ The variable c however also has some additional functions, like
+ c.override which can be used to
+ override the default arguments. In this example the value of
+ (c.override { a = 4; }).result is 6.
+
+
+
-
- lib.makeOverridable
+
+ Generators
- The function lib.makeOverridable is used to make the result
- of a function easily customizable. This utility only makes sense for functions
- that accept an argument set and return an attribute set.
+ Generators are functions that create file formats from nix
+ data structures, e. g. for configuration files.
+ There are generators available for: INI,
+ JSON and YAML
- Example usage:
-
- f = { a, b }: { result = a+b; }
-c = lib.makeOverridable f { a = 1; b = 2; }
-
+ All generators follow a similar call interface: generatorName
+ configFunctions data, where configFunctions is a
+ set of user-defined functions that format variable parts of the content.
+ They each have common defaults, so often they do not need to be set
+ manually. An example is mkSectionName ? (name: libStr.escape [ "[" "]"
+ ] name) from the INI generator. It gets the name
+ of a section and returns a sanitized name. The default
+ mkSectionName escapes [ and
+ ] with a backslash.
-
- The variable c is the value of the f function
- applied with some default arguments. Hence the value of c.result
- is 3, in this example.
-
+ Nix store paths can be converted to strings by enclosing a
+ derivation attribute like so: "${drv}".
- The variable c however also has some additional functions, like
- c.override which can be used to
- override the default arguments. In this example the value of
- (c.override { a = 4; }).result is 6.
+ Detailed documentation for each generator can be found in
+ lib/generators.nix.
@@ -295,37 +413,37 @@ c = lib.makeOverridable f { a = 1; b = 2; }
- pkgs.dockerTools
+pkgs.dockerTools
-
+pkgs.dockerTools is a set of functions for creating and
manipulating Docker images according to the
- Docker Image Specification v1.0.0
+ Docker Image Specification v1.0.0
. Docker itself is not used to perform any of the operations done by these
functions.
-
+
-
+
- The dockerTools API is unstable and may be subject to
- backwards-incompatible changes in the future.
+ The dockerTools API is unstable and may be subject to
+ backwards-incompatible changes in the future.
-
+
-
+buildImage
- This function is analogous to the docker build command,
- in that can used to build a Docker-compatible repository tarball containing
- a single image with one or multiple layers. As such, the result
- is suitable for being loaded in Docker with docker load.
+ This function is analogous to the docker build command,
+ in that can used to build a Docker-compatible repository tarball containing
+ a single image with one or multiple layers. As such, the result
+ is suitable for being loaded in Docker with docker load.
- The parameters of buildImage with relative example values are
- described below:
+ The parameters of buildImage with relative example values are
+ described below:
Docker build
@@ -333,11 +451,11 @@ c = lib.makeOverridable f { a = 1; b = 2; }
buildImage {
name = "redis";
tag = "latest";
-
+
fromImage = someBaseImage;
fromImageName = null;
fromImageTag = "latest";
-
+
contents = pkgs.redis;
runAsRoot = ''
#!${stdenv.shell}
@@ -356,131 +474,131 @@ c = lib.makeOverridable f { a = 1; b = 2; }
The above example will build a Docker image redis/latest
- from the given base image. Loading and running this image in Docker results in
- redis-server being started automatically.
+ from the given base image. Loading and running this image in Docker results in
+ redis-server being started automatically.
-
+
- name specifies the name of the resulting image.
- This is the only required argument for buildImage.
+ name specifies the name of the resulting image.
+ This is the only required argument for buildImage.
-
+
-
+
- tag specifies the tag of the resulting image.
- By default it's latest.
+ tag specifies the tag of the resulting image.
+ By default it's latest.
-
+
-
+
- fromImage is the repository tarball containing the base image.
- It must be a valid Docker image, such as exported by docker save.
- By default it's null, which can be seen as equivalent
- to FROM scratch of a Dockerfile.
+ fromImage is the repository tarball containing the base image.
+ It must be a valid Docker image, such as exported by docker save.
+ By default it's null, which can be seen as equivalent
+ to FROM scratch of a Dockerfile.
-
-
-
-
- fromImageName can be used to further specify
- the base image within the repository, in case it contains multiple images.
- By default it's null, in which case
- buildImage will peek the first image available
- in the repository.
-
-
+
-
+
- fromImageTag can be used to further specify the tag
- of the base image within the repository, in case an image contains multiple tags.
- By default it's null, in which case
- buildImage will peek the first tag available for the base image.
+ fromImageName can be used to further specify
+ the base image within the repository, in case it contains multiple images.
+ By default it's null, in which case
+ buildImage will peek the first image available
+ in the repository.
-
+
-
+
- contents is a derivation that will be copied in the new
- layer of the resulting image. This can be similarly seen as
- ADD contents/ / in a Dockerfile.
- By default it's null.
+ fromImageTag can be used to further specify the tag
+ of the base image within the repository, in case an image contains multiple tags.
+ By default it's null, in which case
+ buildImage will peek the first tag available for the base image.
-
+
-
+
- runAsRoot is a bash script that will run as root
- in an environment that overlays the existing layers of the base image with
- the new resulting layer, including the previously copied
- contents derivation.
- This can be similarly seen as
- RUN ... in a Dockerfile.
-
-
+ contents is a derivation that will be copied in the new
+ layer of the resulting image. This can be similarly seen as
+ ADD contents/ / in a Dockerfile.
+ By default it's null.
+
+
+
+
+
+ runAsRoot is a bash script that will run as root
+ in an environment that overlays the existing layers of the base image with
+ the new resulting layer, including the previously copied
+ contents derivation.
+ This can be similarly seen as
+ RUN ... in a Dockerfile.
+
+
- Using this parameter requires the kvm
- device to be available.
+ Using this parameter requires the kvm
+ device to be available.
-
+
-
+
-
+
- config is used to specify the configuration of the
- containers that will be started off the built image in Docker.
- The available options are listed in the
-
+ config is used to specify the configuration of the
+ containers that will be started off the built image in Docker.
+ The available options are listed in the
+
Docker Image Specification v1.0.0
- .
+ .
-
+
- After the new layer has been created, its closure
- (to which contents, config and
- runAsRoot contribute) will be copied in the layer itself.
- Only new dependencies that are not already in the existing layers will be copied.
+ After the new layer has been created, its closure
+ (to which contents, config and
+ runAsRoot contribute) will be copied in the layer itself.
+ Only new dependencies that are not already in the existing layers will be copied.
- At the end of the process, only one new single layer will be produced and
- added to the resulting image.
+ At the end of the process, only one new single layer will be produced and
+ added to the resulting image.
- The resulting repository will only list the single image
- image/tag. In the case of
- it would be redis/latest.
+ The resulting repository will only list the single image
+ image/tag. In the case of
+ it would be redis/latest.
- It is possible to inspect the arguments with which an image was built
- using its buildArgs attribute.
+ It is possible to inspect the arguments with which an image was built
+ using its buildArgs attribute.
-
+
-
+pullImage
- This function is analogous to the docker pull command,
- in that can be used to fetch a Docker image from a Docker registry.
- Currently only registry v1 is supported.
- By default Docker Hub
- is used to pull images.
+ This function is analogous to the docker pull command,
+ in that can be used to fetch a Docker image from a Docker registry.
+ Currently only registry v1 is supported.
+ By default Docker Hub
+ is used to pull images.
- Its parameters are described in the example below:
+ Its parameters are described in the example below:
Docker pull
@@ -498,73 +616,73 @@ c = lib.makeOverridable f { a = 1; b = 2; }
-
+
- imageName specifies the name of the image to be downloaded,
- which can also include the registry namespace (e.g. library/debian).
- This argument is required.
+ imageName specifies the name of the image to be downloaded,
+ which can also include the registry namespace (e.g. library/debian).
+ This argument is required.
-
-
-
-
- imageTag specifies the tag of the image to be downloaded.
- By default it's latest.
-
-
+
-
+
- imageId, if specified this exact image will be fetched, instead
- of imageName/imageTag. However, the resulting repository
- will still be named imageName/imageTag.
- By default it's null.
+ imageTag specifies the tag of the image to be downloaded.
+ By default it's latest.
-
+
-
+
- sha256 is the checksum of the whole fetched image.
- This argument is required.
+ imageId, if specified this exact image will be fetched, instead
+ of imageName/imageTag. However, the resulting repository
+ will still be named imageName/imageTag.
+ By default it's null.
+
+
+
+
+
+ sha256 is the checksum of the whole fetched image.
+ This argument is required.
- The checksum is computed on the unpacked directory, not on the final tarball.
+ The checksum is computed on the unpacked directory, not on the final tarball.
-
+
-
+
- In the above example the default values are shown for the variables
- indexUrl and registryVersion.
- Hence by default the Docker.io registry is used to pull the images.
+ In the above example the default values are shown for the variables
+ indexUrl and registryVersion.
+ Hence by default the Docker.io registry is used to pull the images.
-
+
-
-
-
-
+
+
+
+exportImage
- This function is analogous to the docker export command,
- in that can used to flatten a Docker image that contains multiple layers.
- It is in fact the result of the merge of all the layers of the image.
- As such, the result is suitable for being imported in Docker
- with docker import.
+ This function is analogous to the docker export command,
+ in that can used to flatten a Docker image that contains multiple layers.
+ It is in fact the result of the merge of all the layers of the image.
+ As such, the result is suitable for being imported in Docker
+ with docker import.
-
+
Using this function requires the kvm
device to be available.
-
+
- The parameters of exportImage are the following:
+ The parameters of exportImage are the following:
Docker export
@@ -573,35 +691,35 @@ c = lib.makeOverridable f { a = 1; b = 2; }
fromImage = someLayeredImage;
fromImageName = null;
fromImageTag = null;
-
+
name = someLayeredImage.name;
}
- The parameters relative to the base image have the same synopsis as
- described in , except that
- fromImage is the only required argument in this case.
+ The parameters relative to the base image have the same synopsis as
+ described in , except that
+ fromImage is the only required argument in this case.
- The name argument is the name of the derivation output,
- which defaults to fromImage.name.
+ The name argument is the name of the derivation output,
+ which defaults to fromImage.name.
-
+
-
+shadowSetup
- This constant string is a helper for setting up the base files for managing
- users and groups, only if such files don't exist already.
- It is suitable for being used in a
- runAsRoot script for cases like
- in the example below:
+ This constant string is a helper for setting up the base files for managing
+ users and groups, only if such files don't exist already.
+ It is suitable for being used in a
+ runAsRoot script for cases like
+ in the example below:
-
+
Shadow base files
buildImage {
@@ -620,13 +738,13 @@ c = lib.makeOverridable f { a = 1; b = 2; }
- Creating base files like /etc/passwd or
- /etc/login.defs are necessary for shadow-utils to
- manipulate users and groups.
+ Creating base files like /etc/passwd or
+ /etc/login.defs are necessary for shadow-utils to
+ manipulate users and groups.
-
-
-
+
+
+
diff --git a/doc/languages-frameworks/beam.xml b/doc/languages-frameworks/beam.xml
index 2dc5aa63e458..efb2e60cf3aa 100644
--- a/doc/languages-frameworks/beam.xml
+++ b/doc/languages-frameworks/beam.xml
@@ -248,7 +248,7 @@ $ nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
development. Many times we need to create a
shell.nix file and do our development inside
of the environment specified by that file. This file looks a lot
- like the packageing described above. The main difference is that
+ like the packaging described above. The main difference is that
src points to project root and we call the
package directly.
diff --git a/doc/languages-frameworks/go.xml b/doc/languages-frameworks/go.xml
index e56d7dd389d9..026acb4e8fb9 100644
--- a/doc/languages-frameworks/go.xml
+++ b/doc/languages-frameworks/go.xml
@@ -24,7 +24,7 @@ deis = buildGoPackage rec {
sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
};
- goDeps = ./deps.json;
+ goDeps = ./deps.nix;
buildFlags = "--tags release";
}
@@ -56,7 +56,9 @@ the following arguments are of special significance to the function:
goDeps is where the Go dependencies of a Go program are listed
- in a JSON format described below.
+ 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.
@@ -70,23 +72,32 @@ the following arguments are of special significance to the function:
-The goDeps attribute should point to a JSON file that defines which Go libraries
- are needed and should be included in GOPATH for buildPhase.
-
+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.
-deps.json
+deps.nix
[
- {
- "goPackagePath": "gopkg.in/yaml.v2",
- "fetch": {
- "type": "git",
- "url": "https://gopkg.in/yaml.v2",
- "rev": "a83829b6f1293c91addabc89d0571c246397bbf4",
- "sha256": "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh"
- }
- }
+ {
+ goPackagePath = "gopkg.in/yaml.v2";
+ fetch = {
+ 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";
+ };
+ }
]
diff --git a/doc/languages-frameworks/haskell.md b/doc/languages-frameworks/haskell.md
index 18b2fd65f44b..6728f4abba0e 100644
--- a/doc/languages-frameworks/haskell.md
+++ b/doc/languages-frameworks/haskell.md
@@ -383,7 +383,7 @@ You can select a particular GHC version to compile with by setting the
Stack choose what GHC version it wants based on the snapshot specified
in `stack.yaml` (only works with Stack >= 1.1.3):
- {nixpkgs ? import { }, ghc ? nixpkgs.ghc}
+ {nixpkgs ? import { }, ghc ? nixpkgs.ghc}:
with nixpkgs;
@@ -633,7 +633,7 @@ Now the builds succeeds.
Of course, in the concrete example of `ghc-events` this whole exercise is not
an ideal solution, because `ghc-events` can analyze the output emitted by any
version of GHC later than 6.12 regardless of the compiler version that was used
-to build the `ghc-events' executable, so strictly speaking there's no reason to
+to build the `ghc-events` executable, so strictly speaking there's no reason to
prefer one built with GHC 7.8.x in the first place. However, for users who
cannot use GHC 7.10.x at all for some reason, the approach of downgrading to an
older version might be useful.
diff --git a/doc/languages-frameworks/index.xml b/doc/languages-frameworks/index.xml
index 8076c33f1b3f..81352ec2a9a6 100644
--- a/doc/languages-frameworks/index.xml
+++ b/doc/languages-frameworks/index.xml
@@ -21,6 +21,7 @@ such as Perl or Haskell. These are described in this chapter.
+
diff --git a/doc/languages-frameworks/perl.xml b/doc/languages-frameworks/perl.xml
index 54b82f4a0560..dfb463b99912 100644
--- a/doc/languages-frameworks/perl.xml
+++ b/doc/languages-frameworks/perl.xml
@@ -157,16 +157,16 @@ expression on standard output. For example:
$ nix-generate-from-cpan XML::Simple
- XMLSimple = buildPerlPackage {
- name = "XML-Simple-2.20";
+ XMLSimple = buildPerlPackage rec {
+ name = "XML-Simple-2.22";
src = fetchurl {
- url = mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.20.tar.gz;
- sha256 = "5cff13d0802792da1eb45895ce1be461903d98ec97c9c953bc8406af7294434a";
+ url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
+ sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
};
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
meta = {
- description = "Easily read/write XML (esp config files)";
- license = "perl";
+ description = "An API for simple XML files";
+ license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
};
};
diff --git a/doc/languages-frameworks/python.md b/doc/languages-frameworks/python.md
index e7dbe3bd7db0..82aeb112c93e 100644
--- a/doc/languages-frameworks/python.md
+++ b/doc/languages-frameworks/python.md
@@ -3,7 +3,7 @@
## User Guide
Several versions of Python are available on Nix as well as a high amount of
-packages. The default interpreter is CPython 2.7.
+packages. The default interpreter is CPython 3.5.
### Using Python
@@ -97,7 +97,7 @@ We will first have a look at how Python packages are packaged on Nix. Then, we w
#### Python packaging on Nix
-On Nix all packages are built by functions. The main function in Nix for building Python packages is [`buildPythonPackage`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/generic/default.nix).
+On Nix all packages are built by functions. The main function in Nix for building Python packages is [`buildPythonPackage`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/interpreters/python/build-python-package.nix).
Let's see how we would build the `toolz` package. According to [`python-packages.nix`](https://raw.githubusercontent.com/NixOS/nixpkgs/master/pkgs/top-level/python-packages.nix) `toolz` is build using
```nix
@@ -141,13 +141,15 @@ with import {};
pkgs.python35Packages.buildPythonPackage rec {
name = "toolz-${version}";
- version = "0.7.4";
+ version = "0.8.0";
src = pkgs.fetchurl{
url = "mirror://pypi/t/toolz/toolz-${version}.tar.gz";
- sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
+ sha256 = "e8451af61face57b7c5d09e71c0d27b8005f001ead56e9fdf470417e5cc6d479";
};
+ doCheck = false;
+
meta = {
homepage = "http://github.com/pytoolz/toolz/";
description = "List processing tools and functional utilities";
@@ -170,18 +172,18 @@ with import {};
( let
toolz = pkgs.python35Packages.buildPythonPackage rec {
name = "toolz-${version}";
- version = "0.7.4";
+ version = "0.8.0";
src = pkgs.fetchurl{
url = "mirror://pypi/t/toolz/toolz-${version}.tar.gz";
- sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
+ sha256 = "e8451af61face57b7c5d09e71c0d27b8005f001ead56e9fdf470417e5cc6d479";
};
+ doCheck = false;
+
meta = {
homepage = "http://github.com/pytoolz/toolz/";
description = "List processing tools and functional utilities";
- license = licenses.bsd3;
- maintainers = with maintainers; [ fridh ];
};
};
@@ -308,11 +310,10 @@ Note also the line `doCheck = false;`, we explicitly disabled running the test-s
#### Develop local package
-As a Python developer you're likely aware of [development mode](http://pythonhosted.org/setuptools/setuptools.html#development-mode) (`python setup.py develop`);
+As a Python developer you're likely aware of [development mode](http://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode) (`python setup.py develop`);
instead of installing the package this command creates a special link to the project code.
That way, you can run updated code without having to reinstall after each and every change you make.
-Development mode is also available on Nix as [explained](http://nixos.org/nixpkgs/manual/#ssec-python-development) in the Nixpkgs manual.
-Let's see how you can use it.
+Development mode is also available. Let's see how you can use it.
In the previous Nix expression the source was fetched from an url. We can also refer to a local source instead using
@@ -409,36 +410,21 @@ and in this case the `python35` interpreter is automatically used.
### Interpreters
-Versions 2.6, 2.7, 3.3, 3.4 and 3.5 of the CPython interpreter are available on
-Nix and are available as `python26`, `python27`, `python33`, `python34` and
-`python35`. The PyPy interpreter is also available as `pypy`. Currently, the
-aliases `python` and `python3` correspond to respectively `python27` and
-`python35`. The Nix expressions for the interpreters can be found in
+Versions 2.6, 2.7, 3.3, 3.4 and 3.5 of the CPython interpreter are available as respectively
+`python26`, `python27`, `python33`, `python34` and `python35`. The PyPy interpreter
+is available as `pypy`. The aliases `python2` and `python3` correspond to respectively `python27` and
+`python35`. The default interpreter, `python`, maps to `python2`.
+The Nix expressions for the interpreters can be found in
`pkgs/development/interpreters/python`.
-
-#### Missing modules standard library
-
-The interpreters `python26` and `python27` do not include modules that
-require external dependencies. This is done in order to reduce the closure size.
-The following modules need to be added as `buildInput` explicitly:
-
-* `python.modules.bsddb`
-* `python.modules.curses`
-* `python.modules.curses_panel`
-* `python.modules.crypt`
-* `python.modules.gdbm`
-* `python.modules.sqlite3`
-* `python.modules.tkinter`
-* `python.modules.readline`
-
-For convenience `python27Full` and `python26Full` are provided with all
-modules included.
-
All packages depending on any Python interpreter get appended
`out/{python.sitePackages}` to `$PYTHONPATH` if such directory
exists.
+#### Missing `tkinter` module standard library
+
+To reduce closure size the `Tkinter`/`tkinter` is available as a separate package, `pythonPackages.tkinter`.
+
#### Attributes on interpreters packages
Each interpreter has the following attributes:
@@ -448,18 +434,21 @@ Each interpreter has the following attributes:
- `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`.
-- `executable`. Name of the interpreter executable, ie `python3.4`.
+- `executable`. Name of the interpreter executable, e.g. `python3.4`.
+- `pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
### Building packages and applications
-Python packages (libraries) and applications that use `setuptools` or
-`distutils` are typically built with respectively the `buildPythonPackage` and
-`buildPythonApplication` functions.
+Python libraries and applications that use `setuptools` or
+`distutils` are typically build with respectively the `buildPythonPackage` and
+`buildPythonApplication` functions. These two functions also support installing a `wheel`.
All Python packages reside in `pkgs/top-level/python-packages.nix` and all
-applications elsewhere. Some packages are also defined in
+applications elsewhere. In case a package is used as both a library and an application,
+then the package should be in `pkgs/top-level/python-packages.nix` since only those packages are made
+available for all interpreter versions. The preferred location for library expressions is in
`pkgs/development/python-modules`. It is important that these packages are
-called in `pkgs/top-level/python-packages.nix` and not elsewhere, to guarantee
+called from `pkgs/top-level/python-packages.nix` and not elsewhere, to guarantee
the right version of the package is built.
Based on the packages defined in `pkgs/top-level/python-packages.nix` an
@@ -475,15 +464,16 @@ sets are
and the aliases
-* `pkgs.pythonPackages` pointing to `pkgs.python27Packages`
+* `pkgs.python2Packages` pointing to `pkgs.python27Packages`
* `pkgs.python3Packages` pointing to `pkgs.python35Packages`
+* `pkgs.pythonPackages` pointing to `pkgs.python2Packages`
#### `buildPythonPackage` function
The `buildPythonPackage` function is implemented in
`pkgs/development/interpreters/python/build-python-package.nix`
-and can be used as:
+The following is an example:
twisted = buildPythonPackage {
name = "twisted-8.1.0";
@@ -534,7 +524,7 @@ All parameters from `mkDerivation` function are still supported.
* `postShellHook`: Hook to execute commands after `shellHook`.
* `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"]`.
* `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`: Format of the source. Options are `setup` for when the source has a `setup.py` and `setuptools` is used to build a wheel, and `wheel` in case the source is already a binary wheel. The default value is `setup`.
+* `format`: Format of the source. Valid options are `setuptools` (default), `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. In case you need to provide your own `buildPhase` and `installPhase` you can use `other`.
* `catchConflicts` 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`.
@@ -669,9 +659,8 @@ when you try to install a second environment.
Create a file, e.g. `build.nix`, with the following expression
```nix
with import {};
-with python35Packages;
-python.withPackages (ps: with ps; [ numpy ipython ])
+pkgs.python35.withPackages (ps: with ps; [ numpy ipython ])
```
and install it in your profile with
```
@@ -683,14 +672,15 @@ Now you can use the Python interpreter, as well as the extra packages that you a
If you prefer to, you could also add the environment as a package override to the Nixpkgs set.
```
- packageOverrides = pkgs: with pkgs; with python35Packages; {
- myEnv = python.withPackages (ps: with ps; [ numpy ipython ]);
+ packageOverrides = pkgs: with pkgs; {
+ myEnv = python35.withPackages (ps: with ps; [ numpy ipython ]);
};
```
and install it in your profile with
```
-nix-env -iA nixos.blogEnv
+nix-env -iA nixpkgs.myEnv
```
+We're installing using the attribute path and assume the channels is named `nixpkgs`.
Note that I'm using the attribute path here.
#### Environment defined in `/etc/nixos/configuration.nix`
@@ -699,7 +689,7 @@ For the sake of completeness, here's another example how to install the environm
```nix
environment.systemPackages = with pkgs; [
- (python35Packages.python.withPackages (ps: callPackage ../packages/common-python-packages.nix { pythonPackages = ps; }))
+ (python35.withPackages(ps: with ps; [ numpy ipython ]))
];
```
@@ -711,59 +701,55 @@ should also be done when packaging `A`.
### How to override a Python package?
-Recursively updating a package can be done with `pkgs.overridePackages` as explained in the Nixpkgs manual.
-Python attribute sets are created for each interpreter version. We will therefore override the attribute set for the interpreter version we're interested.
-In the following example we change the name of the package `pandas` to `foo`.
-```
-newpkgs = pkgs.overridePackages(self: super: rec {
- python35Packages = (super.python35Packages.override { self = python35Packages;})
- // { pandas = super.python35Packages.pandas.override {name = "foo";};
- };
-});
-```
-This can be tested with
-```
+We can override the interpreter and pass `packageOverrides`.
+In the following example we rename the `pandas` package and build it.
+```nix
with import {};
-(let
+let
+ python = let
+ packageOverrides = self: super: {
+ pandas = super.pandas.override {name="foo";};
+ };
+ in pkgs.python35.override {inherit packageOverrides;};
-newpkgs = pkgs.overridePackages(self: super: rec {
- python35Packages = (super.python35Packages.override { self = python35Packages;})
- // { pandas = super.python35Packages.pandas.override {name = "foo";};
- };
-});
-in newpkgs.python35.withPackages (ps: [ps.blaze])
-).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`.
-In the following example we use a different version of `scipy`. All packages in `newpkgs` will now use the updated `scipy` version.
+in python.pkgs.pandas
```
+Using `nix-build` on this expression will build the package `pandas`
+but with the new name `foo`.
+
+All packages in the package set will use the renamed package.
+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` and create an environment that uses it.
+All packages in the Python package set will now use the updated `scipy` version.
+
+```nix
with import {};
-(let
-
-newpkgs = pkgs.overridePackages(self: super: rec {
- python35Packages = super.python35Packages.override {
- self = python35Packages // { scipy = python35Packages.scipy_0_17;};
+(
+let
+ packageOverrides = self: super: {
+ scipy = super.scipy_0_17;
};
-});
-in newpkgs.python35.withPackages (ps: [ps.blaze])
+in (pkgs.python35.override {inherit packageOverrides;}).withPackages (ps: [ps.blaze])
).env
```
-The requested package `blaze` depends upon `pandas` which itself depends on `scipy`.
+The requested package `blaze` depends on `pandas` which itself depends on `scipy`.
-A similar example but now using `django`
+If you want the whole of Nixpkgs to use your modifications, then you can use `pkgs.overridePackages`
+as explained in this manual. In the following example we build a `inkscape` using a different version of `numpy`.
```
-with import {};
-
-(let
-
-newpkgs = pkgs.overridePackages(self: super: rec {
- python27Packages = (super.python27Packages.override {self = python27Packages;})
- // { django = super.python27Packages.django_1_9; };
-});
-in newpkgs.python27.withPackages (ps: [ps.django_guardian ])
-).env
+let
+ pkgs = import {};
+ newpkgs = pkgs.overridePackages ( pkgsself: pkgssuper: {
+ python27 = let
+ packageOverrides = self: super: {
+ numpy = super.numpy_1_10;
+ };
+ in pkgssuper.python27.override {inherit packageOverrides;};
+ } );
+in newpkgs.inkscape
```
### `python setup.py bdist_wheel` cannot create .whl
@@ -784,9 +770,9 @@ or the current time:
nix-shell --run "SOURCE_DATE_EPOCH=$(date +%s) python3 setup.py bdist_wheel"
```
or unset:
-"""
+```
nix-shell --run "unset SOURCE_DATE_EPOCH; python3 setup.py bdist_wheel"
-"""
+```
### `install_data` / `data_files` problems
diff --git a/doc/languages-frameworks/texlive.xml b/doc/languages-frameworks/texlive.xml
index 0e3c1dd13d72..fdee1e405ecc 100644
--- a/doc/languages-frameworks/texlive.xml
+++ b/doc/languages-frameworks/texlive.xml
@@ -35,6 +35,7 @@ texlive.combine {
You can list packages e.g. by nix-repl.
$ nix-repl
+nix-repl> :l <nixpkgs>
nix-repl> texlive.collection-<TAB>
diff --git a/doc/manual.xml b/doc/manual.xml
index 32e94e8e59c5..6ad66d486525 100644
--- a/doc/manual.xml
+++ b/doc/manual.xml
@@ -20,6 +20,7 @@
+
diff --git a/doc/multiple-output.xml b/doc/multiple-output.xml
index 309254f76aac..b7a363c750e6 100644
--- a/doc/multiple-output.xml
+++ b/doc/multiple-output.xml
@@ -45,34 +45,48 @@
File type groupsThe support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an outputFoo variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed – a default output name is defined, falling back to other possibilities if the output isn't defined.
+
$outputDev
is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to dev or out by default.
-
+
+
+
$outputBin
is meant for user-facing binaries, typically residing in bin/. They go to bin or out by default.
-
+
+
$outputLib
is meant for libraries, typically residing in lib/ and libexec/. They go to lib or out by default.
-
+
+
$outputDoc
is for user documentation, typically residing in share/doc/. It goes to doc or out by default.
-
+
+
- $outputDocdev
- is for developer documentation. Currently we count gtk-doc and man3 pages in there. It goes to docdev or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
-
+ $outputDevdoc
+ is for developer documentation. Currently we count gtk-doc in there. It goes to devdoc or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
+
+
$outputMan
is for man pages (except for section 3). They go to man or doc or $outputBin by default.
-
+
+
+
+ $outputDevman
+ is for section 3 man pages. They go to devman or $outputMan by default.
+
+
$outputInfo
is for info pages. They go to info or doc or $outputMan by default.
-
+
+
@@ -88,4 +102,3 @@
-
diff --git a/doc/package-notes.xml b/doc/package-notes.xml
index f0015a7f9ace..0ba7ec4c44d4 100644
--- a/doc/package-notes.xml
+++ b/doc/package-notes.xml
@@ -382,4 +382,138 @@ it. Place the resulting package.nix file into
+
+
+Steam
+
+
+
+Steam in Nix
+
+
+ Steam is distributed as a .deb file, for now only
+ as an i686 package (the amd64 package only has documentation).
+ When unpacked, it has a script called steam that
+ in ubuntu (their target distro) would go to /usr/bin
+ . When run for the first time, this script copies some
+ files to the user's home, which include another script that is the
+ ultimate responsible for launching the steam binary, which is also
+ in $HOME.
+
+
+ Nix problems and constraints:
+
+ We don't have /bin/bash and many
+ scripts point there. Similarly for /usr/bin/python
+ .
+ We don't have the dynamic loader in /lib
+ .
+ The steam.sh script in $HOME can
+ not be patched, as it is checked and rewritten by steam.
+ The steam binary cannot be patched, it's also checked.
+
+
+
+ The current approach to deploy Steam in NixOS is composing a FHS-compatible
+ chroot environment, as documented
+ here.
+ This allows us to have binaries in the expected paths without disrupting the system,
+ and to avoid patching them to work in a non FHS environment.
+
+
+
+
+
+
+How to play
+
+
+ For 64-bit systems it's important to have
+ hardware.opengl.driSupport32Bit = true;
+ in your /etc/nixos/configuration.nix. You'll also need
+ hardware.pulseaudio.support32Bit = true;
+ if you are using PulseAudio - this will enable 32bit ALSA apps integration.
+ To use the Steam controller, you need to add
+ services.udev.extraRules = ''
+ SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
+ KERNEL=="uinput", MODE="0660", GROUP="users", OPTIONS+="static_node=uinput"
+ '';
+ to your configuration.
+
+
+
+
+
+
+Troubleshooting
+
+
+
+
+
+ Steam fails to start. What do I do?
+ Try to run
+ strace steam
+ to see what is causing steam to fail.
+
+
+
+ Using the FOSS Radeon drivers
+
+ The open source radeon drivers need a newer libc++ than is provided
+ by the default runtime, which leads to a crash on launch. Use
+ environment.systemPackages = [(pkgs.steam.override { newStdcpp = true; })];
+ in your config if you get an error like
+
+libGL error: unable to load driver: radeonsi_dri.so
+libGL error: driver pointer missing
+libGL error: failed to load driver: radeonsi
+libGL error: unable to load driver: swrast_dri.so
+libGL error: failed to load driver: swrast
+
+ Steam ships statically linked with a version of libcrypto that
+ conflics with the one dynamically loaded by radeonsi_dri.so.
+ If you get the error
+ steam.sh: line 713: 7842 Segmentation fault (core dumped)
+ have a look at this pull request.
+
+
+
+
+
+ Java
+
+
+ There is no java in steam chrootenv by default. If you get a message like
+ /home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found
+ You need to add
+ steam.override { withJava = true; };
+ to your configuration.
+
+
+
+
+
+
+
+
+
+
+steam-run
+
+The FHS-compatible chroot used for steam can also be used to run
+other linux games that expect a FHS environment.
+To do it, add
+pkgs.(steam.override {
+ nativeOnly = true;
+ newStdcpp = true;
+ }).run
+to your configuration, rebuild, and run the game with
+steam-run ./foo
+
+
+
+
+
+
diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml
new file mode 100644
index 000000000000..f86928bcd5d0
--- /dev/null
+++ b/doc/reviewing-contributions.xml
@@ -0,0 +1,393 @@
+
+
+Reviewing contributions
+
+
+ The following section is a draft and reviewing policy is still being
+ discussed.
+
+
+The nixpkgs projects receives a fairly high number of contributions via
+ GitHub pull-requests. Reviewing and approving these is an important task and a
+ way to contribute to the project.
+
+The high change rate of nixpkgs make any pull request that is open for
+ long enough subject to conflicts that will require extra work from the
+ submitter or the merger. Reviewing pull requests in a timely manner and being
+ responsive to the comments is the key to avoid these. Github provides sort
+ filters that can be used to see the most
+ recently and the least
+ recently updated pull-requests.
+
+When reviewing a pull request, please always be nice and polite.
+ Controversial changes can lead to controversial opinions, but it is important
+ to respect every community members and their work.
+
+GitHub provides reactions, they are a simple and quick way to provide
+ feedback to pull-requests or any comments. The thumb-down reaction should be
+ used with care and if possible accompanied with some explanations so the
+ submitter has directions to improve his contribution.
+
+Pull-requests reviews should include a list of what has been reviewed in a
+ comment, so other reviewers and mergers can know the state of the
+ review.
+
+All the review template samples provided in this section are generic and
+ meant as examples. Their usage is optional and the reviewer is free to adapt
+ them to his liking.
+
+Package updates
+
+A package update is the most trivial and common type of pull-request.
+ These pull-requests mainly consist in updating the version part of the package
+ name and the source hash.
+It can happen that non trivial updates include patches or more complex
+ changes.
+
+Reviewing process:
+
+
+ Add labels to the pull-request. (Requires commit
+ rights)
+
+ 8.has: package (update) and any topic
+ label that fit the updated package.
+
+
+ Ensure that the package versioning is fitting the
+ guidelines.
+ Ensure that the commit text is fitting the
+ guidelines.
+ Ensure that the package maintainers are notified.
+
+ mention-bot usually notify GitHub users based on the
+ submitted changes, but it can happen that it misses some of the
+ package maintainers.
+
+
+ Ensure that the meta field contains correct
+ information.
+
+ License can change with version updates, so it should be
+ checked to be fitting upstream license.
+ If the package has no maintainer, a maintainer must be
+ set. This can be the update submitter or a community member that
+ accepts to take maintainership of the package.
+
+
+ Ensure that the code contains no typos.
+ Building the package locally.
+
+ Pull-requests are often targeted to the master or staging
+ branch so building the pull-request locally as it is submitted can
+ trigger a large amount of source builds.
+ It is possible to rebase the changes on nixos-unstable or
+ nixpkgs-unstable for easier review by running the following commands
+ from a nixpkgs clone.
+
+$ git remote add channels https://github.com/NixOS/nixpkgs-channels.git
+$ git fetch channels nixos-unstable
+$ git fetch origin pull/PRNUMBER/head
+$ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD
+
+
+
+ This should be done only once to be able to fetch channel
+ branches from the nixpkgs-channels repository.
+
+
+ Fetching the nixos-unstable branch.
+
+
+ Fetching the pull-request changes, PRNUMBER
+ is the number at the end of the pull-request title and
+ BASEBRANCH the base branch of the
+ pull-request.
+
+
+ Rebasing the pull-request changes to the nixos-unstable
+ branch.
+
+
+
+
+
+ The nox
+ tool can be used to review a pull-request content in a single command.
+ It doesn't rebase on a channel branch so it might trigger multiple
+ source builds. PRNUMBER should be replaced by the
+ number at the end of the pull-request title.
+
+$ nix-shell -p nox --run "nox-review -k pr PRNUMBER"
+
+
+
+
+ Running every binary.
+
+
+Sample template for a package update review
+
+##### Reviewed points
+
+- [ ] package name fits guidelines
+- [ ] package version fits guidelines
+- [ ] package build on ARCHITECTURE
+- [ ] executables tested on ARCHITECTURE
+- [ ] all depending packages build
+
+##### Possible improvements
+
+##### Comments
+
+
+
+
+New packages
+
+New packages are a common type of pull-requests. These pull requests
+ consists in adding a new nix-expression for a package.
+
+Reviewing process:
+
+
+ Add labels to the pull-request. (Requires commit
+ rights)
+
+ 8.has: package (new) and any topic
+ label that fit the new package.
+
+
+ Ensure that the package versioning is fitting the
+ guidelines.
+ Ensure that the commit name is fitting the
+ guidelines.
+ Ensure that the meta field contains correct
+ information.
+
+ License must be checked to be fitting upstream
+ license.
+ Platforms should be set or the package will not get binary
+ substitutes.
+ A maintainer must be set, this can be the package
+ submitter or a community member that accepts to take maintainership of
+ the package.
+
+
+ Ensure that the code contains no typos.
+ Ensure the package source.
+
+ Mirrors urls should be used when
+ available.
+ The most appropriate function should be used (e.g.
+ packages from GitHub should use
+ fetchFromGitHub).
+
+
+ Building the package locally.
+ Running every binary.
+
+
+Sample template for a new package review
+
+##### Reviewed points
+
+- [ ] package path fits guidelines
+- [ ] package name fits guidelines
+- [ ] package version fits guidelines
+- [ ] package build on ARCHITECTURE
+- [ ] executables tested on ARCHITECTURE
+- [ ] `meta.description` is set and fits guidelines
+- [ ] `meta.license` fits upstream license
+- [ ] `meta.platforms` is set
+- [ ] `meta.maintainers` is set
+- [ ] build time only dependencies are declared in `nativeBuildInputs`
+- [ ] source is fetched using the appropriate function
+- [ ] phases are respected
+- [ ] patches that are remotely available are fetched with `fetchpatch`
+
+##### Possible improvements
+
+##### Comments
+
+
+
+
+Module updates
+
+Module updates are submissions changing modules in some ways. These often
+ contains changes to the options or introduce new options.
+
+Reviewing process
+
+
+ Add labels to the pull-request. (Requires commit
+ rights)
+
+ 8.has: module (update) and any topic
+ label that fit the module.
+
+
+ Ensure that the module maintainers are notified.
+
+ Mention-bot notify GitHub users based on the submitted
+ changes, but it can happen that it miss some of the package
+ maintainers.
+
+
+ Ensure that the module tests, if any, are
+ succeeding.
+ Ensure that the introduced options are correct.
+
+ Type should be appropriate (string related types differs
+ in their merging capabilities, optionSet and
+ string types are deprecated).
+ Description, default and example should be
+ provided.
+
+
+ Ensure that option changes are backward compatible.
+
+ mkRenamedOptionModule and
+ mkAliasOptionModule functions provide way to make
+ option changes backward compatible.
+
+
+ Ensure that removed options are declared with
+ mkRemovedOptionModule
+ Ensure that changes that are not backward compatible are
+ mentioned in release notes.
+ Ensure that documentations affected by the change is
+ updated.
+
+
+Sample template for a module update review
+
+##### Reviewed points
+
+- [ ] changes are backward compatible
+- [ ] removed options are declared with `mkRemovedOptionModule`
+- [ ] changes that are not backward compatible are documented in release notes
+- [ ] module tests succeed on ARCHITECTURE
+- [ ] options types are appropriate
+- [ ] options description is set
+- [ ] options example is provided
+- [ ] documentation affected by the changes is updated
+
+##### Possible improvements
+
+##### Comments
+
+
+
+
+New modules
+
+New modules submissions introduce a new module to NixOS.
+
+
+ Add labels to the pull-request. (Requires commit
+ rights)
+
+ 8.has: module (new) and any topic label
+ that fit the module.
+
+
+ Ensure that the module tests, if any, are
+ succeeding.
+ Ensure that the introduced options are correct.
+
+ Type should be appropriate (string related types differs
+ in their merging capabilities, optionSet and
+ string types are deprecated).
+ Description, default and example should be
+ provided.
+
+
+ Ensure that module meta field is
+ present
+
+ Maintainers should be declared in
+ meta.maintainers.
+ Module documentation should be declared with
+ meta.doc.
+
+
+ Ensure that the module respect other modules
+ functionality.
+
+ For example, enabling a module should not open firewall
+ ports by default.
+
+
+
+
+Sample template for a new module review
+
+##### Reviewed points
+
+- [ ] module path fits the guidelines
+- [ ] module tests succeed on ARCHITECTURE
+- [ ] options have appropriate types
+- [ ] options have default
+- [ ] options have example
+- [ ] options have descriptions
+- [ ] No unneeded package is added to system.environmentPackages
+- [ ] meta.maintainers is set
+- [ ] module documentation is declared in meta.doc
+
+##### Possible improvements
+
+##### Comments
+
+
+
+
+Other submissions
+
+Other type of submissions requires different reviewing steps.
+
+If you consider having enough knowledge and experience in a topic and
+ would like to be a long-term reviewer for related submissions, please contact
+ the current reviewers for that topic. They will give you information about the
+ reviewing process.
+The main reviewers for a topic can be hard to find as there is no list, but
+checking past pull-requests to see who reviewed or git-blaming the code to see
+who committed to that topic can give some hints.
+
+Container system, boot system and library changes are some examples of the
+ pull requests fitting this category.
+
+
+
+Merging pull-requests
+
+It is possible for community members that have enough knowledge and
+ experience on a special topic to contribute by merging pull requests.
+
+TODO: add the procedure to request merging rights.
+
+
+
+In a case a contributor leaves definitively the Nix community, he should
+ create an issue or notify the mailing list with references of packages and
+ modules he maintains so the maintainership can be taken over by other
+ contributors.
+
+
+
diff --git a/doc/stdenv.xml b/doc/stdenv.xml
index c17d7c51ae21..68441ea9393a 100644
--- a/doc/stdenv.xml
+++ b/doc/stdenv.xml
@@ -27,7 +27,7 @@ stdenv.mkDerivation {
name = "libfoo-1.2.3";
src = fetchurl {
url = http://example.org/libfoo-1.2.3.tar.bz2;
- md5 = "e1ec107956b6ddcb0b8b0679367e9ac9";
+ sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
};
}
@@ -988,6 +988,41 @@ set debug-file-directory ~/.nix-profile/lib/debug
+The installCheck phase
+
+The installCheck phase checks whether the package was installed
+correctly by running its test suite against the installed directories.
+The default installCheck calls make
+installcheck.
+
+
+ Variables controlling the installCheck phase
+
+
+ doInstallCheck
+ If set to a non-empty string, the installCheck phase is
+ executed, otherwise it is skipped (default). Thus you should set
+
+ doInstallCheck = true;
+
+ in the derivation to enable install checks.
+
+
+
+ preInstallCheck
+ Hook executed at the start of the installCheck
+ phase.
+
+
+
+ postInstallCheck
+ Hook executed at the end of the installCheck
+ phase.
+
+
+
+
+The distribution
phase
@@ -1196,13 +1231,12 @@ echo @foo@
stripHashpathStrips the directory and hash part of a store
- path, storing the name part in the environment variable
- strippedName. For example:
+ path, outputting the name part to stdout.
+ For example:
-stripHash "/nix/store/9s9r019176g7cvn2nvcw41gsp862y6b4-coreutils-8.24"
# prints coreutils-8.24
-echo $strippedName
+stripHash "/nix/store/9s9r019176g7cvn2nvcw41gsp862y6b4-coreutils-8.24"
If you wish to store the result in another variable, then the
@@ -1210,7 +1244,7 @@ echo $strippedName
name="/nix/store/9s9r019176g7cvn2nvcw41gsp862y6b4-coreutils-8.24"
-someVar=$(stripHash $name; echo $strippedName)
+someVar=$(stripHash $name)
diff --git a/lib/attrsets.nix b/lib/attrsets.nix
index 686e125f100c..c1bd764c70dc 100644
--- a/lib/attrsets.nix
+++ b/lib/attrsets.nix
@@ -296,12 +296,17 @@ rec {
/* Converts a store path to a fake derivation. */
toDerivation = path:
- let path' = builtins.storePath path; in
- { type = "derivation";
- name = builtins.unsafeDiscardStringContext (builtins.substring 33 (-1) (baseNameOf path'));
- outPath = path';
- outputs = [ "out" ];
- };
+ let
+ path' = builtins.storePath path;
+ res =
+ { type = "derivation";
+ name = builtins.unsafeDiscardStringContext (builtins.substring 33 (-1) (baseNameOf path'));
+ outPath = path';
+ outputs = [ "out" ];
+ out = res;
+ outputName = "out";
+ };
+ in res;
/* If `cond' is true, return the attribute set `as',
@@ -386,7 +391,7 @@ rec {
);
in f [] [rhs lhs];
- /* A recursive variant of the update operator ‘//’. The recusion
+ /* A recursive variant of the update operator ‘//’. The recursion
stops when one of the attribute values is not an attribute set,
in which case the right hand side value takes precedence over the
left hand side value.
@@ -455,7 +460,7 @@ rec {
getDev = getOutput "dev";
/* Pick the outputs of packages to place in buildInputs */
- chooseDevOutputs = drvs: builtins.map (drv: if drv.outputUnspecified or false then drv.dev or drv else drv) drvs;
+ chooseDevOutputs = drvs: builtins.map getDev drvs;
/*** deprecated stuff ***/
diff --git a/lib/customisation.nix b/lib/customisation.nix
index efe82d786600..3e6e279824be 100644
--- a/lib/customisation.nix
+++ b/lib/customisation.nix
@@ -56,16 +56,18 @@ rec {
ff = f origArgs;
overrideWith = newArgs: origArgs // (if builtins.isFunction newArgs then newArgs origArgs else newArgs);
in
- if builtins.isAttrs ff then (ff //
- { override = newArgs: makeOverridable f (overrideWith newArgs);
- overrideDerivation = fdrv:
- makeOverridable (args: overrideDerivation (f args) fdrv) origArgs;
- })
- else if builtins.isFunction ff then
- { override = newArgs: makeOverridable f (overrideWith newArgs);
- __functor = self: ff;
- overrideDerivation = throw "overrideDerivation not yet supported for functors";
- }
+ if builtins.isAttrs ff then (ff // {
+ override = newArgs: makeOverridable f (overrideWith newArgs);
+ overrideDerivation = fdrv:
+ makeOverridable (args: overrideDerivation (f args) fdrv) origArgs;
+ ${if ff ? overrideAttrs then "overrideAttrs" else null} = fdrv:
+ makeOverridable (args: (f args).overrideAttrs fdrv) origArgs;
+ })
+ else if builtins.isFunction ff then {
+ override = newArgs: makeOverridable f (overrideWith newArgs);
+ __functor = self: ff;
+ overrideDerivation = throw "overrideDerivation not yet supported for functors";
+ }
else ff;
diff --git a/lib/default.nix b/lib/default.nix
index 32ac0c58af6c..c0d7899b882a 100644
--- a/lib/default.nix
+++ b/lib/default.nix
@@ -1,27 +1,47 @@
-let
+let
+ # trivial, often used functions
trivial = import ./trivial.nix;
+
+ # datatypes
+ attrsets = import ./attrsets.nix;
lists = import ./lists.nix;
strings = import ./strings.nix;
stringsWithDeps = import ./strings-with-deps.nix;
- attrsets = import ./attrsets.nix;
+
+ # packaging
+ customisation = import ./customisation.nix;
+ maintainers = import ./maintainers.nix;
+ meta = import ./meta.nix;
sources = import ./sources.nix;
+
+ # module system
modules = import ./modules.nix;
options = import ./options.nix;
types = import ./types.nix;
- meta = import ./meta.nix;
- debug = import ./debug.nix;
- misc = import ./deprecated.nix;
- maintainers = import ./maintainers.nix;
+
+ # constants
+ licenses = import ./licenses.nix;
platforms = import ./platforms.nix;
systems = import ./systems.nix;
- customisation = import ./customisation.nix;
- licenses = import ./licenses.nix;
+
+ # misc
+ debug = import ./debug.nix;
+ generators = import ./generators.nix;
+ misc = import ./deprecated.nix;
+
+ # domain-specific
sandbox = import ./sandbox.nix;
+ fetchers = import ./fetchers.nix;
in
- { inherit trivial lists strings stringsWithDeps attrsets sources options
- modules types meta debug maintainers licenses platforms systems sandbox;
+ { inherit trivial
+ attrsets lists strings stringsWithDeps
+ customisation maintainers meta sources
+ modules options types
+ licenses platforms systems
+ debug generators misc
+ sandbox fetchers;
}
# !!! don't include everything at top-level; perhaps only the most
# commonly used functions.
diff --git a/lib/fetchers.nix b/lib/fetchers.nix
new file mode 100644
index 000000000000..19d89d6c4074
--- /dev/null
+++ b/lib/fetchers.nix
@@ -0,0 +1,12 @@
+# snippets that can be shared by mutliple fetchers (pkgs/build-support)
+{
+
+ proxyImpureEnvVars = [
+ # We borrow these environment variables from the caller to allow
+ # easy proxy configuration. This is impure, but a fixed-output
+ # derivation like fetchurl is allowed to do so since its result is
+ # by definition pure.
+ "http_proxy" "https_proxy" "ftp_proxy" "all_proxy" "no_proxy"
+ ];
+
+}
diff --git a/lib/generators.nix b/lib/generators.nix
new file mode 100644
index 000000000000..4d3c920b0ae3
--- /dev/null
+++ b/lib/generators.nix
@@ -0,0 +1,93 @@
+/* Functions that generate widespread file
+ * formats from nix data structures.
+ *
+ * They all follow a similar interface:
+ * generator { config-attrs } data
+ *
+ * Tests can be found in ./tests.nix
+ * Documentation in the manual, #sec-generators
+ */
+with import ./trivial.nix;
+let
+ libStr = import ./strings.nix;
+ libAttr = import ./attrsets.nix;
+
+ flipMapAttrs = flip libAttr.mapAttrs;
+in
+
+rec {
+
+ /* Generate a line of key k and value v, separated by
+ * character sep. If sep appears in k, it is escaped.
+ * Helper for synaxes with different separators.
+ *
+ * mkKeyValueDefault ":" "f:oo" "bar"
+ * > "f\:oo:bar"
+ */
+ mkKeyValueDefault = sep: k: v:
+ "${libStr.escape [sep] k}${sep}${toString v}";
+
+
+ /* Generate a key-value-style config file from an attrset.
+ *
+ * mkKeyValue is the same as in toINI.
+ */
+ toKeyValue = {
+ mkKeyValue ? mkKeyValueDefault "="
+ }: attrs:
+ let mkLine = k: v: mkKeyValue k v + "\n";
+ in libStr.concatStrings (libAttr.mapAttrsToList mkLine attrs);
+
+
+ /* Generate an INI-style config file from an
+ * attrset of sections to an attrset of key-value pairs.
+ *
+ * generators.toINI {} {
+ * foo = { hi = "${pkgs.hello}"; ciao = "bar"; };
+ * baz = { "also, integers" = 42; };
+ * }
+ *
+ *> [baz]
+ *> also, integers=42
+ *>
+ *> [foo]
+ *> ciao=bar
+ *> hi=/nix/store/y93qql1p5ggfnaqjjqhxcw0vqw95rlz0-hello-2.10
+ *
+ * The mk* configuration attributes can generically change
+ * the way sections and key-value strings are generated.
+ *
+ * For more examples see the test cases in ./tests.nix.
+ */
+ toINI = {
+ # apply transformations (e.g. escapes) to section names
+ mkSectionName ? (name: libStr.escape [ "[" "]" ] name),
+ # format a setting line from key and value
+ mkKeyValue ? mkKeyValueDefault "="
+ }: attrsOfAttrs:
+ let
+ # map function to string for each key val
+ mapAttrsToStringsSep = sep: mapFn: attrs:
+ libStr.concatStringsSep sep
+ (libAttr.mapAttrsToList mapFn attrs);
+ mkSection = sectName: sectValues: ''
+ [${mkSectionName sectName}]
+ '' + toKeyValue { inherit mkKeyValue; } sectValues;
+ in
+ # map input to ini sections
+ mapAttrsToStringsSep "\n" mkSection attrsOfAttrs;
+
+
+ /* Generates JSON from an arbitrary (non-function) value.
+ * For more information see the documentation of the builtin.
+ */
+ toJSON = {}: builtins.toJSON;
+
+
+ /* YAML has been a strict superset of JSON since 1.2, so we
+ * use toJSON. Before it only had a few differences referring
+ * to implicit typing rules, so it should work with older
+ * parsers as well.
+ */
+ toYAML = {}@args: toJSON args;
+}
diff --git a/lib/licenses.nix b/lib/licenses.nix
index 3708b1eb15cf..e5784ce22022 100644
--- a/lib/licenses.nix
+++ b/lib/licenses.nix
@@ -65,6 +65,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "Boost Software License 1.0";
};
+ beerware = spdx {
+ spdxId = "Beerware";
+ fullName = ''Beerware License'';
+ };
+
bsd2 = spdx {
spdxId = "BSD-2-Clause";
fullName = ''BSD 2-clause "Simplified" License'';
@@ -105,6 +110,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "Creative Commons Attribution Non Commercial Share Alike 4.0";
};
+ cc-by-nd-30 = spdx {
+ spdxId = "CC-BY-ND-3.0";
+ fullName = "Creative Commons Attribution-No Derivative Works v3.00";
+ };
+
cc-by-sa-25 = spdx {
spdxId = "CC-BY-SA-2.5";
fullName = "Creative Commons Attribution Share Alike 2.5";
@@ -439,6 +449,12 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "Sleepycat License";
};
+ smail = {
+ shortName = "smail";
+ fullName = "SMAIL General Public License";
+ url = http://metadata.ftp-master.debian.org/changelogs/main/d/debianutils/debianutils_4.8.1_copyright;
+ };
+
tcltk = spdx {
spdxId = "TCL";
fullName = "TCL/TK License";
@@ -470,6 +486,11 @@ lib.mapAttrs (n: v: v // { shortName = n; }) rec {
fullName = "The Unlicense";
};
+ upl = {
+ fullName = "Universal Permissive License";
+ url = "https://oss.oracle.com/licenses/upl/";
+ };
+
vim = spdx {
spdxId = "Vim";
fullName = "Vim License";
diff --git a/lib/maintainers.nix b/lib/maintainers.nix
index 8c29c9b4cf26..95b836130af4 100644
--- a/lib/maintainers.nix
+++ b/lib/maintainers.nix
@@ -10,8 +10,10 @@
aaronschif = "Aaron Schif ";
abaldeau = "Andreas Baldeau ";
abbradar = "Nikolay Amiantov ";
+ abigailbuccaneer = "Abigail Bunyan ";
aboseley = "Adam Boseley ";
abuibrahim = "Ruslan Babayev ";
+ acowley = "Anthony Cowley ";
adev = "Adrien Devresse ";
Adjective-Object = "Maxwell Huang-Hobbs ";
adnelson = "Allen Nelson ";
@@ -28,24 +30,30 @@
all = "Nix Committers ";
ambrop72 = "Ambroz Bizjak ";
amiddelk = "Arie Middelkoop ";
+ amiloradovsky = "Andrew Miloradovsky ";
amorsillo = "Andrew Morsillo ";
AndersonTorres = "Anderson Torres ";
anderspapitto = "Anders Papitto ";
andres = "Andres Loeh ";
andrewrk = "Andrew Kelley ";
+ andsild = "Anders Sildnes ";
aneeshusa = "Aneesh Agrawal ";
antono = "Antono Vasiljev ";
+ apeyroux = "Alexandre Peyroux ";
ardumont = "Antoine R. Dumont ";
aristid = "Aristid Breitkreuz ";
arobyn = "Alexei Robyn ";
artuuge = "Artur E. Ruuge ";
ashalkhakov = "Artyom Shalkhakov ";
+ aske = "Kirill Boltaev ";
asppsa = "Alastair Pharo ";
astsmtl = "Alexander Tsamutali ";
+ asymmetric = "Lorenzo Manacorda ";
aszlig = "aszlig ";
auntie = "Jonathan Glines ";
avnik = "Alexander V. Nikolaev ";
aycanirican = "Aycan iRiCAN ";
+ bachp = "Pascal Bach ";
badi = "Badi' Abdul-Wahid ";
balajisivaraman = "Balaji Sivaraman";
Baughn = "Svein Ove Aas ";
@@ -81,39 +89,52 @@
chris-martin = "Chris Martin ";
chrisjefferson = "Christopher Jefferson ";
christopherpoole = "Christopher Mark Poole ";
+ ckampka = "Christian Kampka ";
cko = "Christine Koppelt ";
cleverca22 = "Michael Bishop ";
cmcdragonkai = "Roger Qiu ";
+ cmfwyp = "cmfwyp ";
coconnor = "Corey O'Connor ";
codsl = "codsl ";
codyopel = "Cody Opel ";
colemickens = "Cole Mickens ";
copumpkin = "Dan Peebles ";
+ corngood = "David McFarland ";
coroa = "Jonas Hörsch ";
couchemar = "Andrey Pavlov ";
cransom = "Casey Ransom ";
+ cryptix = "Henry Bubert ";
CrystalGamma = "Jona Stubbe ";
cstrahan = "Charles Strahan ";
cwoac = "Oliver Matthews ";
DamienCassou = "Damien Cassou ";
+ danbst = "Danylo Hlynskyi ";
+ danielfullmer = "Daniel Fullmer ";
dasuxullebt = "Christoph-Simon Senjak ";
davidak = "David Kleuker ";
davidrusu = "David Rusu ";
+ davorb = "Davor Babic ";
dbohdan = "Danyil Bohdan ";
dbrock = "Daniel Brockman ";
deepfire = "Kosyrev Serge <_deepfire@feelingofgreen.ru>";
demin-dmitriy = "Dmitriy Demin ";
DerGuteMoritz = "Moritz Heidkamp ";
+ DerTim1 = "Tim Digel ";
desiderius = "Didier J. Devroye ";
devhell = "devhell <\"^\"@regexmail.net>";
dezgeg = "Tuomas Tynkkynen ";
dfoxfranke = "Daniel Fox Franke ";
dgonyeo = "Derek Gonyeo ";
+ dipinhora = "Dipin Hora ";
dmalikov = "Dmitry Malikov ";
dochang = "Desmond O. Chang ";
+ domenkozar = "Domen Kozar ";
doublec = "Chris Double ";
+ dpaetzel = "David Pätzel ";
drets = "Dmytro Rets ";
drewkett = "Andrew Burkett ";
+ dtzWill = "Will Dietz ";
+ e-user = "Alexander Kahl ";
ebzzry = "Rommel Martinez ";
ederoyd46 = "Matthew Brown ";
eduarrrd = "Eduard Bachmakov ";
@@ -123,6 +144,7 @@
ehmry = "Emery Hemingway ";
eikek = "Eike Kettner ";
elasticdog = "Aaron Bull Schaefer ";
+ eleanor = "Dejan Lukan ";
elitak = "Eric Litak ";
ellis = "Ellis Whitehead ";
epitrochoid = "Mabry Cervin ";
@@ -130,6 +152,7 @@
ericsagnes = "Eric Sagnes ";
erikryb = "Erik Rybakken ";
ertes = "Ertugrul Söylemez ";
+ ethercrow = "Dmitry Ivanov ";
exi = "Reno Reckling ";
exlevan = "Alexey Levan ";
expipiplus1 = "Joe Hermaszewski ";
@@ -158,32 +181,40 @@
giogadi = "Luis G. Torres ";
gleber = "Gleb Peregud ";
globin = "Robin Gloster ";
+ gnidorah = "Alex Ivanov ";
goibhniu = "Cillian de Róiste ";
Gonzih = "Max Gonzih ";
+ goodrone = "Andrew Trachenko ";
gpyh = "Yacine Hmito ";
grahamc = "Graham Christensen ";
gridaphobe = "Eric Seidel ";
guibert = "David Guibert ";
+ guillaumekoenig = "Guillaume Koenig ";
+ guyonvarch = "Joris Guyonvarch ";
+ hakuch = "Jesse Haber-Kucharsky ";
havvy = "Ryan Scheel ";
hbunke = "Hendrik Bunke ";
hce = "Hans-Christian Esperer ";
henrytill = "Henry Till ";
- hiberno = "Christian Lask ";
hinton = "Tom Hinton ";
hrdinka = "Christoph Hrdinka ";
iand675 = "Ian Duncan ";
ianwookim = "Ian-Woo Kim ";
- domenkozar = "Domen Kozar ";
igsha = "Igor Sharonov ";
ikervagyok = "Balázs Lengyel ";
+ ivan-tkatchev = "Ivan Tkatchev ";
j-keck = "Jürgen Keck ";
jagajaga = "Arseniy Seroka ";
javaguirre = "Javier Aguirre ";
jb55 = "William Casarin ";
+ jbedo = "Justin Bedő ";
jcumming = "Jack Cummings ";
+ jdagilliland = "Jason Gilliland ";
jefdaj = "Jeffrey David Johnson ";
+ jerith666 = "Matt McHenry ";
jfb = "James Felix Black ";
jgeerds = "Jascha Geerds ";
+ jgertm = "Tim Jaeger ";
jgillich = "Jakob Gillich ";
jirkamarsik = "Jirka Marsik ";
joachifm = "Joachim Fasting ";
@@ -191,17 +222,22 @@
joelmo = "Joel Moberg ";
joelteon = "Joel Taylor ";
joko = "Ioannis Koutras ";
+ jonafato = "Jon Banafato ";
jpbernardy = "Jean-Philippe Bernardy ";
jraygauthier = "Raymond Gauthier ";
juliendehos = "Julien Dehos ";
jwiegley = "John Wiegley ";
jwilberding = "Jordan Wilberding ";
jzellner = "Jeff Zellner ";
+ kaiha = "Kai Harries ";
kamilchm = "Kamil Chmielewski ";
kampfschlaefer = "Arnold Krille ";
kevincox = "Kevin Cox ";
khumba = "Bryan Gardiner ";
+ KibaFox = "Kiba Fox ";
+ kierdavis = "Kier Davis ";
kkallio = "Karn Kallio ";
+ knedlsepp = "Josef Kemetmüller ";
koral = "Koral ";
kovirobi = "Kovacsics Robert ";
kragniz = "Louis Taylor ";
@@ -209,22 +245,25 @@
lassulus = "Lassulus ";
layus = "Guillaume Maudoux ";
ldesgoui = "Lucas Desgouilles ";
+ league = "Christopher League ";
lebastr = "Alexander Lebedev ";
leenaars = "Michiel Leenaars ";
leonardoce = "Leonardo Cecchi ";
lethalman = "Luca Bruno ";
lewo = "Antoine Eiche ";
+ lheckemann = "Linus Heckemann ";
lhvwb = "Nathaniel Baxter ";
lihop = "Leroy Hopson ";
linquize = "Linquize ";
linus = "Linus Arver ";
lnl7 = "Daiderd Jordan ";
+ loskutov = "Ignat Loskutov ";
lovek323 = "Jason O'Conal ";
lowfatcomputing = "Andreas Wagner ";
lsix = "Lancelot SIX ";
+ lucas8 = "Luc Chabassier ";
ludo = "Ludovic Courtès ";
luispedro = "Luis Pedro Coelho ";
- lukasepple = "Lukas Epple ";
lukego = "Luke Gorrie ";
lw = "Sergey Sofeychuk ";
madjar = "Georges Dubus ";
@@ -240,25 +279,32 @@
martingms = "Martin Gammelsæter ";
matejc = "Matej Cotman ";
mathnerd314 = "Mathnerd314 ";
+ matthewbauer = "Matthew Bauer ";
matthiasbeyer = "Matthias Beyer ";
maurer = "Matthew Maurer ";
mbakke = "Marius Bakke ";
- matthewbauer = "Matthew Bauer ";
+ mbbx6spp = "Susan Potter ";
mbe = "Brandon Edens ";
mboes = "Mathieu Boespflug ";
mcmtroffaes = "Matthias C. M. Troffaes ";
+ mdaiter = "Matthew S. Daiter ";
meditans = "Carlo Nucera ";
meisternu = "Matt Miemiec ";
+ mguentner = "Maximilian Güntner ";
mic92 = "Jörg Thalheim ";
michaelpj = "Michael Peyton Jones ";
michalrus = "Michal Rus ";
michelk = "Michel Kuhlmann ";
+ mikefaille = "Michaël Faille ";
mimadrid = "Miguel Madrid ";
mingchuan = "Ming Chuan ";
mirdhyn = "Merlin Gaillard ";
mirrexagon = "Andrew Abbott ";
+ mjanczyk = "Marcin Janczyk ";
+ mlieberman85 = "Michael Lieberman ";
modulistic = "Pablo Costa ";
mog = "Matthew O'Gorman ";
+ montag451 = "montag451 ";
moosingin3space = "Nathan Moos ";
moretea = "Maarten Hoogendoorn ";
mornfall = "Petr Ročkai ";
@@ -266,6 +312,7 @@
mounium = "Katona László ";
MP2E = "Cray Elliott ";
mpscholten = "Marc Scholten ";
+ mpsyco = "Francis St-Amour ";
msackman = "Matthew Sackman ";
mschristiansen = "Mikkel Christiansen ";
msteen = "Matthijs Steen ";
@@ -273,23 +320,29 @@
mudri = "James Wood ";
muflax = "Stefan Dorn ";
myrl = "Myrl Hex ";
+ namore = "Roman Naumann ";
nand0p = "Fernando Jose Pando ";
- nathan-gs = "Nathan Bijnens ";
Nate-Devv = "Nathan Moore ";
+ nathan-gs = "Nathan Bijnens ";
nckx = "Tobias Geerinckx-Rice ";
nequissimus = "Tim Steinbach ";
nfjinjing = "Jinjing Wang ";
+ nhooyr = "Anmol Sethi ";
+ nicknovitski = "Nick Novitski ";
nico202 = "Nicolò Balzarotti ";
- notthemessiah = "Brian Cohen ";
NikolaMandic = "Ratko Mladic ";
+ notthemessiah = "Brian Cohen ";
np = "Nicolas Pouillard ";
nslqqq = "Nikita Mikhailov ";
obadz = "obadz