33045 files changed+2279430−879444
30045 more files changed are not listed.
.editorconfig+68−9
@@ -1,5 +1,5 @@
11# EditorConfig configuration for nixpkgs
2−# http://EditorConfig.org
2+# https://EditorConfig.org
33
44# Top-most EditorConfig file
55root = true
@@ -11,18 +11,77 @@ insert_final_newline = true
1111trim_trailing_whitespace = true
1212charset = utf-8
1313
14+# Ignore diffs/patches
15+[*.{diff,patch}]
16+end_of_line = unset
17+insert_final_newline = unset
18+trim_trailing_whitespace = unset
19+
1420# see https://nixos.org/nixpkgs/manual/#chap-conventions
1521
16−# Match nix/ruby/docbook files, set indent to spaces with width of two
17−[*.{nix,rb,xml}]
22+# Match json/lockfiles/markdown/nix/perl/python/ruby/shell/docbook files, set indent to spaces
23+[*.{json,lock,md,nix,pl,pm,py,rb,sh,xml}]
1824indent_style = space
25+
26+# Match docbook files, set indent width of one
27+[*.xml]
28+indent_size = 1
29+
30+# Match json/lockfiles/markdown/nix/ruby files, set indent width of two
31+[*.{json,lock,md,nix,rb}]
1932indent_size = 2
2033
21−# Match shell/python/perl scripts, set indent to spaces with width of four
22−[*.{sh,py,pl}]
23−indent_style = space
34+# Match perl/python/shell scripts, set indent width of four
35+[*.{pl,pm,py,sh}]
2436indent_size = 4
2537
26−# Match diffs, avoid to trim trailing whitespace
27−[*.{diff,patch}]
28−trim_trailing_whitespace = false
38+# Match gemfiles, set indent to spaces with width of two
39+[Gemfile]
40+indent_size = 2
41+indent_style = space
42+
43+# Disable file types or individual files
44+# some of these files may be auto-generated and/or require significant changes
45+
46+[*.{c,h}]
47+insert_final_newline = unset
48+trim_trailing_whitespace = unset
49+
50+[*.{asc,key,ovpn}]
51+insert_final_newline = unset
52+end_of_line = unset
53+trim_trailing_whitespace = unset
54+
55+[*.lock]
56+indent_size = unset
57+
58+# trailing whitespace is an actual syntax element of classic Markdown/
59+# CommonMark to enforce a line break
60+[*.md]
61+trim_trailing_whitespace = unset
62+
63+[eggs.nix]
64+trim_trailing_whitespace = unset
65+
66+[nixos/modules/services/networking/ircd-hybrid/*.{conf,in}]
67+trim_trailing_whitespace = unset
68+
69+[pkgs/build-support/dotnetenv/Wrapper/**]
70+end_of_line = unset
71+indent_style = unset
72+insert_final_newline = unset
73+trim_trailing_whitespace = unset
74+
75+[pkgs/development/compilers/elm/registry.dat]
76+end_of_line = unset
77+insert_final_newline = unset
78+
79+[pkgs/development/haskell-modules/hackage-packages.nix]
80+indent_style = unset
81+trim_trailing_whitespace = unset
82+
83+[pkgs/servers/dict/wordnet_structures.py]
84+trim_trailing_whitespace = unset
85+
86+[pkgs/tools/misc/timidity/timidity.cfg]
87+trim_trailing_whitespace = unset
.git-blame-ignore-revsnew file+32
@@ -0,0 +1,32 @@
1+# This file contains a list of commits that are not likely what you
2+# are looking for in a blame, such as mass reformatting or renaming.
3+# You can set this file as a default ignore file for blame by running
4+# the following command.
5+#
6+# $ git config blame.ignoreRevsFile .git-blame-ignore-revs
7+#
8+# To temporarily not use this file add
9+# --ignore-revs-file=""
10+# to your blame command.
11+#
12+# The ignoreRevsFile can't be set globally due to blame failing if the file isn't present.
13+# To not have to set the option in every repository it is needed in,
14+# save the following script in your path with the name "git-bblame"
15+# now you can run
16+# $ git bblame $FILE
17+# to use the .git-blame-ignore-revs file if it is present.
18+#
19+# #!/usr/bin/env bash
20+# repo_root=$(git rev-parse --show-toplevel)
21+# if [[ -e $repo_root/.git-blame-ignore-revs ]]; then
22+# git blame --ignore-revs-file="$repo_root/.git-blame-ignore-revs" $@
23+# else
24+# git blame $@
25+# fi
26+
27+
28+# nixos/modules/rename: Sort alphabetically
29+1f71224fe86605ef4cd23ed327b3da7882dad382
30+
31+# nixos: fix module paths in rename.nix
32+d08ede042b74b8199dc748323768227b88efcf7c
.github/CODEOWNERS+217−54
@@ -6,33 +6,57 @@
66#
77# For documentation on this file, see https://help.github.com/articles/about-codeowners/
88# Mentioned users will get code review requests.
9+#
10+# IMPORTANT NOTE: in order to actually get pinged, commit access is required.
11+# This also holds true for GitHub teams. Since almost none of our teams have write
12+# permissions, you need to list all members of the team with commit access individually.
913
1014# This file
1115/.github/CODEOWNERS @edolstra
1216
17+# GitHub actions
18+/.github/workflows @NixOS/Security @Mic92 @zowoq
19+/.github/workflows/merge-staging @FRidh
20+
21+# EditorConfig
22+/.editorconfig @Mic92 @zowoq
23+
1324# Libraries
14−/lib @edolstra @nbp
15−/lib/systems @nbp @ericson2314 @matthewbauer
25+/lib @edolstra @nbp @infinisil
26+/lib/systems @alyssais @nbp @ericson2314 @matthewbauer
1627/lib/generators.nix @edolstra @nbp @Profpatsch
28+/lib/cli.nix @edolstra @nbp @Profpatsch
1729/lib/debug.nix @edolstra @nbp @Profpatsch
30+/lib/asserts.nix @edolstra @nbp @Profpatsch
1831
1932# Nixpkgs Internals
20−/default.nix @nbp
21−/pkgs/top-level/default.nix @nbp @Ericson2314
22−/pkgs/top-level/impure.nix @nbp @Ericson2314
23−/pkgs/top-level/stage.nix @nbp @Ericson2314 @matthewbauer
24−/pkgs/top-level/splice.nix @Ericson2314 @matthewbauer
25−/pkgs/top-level/release-cross.nix @Ericson2314 @matthewbauer
26−/pkgs/stdenv/generic @Ericson2314 @matthewbauer
27−/pkgs/stdenv/cross @Ericson2314 @matthewbauer
28−/pkgs/build-support/cc-wrapper @Ericson2314 @orivej
29−/pkgs/build-support/bintools-wrapper @Ericson2314 @orivej
30−/pkgs/build-support/setup-hooks @Ericson2314
33+/default.nix @nbp
34+/pkgs/top-level/default.nix @nbp @Ericson2314
35+/pkgs/top-level/impure.nix @nbp @Ericson2314
36+/pkgs/top-level/stage.nix @nbp @Ericson2314 @matthewbauer
37+/pkgs/top-level/splice.nix @Ericson2314 @matthewbauer
38+/pkgs/top-level/release-cross.nix @Ericson2314 @matthewbauer
39+/pkgs/stdenv/generic @Ericson2314 @matthewbauer
40+/pkgs/stdenv/cross @Ericson2314 @matthewbauer
41+/pkgs/build-support/cc-wrapper @Ericson2314
42+/pkgs/build-support/bintools-wrapper @Ericson2314
43+/pkgs/build-support/setup-hooks @Ericson2314
44+/pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
45+/pkgs/build-support/setup-hooks/auto-patchelf.py @layus
46+
47+# Nixpkgs build-support
48+/pkgs/build-support/writers @lassulus @Profpatsch
49+
50+# Nixpkgs documentation
51+/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
52+/maintainers/scripts/doc @jtojnar @ryantm
53+/doc/build-aux/pandoc-filters @jtojnar
54+/doc/contributing/contributing-to-documentation.chapter.md @jtojnar
3155
3256# NixOS Internals
33−/nixos/default.nix @nbp
34−/nixos/lib/from-env.nix @nbp
35−/nixos/lib/eval-config.nix @nbp
57+/nixos/default.nix @nbp @infinisil
58+/nixos/lib/from-env.nix @nbp @infinisil
59+/nixos/lib/eval-config.nix @nbp @infinisil
3660/nixos/doc/manual/configuration/abstractions.xml @nbp
3761/nixos/doc/manual/configuration/config-file.xml @nbp
3862/nixos/doc/manual/configuration/config-syntax.xml @nbp
@@ -46,38 +70,59 @@
4670/nixos/doc/manual/development/writing-modules.xml @nbp
4771/nixos/doc/manual/man-nixos-option.xml @nbp
4872/nixos/modules/installer/tools/nixos-option.sh @nbp
73+/nixos/modules/system @dasJ
4974
50−# NixOS modules
51−/nixos/modules @Infinisil
75+# NixOS integration test driver
76+/nixos/lib/test-driver @tfc
77+
78+# Systemd
79+/nixos/modules/system/boot/systemd.nix @NixOS/systemd
80+/nixos/modules/system/boot/systemd @NixOS/systemd
81+/nixos/lib/systemd-*.nix @NixOS/systemd
82+/pkgs/os-specific/linux/systemd @NixOS/systemd
83+
84+# Updaters
85+## update.nix
86+/maintainers/scripts/update.nix @jtojnar
87+/maintainers/scripts/update.py @jtojnar
88+## common-updater-scripts
89+/pkgs/common-updater/scripts/update-source-version @jtojnar
5290
5391# Python-related code and docs
54−/maintainers/scripts/update-python-libraries @FRidh
55−/pkgs/top-level/python-packages.nix @FRidh
56−/pkgs/development/interpreters/python @FRidh
57−/pkgs/development/python-modules @FRidh
58−/doc/languages-frameworks/python.md @FRidh
92+/maintainers/scripts/update-python-libraries @FRidh
93+/pkgs/top-level/python-packages.nix @FRidh @jonringer
94+/pkgs/development/interpreters/python @FRidh
95+/pkgs/development/python-modules @FRidh @jonringer
96+/doc/languages-frameworks/python.section.md @FRidh
97+/pkgs/development/tools/poetry2nix @adisbladis
98+/pkgs/development/interpreters/python/hooks @FRidh @jonringer
5999
60100# Haskell
61−/pkgs/development/compilers/ghc @peti @ryantm @basvandijk
62−/pkgs/development/haskell-modules @peti @ryantm @basvandijk
63−/pkgs/development/haskell-modules/default.nix @peti @ryantm @basvandijk
64−/pkgs/development/haskell-modules/generic-builder.nix @peti @ryantm @basvandijk
65−/pkgs/development/haskell-modules/hoogle.nix @peti @ryantm @basvandijk
101+/doc/languages-frameworks/haskell.section.md @cdepillabout @sternenseemann @maralorn @expipiplus1
102+/maintainers/scripts/haskell @cdepillabout @sternenseemann @maralorn @expipiplus1
103+/pkgs/development/compilers/ghc @cdepillabout @sternenseemann @maralorn @expipiplus1
104+/pkgs/development/haskell-modules @cdepillabout @sternenseemann @maralorn @expipiplus1
105+/pkgs/test/haskell @cdepillabout @sternenseemann @maralorn @expipiplus1
106+/pkgs/top-level/release-haskell.nix @cdepillabout @sternenseemann @maralorn @expipiplus1
107+/pkgs/top-level/haskell-packages.nix @cdepillabout @sternenseemann @maralorn @expipiplus1
108+
109+# Perl
110+/pkgs/development/interpreters/perl @stigtsp @zakame
111+/pkgs/top-level/perl-packages.nix @stigtsp @zakame
112+/pkgs/development/perl-modules @stigtsp @zakame
66113
67114# R
68−/pkgs/applications/science/math/R @peti
69−/pkgs/development/r-modules @peti
115+/pkgs/applications/science/math/R @jbedo
116+/pkgs/development/r-modules @jbedo
70117
71118# Ruby
72−/pkgs/development/interpreters/ruby @zimbatm
73−/pkgs/development/ruby-modules @zimbatm
119+/pkgs/development/interpreters/ruby @marsam
120+/pkgs/development/ruby-modules @marsam
74121
75122# Rust
76−/pkgs/development/compilers/rust @Mic92 @LnL7
77−
78−# Darwin-related
79−/pkgs/stdenv/darwin @NixOS/darwin-maintainers
80−/pkgs/os-specific/darwin @NixOS/darwin-maintainers
123+/pkgs/development/compilers/rust @Mic92 @LnL7 @zowoq
124+/pkgs/build-support/rust @zowoq
125+/doc/languages-frameworks/rust.section.md @zowoq
81126
82127# C compilers
83128/pkgs/development/compilers/gcc @matthewbauer
@@ -87,23 +132,20 @@
87132/pkgs/top-level/unix-tools.nix @matthewbauer
88133/pkgs/development/tools/xcbuild @matthewbauer
89134
90−# Beam-related (Erlang, Elixir, LFE, etc)
91−/pkgs/development/beam-modules @gleber
92−/pkgs/development/interpreters/erlang @gleber
93−/pkgs/development/interpreters/lfe @gleber
94−/pkgs/development/interpreters/elixir @gleber
95−/pkgs/development/tools/build-managers/rebar @gleber
96−/pkgs/development/tools/build-managers/rebar3 @gleber
97−/pkgs/development/tools/erlang @gleber
135+# Audio
136+/nixos/modules/services/audio/botamusique.nix @mweinelt
137+/nixos/modules/services/audio/snapserver.nix @mweinelt
138+/nixos/tests/modules/services/audio/botamusique.nix @mweinelt
139+/nixos/tests/snapcast.nix @mweinelt
140+
141+# Browsers
142+/pkgs/applications/networking/browsers/firefox @mweinelt
98143
99144# Jetbrains
100145/pkgs/applications/editors/jetbrains @edwtjo
101146
102−# Eclipse
103−/pkgs/applications/editors/eclipse @rycee
104−
105−# https://github.com/NixOS/nixpkgs/issues/31401
106−/lib/licenses.nix @ghost
147+# Licenses
148+/lib/licenses.nix @alyssais
107149
108150# Qt / KDE
109151/pkgs/applications/kde @ttuegel
@@ -112,17 +154,138 @@
112154/pkgs/development/libraries/qt-5 @ttuegel
113155
114156# PostgreSQL and related stuff
115−/pkgs/servers/sql/postgresql @thoughtpolice
157+/pkgs/servers/sql/postgresql @thoughtpolice @marsam
116158/nixos/modules/services/databases/postgresql.xml @thoughtpolice
117159/nixos/modules/services/databases/postgresql.nix @thoughtpolice
118160/nixos/tests/postgresql.nix @thoughtpolice
119161
162+# Hardened profile & related modules
163+/nixos/modules/profiles/hardened.nix @joachifm
164+/nixos/modules/security/hidepid.nix @joachifm
165+/nixos/modules/security/lock-kernel-modules.nix @joachifm
166+/nixos/modules/security/misc.nix @joachifm
167+/nixos/tests/hardened.nix @joachifm
168+/pkgs/os-specific/linux/kernel/hardened-config.nix @joachifm
169+
170+# Home Automation
171+/nixos/modules/services/misc/home-assistant.nix @mweinelt
172+/nixos/modules/services/misc/zigbee2mqtt.nix @mweinelt
173+/nixos/tests/home-assistant.nix @mweinelt
174+/nixos/tests/zigbee2mqtt.nix @mweinelt
175+/pkgs/servers/home-assistant @mweinelt
176+/pkgs/tools/misc/esphome @mweinelt
177+
178+# Network Time Daemons
179+/pkgs/tools/networking/chrony @thoughtpolice
180+/pkgs/tools/networking/ntp @thoughtpolice
181+/pkgs/tools/networking/openntpd @thoughtpolice
182+/nixos/modules/services/networking/ntp @thoughtpolice
183+
184+# Network
185+/pkgs/tools/networking/kea/default.nix @mweinelt
186+/pkgs/tools/networking/babeld/default.nix @mweinelt
187+/nixos/modules/services/networking/babeld.nix @mweinelt
188+/nixos/modules/services/networking/kea.nix @mweinelt
189+/nixos/modules/services/networking/knot.nix @mweinelt
190+/nixos/tests/babeld.nix @mweinelt
191+/nixos/tests/kea.nix @mweinelt
192+/nixos/tests/knot.nix @mweinelt
193+
120194# Dhall
121−/pkgs/development/dhall-modules @Gabriel439 @Profpatsch
122−/pkgs/development/interpreters/dhall @Gabriel439 @Profpatsch
195+/pkgs/development/dhall-modules @Gabriel439 @Profpatsch @ehmry
196+/pkgs/development/interpreters/dhall @Gabriel439 @Profpatsch @ehmry
123197
124198# Idris
125199/pkgs/development/idris-modules @Infinisil
126200
127201# Bazel
128−/pkgs/development/tools/build-managers/bazel @mboes @Profpatsch
202+/pkgs/development/tools/build-managers/bazel @Profpatsch
203+
204+# NixOS modules for e-mail and dns services
205+/nixos/modules/services/mail/mailman.nix @peti
206+/nixos/modules/services/mail/postfix.nix @peti
207+/nixos/modules/services/networking/bind.nix @peti
208+/nixos/modules/services/mail/rspamd.nix @peti
209+
210+# Emacs
211+/pkgs/applications/editors/emacs/elisp-packages @adisbladis
212+/pkgs/applications/editors/emacs @adisbladis
213+/pkgs/top-level/emacs-packages.nix @adisbladis
214+
215+# Neovim
216+/pkgs/applications/editors/neovim @jonringer @teto
217+
218+# VimPlugins
219+/pkgs/applications/editors/vim/plugins @jonringer
220+
221+# VsCode Extensions
222+/pkgs/applications/editors/vscode/extensions @jonringer
223+
224+# Prometheus exporter modules and tests
225+/nixos/modules/services/monitoring/prometheus/exporters.nix @WilliButz
226+/nixos/modules/services/monitoring/prometheus/exporters.xml @WilliButz
227+/nixos/tests/prometheus-exporters.nix @WilliButz
228+
229+# PHP interpreter, packages, extensions, tests and documentation
230+/doc/languages-frameworks/php.section.md @aanderse @etu @globin @ma27 @talyz
231+/nixos/tests/php @aanderse @etu @globin @ma27 @talyz
232+/pkgs/build-support/build-pecl.nix @aanderse @etu @globin @ma27 @talyz
233+/pkgs/development/interpreters/php @jtojnar @aanderse @etu @globin @ma27 @talyz
234+/pkgs/development/php-packages @aanderse @etu @globin @ma27 @talyz
235+/pkgs/top-level/php-packages.nix @jtojnar @aanderse @etu @globin @ma27 @talyz
236+
237+# Podman, CRI-O modules and related
238+/nixos/modules/virtualisation/containers.nix @zowoq @adisbladis
239+/nixos/modules/virtualisation/cri-o.nix @zowoq @adisbladis
240+/nixos/modules/virtualisation/podman @zowoq @adisbladis
241+/nixos/tests/cri-o.nix @zowoq @adisbladis
242+/nixos/tests/podman @zowoq @adisbladis
243+
244+# Docker tools
245+/pkgs/build-support/docker @roberth
246+/nixos/tests/docker-tools* @roberth
247+/doc/builders/images/dockertools.section.md @roberth
248+
249+# Blockchains
250+/pkgs/applications/blockchains @mmahut @RaghavSood
251+
252+# Go
253+/doc/languages-frameworks/go.section.md @kalbasit @Mic92 @zowoq
254+/pkgs/development/compilers/go @kalbasit @Mic92 @zowoq
255+/pkgs/development/go-modules @kalbasit @Mic92 @zowoq
256+/pkgs/development/go-packages @kalbasit @Mic92 @zowoq
257+
258+# GNOME
259+/pkgs/desktops/gnome @jtojnar @hedning
260+/pkgs/desktops/gnome/extensions @piegamesde @jtojnar @hedning
261+
262+# Cinnamon
263+/pkgs/desktops/cinnamon @mkg20001
264+
265+# nim
266+/pkgs/development/compilers/nim @ehmry
267+/pkgs/development/nim-packages @ehmry
268+/pkgs/top-level/nim-packages.nix @ehmry
269+
270+# terraform providers
271+/pkgs/applications/networking/cluster/terraform-providers @zowoq
272+
273+# kubernetes
274+/nixos/doc/manual/configuration/kubernetes.chapter.md @zowoq
275+/nixos/modules/services/cluster/kubernetes @zowoq
276+/nixos/tests/kubernetes @zowoq
277+/pkgs/applications/networking/cluster/kubernetes @zowoq
278+
279+# Matrix
280+/pkgs/servers/heisenbridge @piegamesde
281+/pkgs/servers/matrix-conduit @piegamesde
282+/pkgs/servers/matrix-synapse/matrix-appservice-irc @piegamesde
283+/nixos/modules/services/misc/heisenbridge.nix @piegamesde
284+/nixos/modules/services/misc/matrix-appservice-irc.nix @piegamesde
285+/nixos/modules/services/misc/matrix-conduit.nix @piegamesde
286+/nixos/tests/matrix-appservice-irc.nix @piegamesde
287+/nixos/tests/matrix-conduit.nix @piegamesde
288+
289+# Dotnet
290+/pkgs/build-support/dotnet @IvarWithoutBones
291+/pkgs/development/compilers/dotnet @IvarWithoutBones
.github/CONTRIBUTING.mddeleted−54
@@ -1,54 +0,0 @@
1−# How to contribute
2−
3−Note: contributing implies licensing those contributions
4−under the terms of [COPYING](../COPYING), which is an MIT-like license.
5−
6−## Opening issues
7−
8−* Make sure you have a [GitHub account](https://github.com/signup/free)
9−* [Submit an issue](https://github.com/NixOS/nixpkgs/issues) - assuming one does not already exist.
10− * Clearly describe the issue including steps to reproduce when it is a bug.
11− * Include information what version of nixpkgs and Nix are you using (nixos-version or git revision).
12−
13−## Submitting changes
14−
15−* Format the commit messages in the following way:
16−
17− ```
18− (pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
19−
20− (Motivation for change. Additional information.)
21− ```
22−
23− For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
24−
25− Examples:
26−
27− * nginx: init at 2.0.1
28− * firefox: 54.0.1 -> 55.0
29− * nixos/hydra: add bazBaz option
30−
31− Dual baz behavior is needed to do foo.
32− * nixos/nginx: refactor config generation
33−
34− The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
35−
36−* `meta.description` should:
37− * Be capitalized.
38− * Not start with the package name.
39− * Not have a period at the end.
40−* `meta.license` must be set and fit the upstream license.
41− * If there is no upstream license, `meta.license` should default to `stdenv.lib.licenses.unfree`.
42−* `meta.maintainers` must be set.
43−
44−See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
45−
46−## Writing good commit messages
47−
48−In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
49−
50−For package version upgrades and such a one-line commit message is usually sufficient.
51−
52−## Reviewing contributions
53−
54−See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#sec-reviewing-contributions).
.github/ISSUE_TEMPLATE.md+1−2
@@ -8,5 +8,4 @@
88
99## Technical details
1010
11−Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the
12−results.
11+Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
.github/ISSUE_TEMPLATE/bug_report.mdnew file+40
@@ -0,0 +1,40 @@
1+---
2+name: Bug report
3+about: Create a report to help us improve
4+title: ''
5+labels: '0.kind: bug'
6+assignees: ''
7+
8+---
9+
10+### Describe the bug
11+A clear and concise description of what the bug is.
12+
13+### Steps To Reproduce
14+Steps to reproduce the behavior:
15+1. ...
16+2. ...
17+3. ...
18+
19+### Expected behavior
20+A clear and concise description of what you expected to happen.
21+
22+### Screenshots
23+If applicable, add screenshots to help explain your problem.
24+
25+### Additional context
26+Add any other context about the problem here.
27+
28+### Notify maintainers
29+<!--
30+Please @ people who are in the `meta.maintainers` list of the offending package or module.
31+If in doubt, check `git blame` for whoever last touched something.
32+-->
33+
34+### Metadata
35+Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the result.
36+
37+```console
38+[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
39+output here
40+```
.github/ISSUE_TEMPLATE/out_of_date_package_report.mdnew file+48
@@ -0,0 +1,48 @@
1+---
2+name: Out-of-date package reports
3+about: For packages that are out-of-date
4+title: ''
5+labels: '9.needs: package (update)'
6+assignees: ''
7+
8+---
9+
10+
11+###### Checklist
12+
13+<!-- Note that these are hard requirements -->
14+
15+<!--
16+You can use the "Go to file" functionality on GitHub to find the package
17+Then you can go to the history for this package
18+Find the latest "package_name: old_version -> new_version" commit
19+The "new_version" is the current version of the package
20+-->
21+- [ ] Checked the [nixpkgs master branch](https://github.com/NixOS/nixpkgs)
22+<!--
23+Type the name of your package and try to find an open pull request for the package
24+If you find an open pull request, you can review it!
25+There's a high chance that you'll have the new version right away while helping the community!
26+-->
27+- [ ] Checked the [nixpkgs pull requests](https://github.com/NixOS/nixpkgs/pulls)
28+
29+###### Project name
30+`nix search` name:
31+<!--
32+The current version can be found easily with the same process as above for checking the master branch
33+If an open PR is present for the package, take this version as the current one and link to the PR
34+-->
35+current version:
36+desired version:
37+
38+###### Notify maintainers
39+<!--
40+Search your package here: https://search.nixos.org/packages?channel=unstable
41+If no maintainer is listed for your package, tag the person that last updated the package
42+-->
43+
44+maintainers:
45+
46+###### Note for maintainers
47+
48+Please tag this issue in your PR.
.github/ISSUE_TEMPLATE/packaging_request.mdnew file+18
@@ -0,0 +1,18 @@
1+---
2+name: Packaging requests
3+about: For packages that are missing
4+title: ''
5+labels: '0.kind: packaging request'
6+assignees: ''
7+
8+---
9+
10+**Project description**
11+_describe the project a little_
12+
13+**Metadata**
14+
15+* homepage URL:
16+* source URL:
17+* license: mit, bsd, gpl2+ , ...
18+* platforms: unix, linux, darwin, ...
.github/PULL_REQUEST_TEMPLATE.md+32−12
@@ -1,21 +1,41 @@
1−###### Motivation for this change
1+###### Description of changes
22
3+<!--
4+For package updates please link to a changelog or describe changes, this helps your fellow maintainers discover breaking updates.
5+For new packages please briefly describe the package or provide a link to its homepage.
6+-->
37
48###### Things done
59
610<!-- Please check what applies. Note that these are not hard requirements but merely serve as information for reviewers. -->
711
8−- [ ] Tested using sandboxing ([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS, or option `sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file) on non-NixOS)
912- Built on platform(s)
10− - [ ] NixOS
11− - [ ] macOS
12− - [ ] other Linux distributions
13−- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
14−- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
15−- [ ] Tested execution of all binary files (usually in `./result/bin/`)
16−- [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
17−- [ ] Assured whether relevant documentation is up to date
18−- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
13+ - [ ] x86_64-linux
14+ - [ ] aarch64-linux
15+ - [ ] x86_64-darwin
16+ - [ ] aarch64-darwin
17+- [ ] For non-Linux: Is `sandbox = true` set in `nix.conf`? (See [Nix manual](https://nixos.org/manual/nix/stable/command-ref/conf-file.html))
18+- [ ] Tested, as applicable:
19+ - [NixOS test(s)](https://nixos.org/manual/nixos/unstable/index.html#sec-nixos-tests) (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
20+ - and/or [package tests](https://nixos.org/manual/nixpkgs/unstable/#sec-package-tests)
21+ - or, for functions and "core" functionality, tests in [lib/tests](https://github.com/NixOS/nixpkgs/blob/master/lib/tests) or [pkgs/test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/test)
22+ - made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
23+- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
24+- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
25+- [22.05 Release Notes (or backporting 21.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2205-release-notes)
26+ - [ ] (Package updates) Added a release notes entry if the change is major or breaking
27+ - [ ] (Module updates) Added a release notes entry if the change is significant
28+ - [ ] (Module addition) Added a release notes entry if adding a new NixOS module
29+ - [ ] (Release notes changes) Ran `nixos/doc/manual/md-to-db.sh` to update generated release notes
30+- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
1931
20−---
32+<!--
33+To help with the large amounts of pull requests, we would appreciate your
34+reviews of other pull requests, especially simple package updates. Just leave a
35+comment describing what you have tested in the relevant package/service.
36+Reviewing helps to reduce the average time-to-merge for everyone.
37+Thanks a lot if you do!
2138
39+List of open PRs: https://github.com/NixOS/nixpkgs/pulls
40+Reviewing guidelines: https://nixos.org/manual/nixpkgs/unstable/#chap-reviewing-contributions
41+-->
.github/STALE-BOT.mdnew file+35
@@ -0,0 +1,35 @@
1+# Stale bot information
2+
3+- Thanks for your contribution!
4+- To remove the stale label, just leave a new comment.
5+- _How to find the right people to ping?_ → [`git blame`](https://git-scm.com/docs/git-blame) to the rescue! (or GitHub's history and blame buttons.)
6+- You can always ask for help on [our Discourse Forum](https://discourse.nixos.org/), [our Matrix room](https://matrix.to/#/#nix:nixos.org), or on the [#nixos IRC channel](https://web.libera.chat/#nixos).
7+
8+## Suggestions for PRs
9+
10+1. GitHub sometimes doesn't notify people who commented / reviewed a PR previously, when you (force) push commits. If you have addressed the reviews you can [officially ask for a review](https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) from those who commented to you or anyone else.
11+2. If it is unfinished but you plan to finish it, please mark it as a draft.
12+3. If you don't expect to work on it any time soon, closing it with a short comment may encourage someone else to pick up your work.
13+4. To get things rolling again, rebase the PR against the target branch and address valid comments.
14+5. If you need a review to move forward, ask in [the Discourse thread for PRs that need help](https://discourse.nixos.org/t/prs-in-distress/3604).
15+6. If all you need is a merge, check the git history to find and [request reviews](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/requesting-a-pull-request-review) from people who usually merge related contributions.
16+
17+## Suggestions for issues
18+
19+1. If it is resolved (either for you personally, or in general), please consider closing it.
20+2. If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough.
21+3. If you still have interest in resolving it, try to ping somebody who you believe might have an interest in the topic. Consider discussing the problem in [our Discourse Forum](https://discourse.nixos.org/).
22+4. As with all open source projects, your best option is to submit a Pull Request that addresses this issue. We :heart: this attitude!
23+
24+**Memorandum on closing issues**
25+
26+Don't be afraid to close an issue that holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen--nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.
27+
28+## Useful GitHub search queries
29+
30+- [Open PRs with any stale-bot interaction](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+)
31+- [Open PRs with any stale-bot interaction and `2.status: stale`](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+label%3A%222.status%3A+stale%22)
32+- [Open PRs with any stale-bot interaction and NOT `2.status: stale`](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+commenter%3Aapp%2Fstale+-label%3A%222.status%3A+stale%22+)
33+- [Open Issues with any stale-bot interaction](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+)
34+- [Open Issues with any stale-bot interaction and `2.status: stale`](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+label%3A%222.status%3A+stale%22+)
35+- [Open Issues with any stale-bot interaction and NOT `2.status: stale`](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+commenter%3Aapp%2Fstale+-label%3A%222.status%3A+stale%22+)
.github/labeler.ymlnew file+159
@@ -0,0 +1,159 @@
1+"6.topic: agda":
2+ - doc/languages-frameworks/agda.section.md
3+ - nixos/tests/agda.nix
4+ - pkgs/build-support/agda/**/*
5+ - pkgs/development/libraries/agda/**/*
6+ - pkgs/top-level/agda-packages.nix
7+
8+"6.topic: cinnamon":
9+ - pkgs/desktops/cinnamon/**/*
10+
11+"6.topic: emacs":
12+ - nixos/modules/services/editors/emacs.nix
13+ - nixos/modules/services/editors/emacs.xml
14+ - nixos/tests/emacs-daemon.nix
15+ - pkgs/applications/editors/emacs/elisp-packages/**/*
16+ - pkgs/applications/editors/emacs/**/*
17+ - pkgs/build-support/emacs/**/*
18+ - pkgs/top-level/emacs-packages.nix
19+
20+"6.topic: erlang":
21+ - doc/languages-frameworks/beam.section.md
22+ - pkgs/development/beam-modules/**/*
23+ - pkgs/development/interpreters/elixir/**/*
24+ - pkgs/development/interpreters/erlang/**/*
25+ - pkgs/development/tools/build-managers/rebar/**/*
26+ - pkgs/development/tools/build-managers/rebar3/**/*
27+ - pkgs/development/tools/erlang/**/*
28+ - pkgs/top-level/beam-packages.nix
29+
30+"6.topic: fetch":
31+ - pkgs/build-support/fetch*/**/*
32+
33+"6.topic: GNOME":
34+ - doc/languages-frameworks/gnome.section.md
35+ - nixos/modules/services/desktops/gnome/**/*
36+ - nixos/modules/services/x11/desktop-managers/gnome.nix
37+ - nixos/tests/gnome-xorg.nix
38+ - nixos/tests/gnome.nix
39+ - pkgs/desktops/gnome/**/*
40+
41+"6.topic: golang":
42+ - doc/languages-frameworks/go.section.md
43+ - pkgs/development/compilers/go/**/*
44+ - pkgs/development/go-modules/**/*
45+ - pkgs/development/go-packages/**/*
46+
47+"6.topic: haskell":
48+ - doc/languages-frameworks/haskell.section.md
49+ - maintainers/scripts/haskell/**/*
50+ - pkgs/development/compilers/ghc/**/*
51+ - pkgs/development/haskell-modules/**/*
52+ - pkgs/development/tools/haskell/**/*
53+ - pkgs/test/haskell/**/*
54+ - pkgs/top-level/haskell-packages.nix
55+ - pkgs/top-level/release-haskell.nix
56+
57+"6.topic: kernel":
58+ - pkgs/build-support/kernel/**/*
59+ - pkgs/os-specific/linux/kernel/**/*
60+
61+"6.topic: lua":
62+ - pkgs/development/interpreters/lua-5/**/*
63+ - pkgs/development/interpreters/luajit/**/*
64+ - pkgs/development/lua-modules/**/*
65+ - pkgs/top-level/lua-packages.nix
66+
67+"6.topic: nixos":
68+ - nixos/**/*
69+ - pkgs/os-specific/linux/nixos-rebuild/**/*
70+
71+"6.topic: nim":
72+ - doc/languages-frameworks/nim.section.md
73+ - pkgs/development/compilers/nim/*
74+ - pkgs/development/nim-packages/**/*
75+ - pkgs/top-level/nim-packages.nix
76+
77+"6.topic: ocaml":
78+ - doc/languages-frameworks/ocaml.section.md
79+ - pkgs/development/compilers/ocaml/**/*
80+ - pkgs/development/compilers/reason/**/*
81+ - pkgs/development/ocaml-modules/**/*
82+ - pkgs/development/tools/ocaml/**/*
83+ - pkgs/top-level/ocaml-packages.nix
84+
85+"6.topic: pantheon":
86+ - nixos/modules/services/desktops/pantheon/**/*
87+ - nixos/modules/services/x11/desktop-managers/pantheon.nix
88+ - nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix
89+ - nixos/tests/pantheon.nix
90+ - pkgs/desktops/pantheon/**/*
91+
92+"6.topic: policy discussion":
93+ - .github/**/*
94+
95+"6.topic: printing":
96+ - nixos/modules/services/printing/cupsd.nix
97+ - pkgs/misc/cups/**/*
98+
99+"6.topic: python":
100+ - doc/languages-frameworks/python.section.md
101+ - pkgs/development/interpreters/python/**/*
102+ - pkgs/development/python-modules/**/*
103+ - pkgs/top-level/python-packages.nix
104+
105+"6.topic: qt/kde":
106+ - doc/languages-frameworks/qt.section.md
107+ - nixos/modules/services/x11/desktop-managers/plasma5.nix
108+ - nixos/tests/plasma5.nix
109+ - pkgs/applications/kde/**/*
110+ - pkgs/desktops/plasma-5/**/*
111+ - pkgs/development/libraries/kde-frameworks/**/*
112+ - pkgs/development/libraries/qt-5/**/*
113+
114+"6.topic: ruby":
115+ - doc/languages-frameworks/ruby.section.md
116+ - pkgs/development/interpreters/ruby/**/*
117+ - pkgs/development/ruby-modules/**/*
118+
119+"6.topic: rust":
120+ - doc/languages-frameworks/rust.section.md
121+ - pkgs/build-support/rust/**/*
122+ - pkgs/development/compilers/rust/**/*
123+
124+"6.topic: stdenv":
125+ - pkgs/stdenv/**/*
126+
127+"6.topic: steam":
128+ - pkgs/games/steam/**/*
129+
130+"6.topic: systemd":
131+ - pkgs/os-specific/linux/systemd/**/*
132+ - nixos/modules/system/boot/systemd*/**/*
133+
134+"6.topic: TeX":
135+ - doc/languages-frameworks/texlive.section.md
136+ - pkgs/tools/typesetting/tex/**/*
137+
138+"6.topic: vim":
139+ - doc/languages-frameworks/vim.section.md
140+ - pkgs/applications/editors/vim/**/*
141+ - pkgs/applications/editors/vim/plugins/**/*
142+ - nixos/modules/programs/neovim.nix
143+ - pkgs/applications/editors/neovim/**/*
144+
145+"6.topic: xfce":
146+ - nixos/doc/manual/configuration/xfce.xml
147+ - nixos/modules/services/x11/desktop-managers/xfce.nix
148+ - nixos/tests/xfce.nix
149+ - pkgs/desktops/xfce/**/*
150+
151+"8.has: changelog":
152+ - nixos/doc/manual/release-notes/**/*
153+
154+"8.has: documentation":
155+ - doc/**/*
156+ - nixos/doc/**/*
157+
158+"8.has: module (update)":
159+ - nixos/modules/**/*
.github/stale.ymlnew file+10
@@ -0,0 +1,10 @@
1+# Configuration for probot-stale - https://github.com/probot/stale
2+daysUntilStale: 180
3+daysUntilClose: false
4+exemptLabels:
5+ - "1.severity: security"
6+ - "2.status: never-stale"
7+staleLabel: "2.status: stale"
8+markComment: |
9+ I marked this as stale due to inactivity. → [More info](https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md)
10+closeComment: false
.github/workflows/backport.ymlnew file+35
@@ -0,0 +1,35 @@
1+name: Backport
2+on:
3+ pull_request_target:
4+ types: [closed, labeled]
5+
6+# WARNING:
7+# When extending this action, be aware that $GITHUB_TOKEN allows write access to
8+# the GitHub repository. This means that it should not evaluate user input in a
9+# way that allows code injection.
10+
11+jobs:
12+ backport:
13+ name: Backport Pull Request
14+ if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
15+ runs-on: ubuntu-latest
16+ steps:
17+ - uses: actions/checkout@v3
18+ with:
19+ # required to find all branches
20+ fetch-depth: 0
21+ ref: ${{ github.event.pull_request.head.sha }}
22+ - name: Create backport PRs
23+ # should be kept in sync with `version`
24+ uses: zeebe-io/backport-action@v0.0.5
25+ with:
26+ # Config README: https://github.com/zeebe-io/backport-action#backport-action
27+ github_token: ${{ secrets.GITHUB_TOKEN }}
28+ github_workspace: ${{ github.workspace }}
29+ # should be kept in sync with `uses`
30+ version: v0.0.5
31+ pull_description: |-
32+ Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
33+
34+ * [ ] Before merging, ensure that this backport complies with the [Criteria for Backporting](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#criteria-for-backporting-changes).
35+ * Even as a non-commiter, if you find that it does not comply, leave a comment.
.github/workflows/basic-eval.ymlnew file+26
@@ -0,0 +1,26 @@
1+name: Basic evaluation checks
2+
3+on:
4+ workflow_dispatch
5+ # pull_request:
6+ # branches:
7+ # - master
8+ # - release-**
9+ # push:
10+ # branches:
11+ # - master
12+ # - release-**
13+jobs:
14+ tests:
15+ runs-on: ubuntu-latest
16+ # we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
17+ steps:
18+ - uses: actions/checkout@v3
19+ - uses: cachix/install-nix-action@v17
20+ - uses: cachix/cachix-action@v10
21+ with:
22+ # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
23+ name: nixpkgs-ci
24+ signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
25+ # explicit list of supportedSystems is needed until aarch64-darwin becomes part of the trunk jobset
26+ - run: nix-build pkgs/top-level/release.nix -A tarball.nixpkgs-basic-release-checks --arg supportedSystems '[ "aarch64-darwin" "aarch64-linux" "x86_64-linux" "x86_64-darwin" ]'
.github/workflows/direct-push.ymlnew file+32
@@ -0,0 +1,32 @@
1+name: "Direct Push Warning"
2+on:
3+ push:
4+ branches:
5+ - master
6+ - release-**
7+jobs:
8+ build:
9+ runs-on: ubuntu-latest
10+ if: github.repository_owner == 'NixOS'
11+ env:
12+ GITHUB_SHA: ${{ github.sha }}
13+ GITHUB_REPOSITORY: ${{ github.repository }}
14+ steps:
15+ - name: Check if commit is a merge commit
16+ id: ismerge
17+ run: |
18+ ISMERGE=$(curl -H 'Accept: application/vnd.github.groot-preview+json' -H "authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }}/commits/${{ env.GITHUB_SHA }}/pulls | jq -r '.[] | select(.merge_commit_sha == "${{ env.GITHUB_SHA }}") | any')
19+ echo "::set-output name=ismerge::$ISMERGE"
20+ # github events are eventually consistent, so wait until changes propagate to thier DB
21+ - run: sleep 60
22+ if: steps.ismerge.outputs.ismerge != 'true'
23+ - name: Warn if the commit was a direct push
24+ if: steps.ismerge.outputs.ismerge != 'true'
25+ uses: peter-evans/commit-comment@v2
26+ with:
27+ body: |
28+ @${{ github.actor }}, you pushed a commit directly to master/release branch
29+ instead of going through a Pull Request.
30+
31+ That's highly discouraged beyond the few exceptions listed
32+ on https://github.com/NixOS/nixpkgs/issues/118661
.github/workflows/editorconfig.ymlnew file+43
@@ -0,0 +1,43 @@
1+name: "Checking EditorConfig"
2+
3+permissions: read-all
4+
5+on:
6+ # avoids approving first time contributors
7+ pull_request_target:
8+ branches-ignore:
9+ - 'release-**'
10+
11+jobs:
12+ tests:
13+ runs-on: ubuntu-latest
14+ if: "github.repository_owner == 'NixOS' && !contains(github.event.pull_request.title, '[skip editorconfig]')"
15+ steps:
16+ - name: Get list of changed files from PR
17+ env:
18+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
19+ run: |
20+ gh api \
21+ repos/NixOS/nixpkgs/pulls/${{github.event.number}}/files --paginate \
22+ | jq '.[] | select(.status != "removed") | .filename' \
23+ > "$HOME/changed_files"
24+ - name: print list of changed files
25+ run: |
26+ cat "$HOME/changed_files"
27+ - uses: actions/checkout@v3
28+ with:
29+ # pull_request_target checks out the base branch by default
30+ ref: refs/pull/${{ github.event.pull_request.number }}/merge
31+ - uses: cachix/install-nix-action@v17
32+ with:
33+ # nixpkgs commit is pinned so that it doesn't break
34+ # editorconfig-checker 2.4.0
35+ nix_path: nixpkgs=https://github.com/NixOS/nixpkgs/archive/c473cc8714710179df205b153f4e9fa007107ff9.tar.gz
36+ - name: install editorconfig-checker
37+ run: nix-env -iA editorconfig-checker -f '<nixpkgs>'
38+ - name: Checking EditorConfig
39+ run: |
40+ cat "$HOME/changed_files" | xargs -r editorconfig-checker -disable-indent-size
41+ - if: ${{ failure() }}
42+ run: |
43+ echo "::error :: Hey! It looks like your changes don't follow our editorconfig settings. Read https://editorconfig.org/#download to configure your editor so you never see this error again."
.github/workflows/labels.ymlnew file+24
@@ -0,0 +1,24 @@
1+name: "Label PR"
2+
3+on:
4+ pull_request_target:
5+ types: [edited, opened, synchronize, reopened]
6+
7+# WARNING:
8+# When extending this action, be aware that $GITHUB_TOKEN allows some write
9+# access to the GitHub API. This means that it should not evaluate user input in
10+# a way that allows code injection.
11+
12+permissions:
13+ contents: read
14+ pull-requests: write
15+
16+jobs:
17+ labels:
18+ runs-on: ubuntu-latest
19+ if: github.repository_owner == 'NixOS'
20+ steps:
21+ - uses: actions/labeler@v4
22+ with:
23+ repo-token: ${{ secrets.GITHUB_TOKEN }}
24+ sync-labels: true
.github/workflows/manual-nixos.ymlnew file+31
@@ -0,0 +1,31 @@
1+name: "Build NixOS manual"
2+
3+permissions: read-all
4+
5+on:
6+ pull_request_target:
7+ branches:
8+ - master
9+ paths:
10+ - 'nixos/**'
11+
12+jobs:
13+ nixos:
14+ runs-on: ubuntu-latest
15+ if: github.repository_owner == 'NixOS'
16+ steps:
17+ - uses: actions/checkout@v3
18+ with:
19+ # pull_request_target checks out the base branch by default
20+ ref: refs/pull/${{ github.event.pull_request.number }}/merge
21+ - uses: cachix/install-nix-action@v17
22+ with:
23+ # explicitly enable sandbox
24+ extra_nix_config: sandbox = true
25+ - uses: cachix/cachix-action@v10
26+ with:
27+ # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
28+ name: nixpkgs-ci
29+ signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
30+ - name: Building NixOS manual
31+ run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true nixos/release.nix -A manual.x86_64-linux
.github/workflows/manual-nixpkgs.ymlnew file+31
@@ -0,0 +1,31 @@
1+name: "Build Nixpkgs manual"
2+
3+permissions: read-all
4+
5+on:
6+ pull_request_target:
7+ branches:
8+ - master
9+ paths:
10+ - 'doc/**'
11+
12+jobs:
13+ nixpkgs:
14+ runs-on: ubuntu-latest
15+ if: github.repository_owner == 'NixOS'
16+ steps:
17+ - uses: actions/checkout@v3
18+ with:
19+ # pull_request_target checks out the base branch by default
20+ ref: refs/pull/${{ github.event.pull_request.number }}/merge
21+ - uses: cachix/install-nix-action@v17
22+ with:
23+ # explicitly enable sandbox
24+ extra_nix_config: sandbox = true
25+ - uses: cachix/cachix-action@v10
26+ with:
27+ # This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
28+ name: nixpkgs-ci
29+ signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
30+ - name: Building Nixpkgs manual
31+ run: NIX_PATH=nixpkgs=$(pwd) nix-build --option restrict-eval true pkgs/top-level/release.nix -A manual
.github/workflows/nixos-manual.ymlnew file+26
@@ -0,0 +1,26 @@
1+name: NixOS manual checks
2+
3+permissions: read-all
4+
5+on:
6+ pull_request_target:
7+ branches-ignore:
8+ - 'release-**'
9+ paths:
10+ - 'nixos/**/*.xml'
11+ - 'nixos/**/*.md'
12+
13+jobs:
14+ tests:
15+ runs-on: ubuntu-latest
16+ if: github.repository_owner == 'NixOS'
17+ steps:
18+ - uses: actions/checkout@v3
19+ with:
20+ # pull_request_target checks out the base branch by default
21+ ref: refs/pull/${{ github.event.pull_request.number }}/merge
22+ - uses: cachix/install-nix-action@v17
23+ - name: Check DocBook files generated from Markdown are consistent
24+ run: |
25+ nixos/doc/manual/md-to-db.sh
26+ git diff --exit-code
.github/workflows/no-channel.ymlnew file+21
@@ -0,0 +1,21 @@
1+name: "No channel PR"
2+
3+on:
4+ pull_request:
5+ branches:
6+ - 'nixos-**'
7+ - 'nixpkgs-**'
8+
9+jobs:
10+ fail:
11+ name: "This PR is is targeting a channel branch"
12+ runs-on: ubuntu-latest
13+ steps:
14+ - run: |
15+ cat <<EOF
16+ The nixos-* and nixpkgs-* branches are pushed to by the channel
17+ release script and should not be merged into directly.
18+
19+ Please target the equivalent release-* branch or master instead.
20+ EOF
21+ exit 1
.github/workflows/pending-clear.ymlnew file+21
@@ -0,0 +1,21 @@
1+name: "clear pending status"
2+
3+on:
4+ check_suite:
5+ types: [ completed ]
6+
7+jobs:
8+ action:
9+ runs-on: ubuntu-latest
10+ steps:
11+ - name: clear pending status
12+ if: github.repository_owner == 'NixOS' && github.event.check_suite.app.name == 'OfBorg'
13+ env:
14+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
15+ run: |
16+ curl \
17+ -X POST \
18+ -H "Accept: application/vnd.github.v3+json" \
19+ -H "Authorization: token $GITHUB_TOKEN" \
20+ -d '{"state": "success", "target_url": " ", "description": " ", "context": "Wait for ofborg"}' \
21+ "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.check_suite.head_sha }}"
.github/workflows/pending-set.ymlnew file+25
@@ -0,0 +1,25 @@
1+name: "set pending status"
2+
3+on:
4+ pull_request_target:
5+
6+# WARNING:
7+# When extending this action, be aware that $GITHUB_TOKEN allows write access to
8+# the GitHub repository. This means that it should not evaluate user input in a
9+# way that allows code injection.
10+
11+jobs:
12+ action:
13+ runs-on: ubuntu-latest
14+ steps:
15+ - name: set pending status
16+ if: github.repository_owner == 'NixOS'
17+ env:
18+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
19+ run: |
20+ curl \
21+ -X POST \
22+ -H "Accept: application/vnd.github.v3+json" \
23+ -H "Authorization: token $GITHUB_TOKEN" \
24+ -d '{"state": "pending", "target_url": " ", "description": "This pending status will be cleared when ofborg starts eval.", "context": "Wait for ofborg"}' \
25+ "https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.pull_request.head.sha }}"
.github/workflows/periodic-merge-24h.ymlnew file+57
@@ -0,0 +1,57 @@
1+# This action periodically merges base branches into staging branches.
2+# This is done to
3+# * prevent conflicts or rather resolve them early
4+# * make all potential breakage happen on the staging branch
5+# * and make sure that all major rebuilds happen before the staging
6+# branch get’s merged back into its base branch.
7+
8+name: "Periodic Merges (24h)"
9+
10+
11+on:
12+ schedule:
13+ # * is a special character in YAML so you have to quote this string
14+ # Merge every 24 hours
15+ - cron: '0 0 * * *'
16+
17+jobs:
18+ periodic-merge:
19+ if: github.repository_owner == 'NixOS'
20+ runs-on: ubuntu-latest
21+ strategy:
22+ # don't fail fast, so that all pairs are tried
23+ fail-fast: false
24+ # certain branches need to be merged in order, like master->staging-next->staging
25+ # and disabling parallelism ensures the order of the pairs below.
26+ max-parallel: 1
27+ matrix:
28+ pairs:
29+ - from: master
30+ into: haskell-updates
31+ - from: release-21.05
32+ into: staging-next-21.05
33+ - from: staging-next-21.05
34+ into: staging-21.05
35+ - from: release-21.11
36+ into: staging-next-21.11
37+ - from: staging-next-21.11
38+ into: staging-21.11
39+ name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
40+ steps:
41+ - uses: actions/checkout@v3
42+
43+ - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
44+ uses: devmasx/merge-branch@1.4.0
45+ with:
46+ type: now
47+ from_branch: ${{ matrix.pairs.from }}
48+ target_branch: ${{ matrix.pairs.into }}
49+ github_token: ${{ secrets.GITHUB_TOKEN }}
50+
51+ - name: Comment on failure
52+ uses: peter-evans/create-or-update-comment@v2
53+ if: ${{ failure() }}
54+ with:
55+ issue-number: 105153
56+ body: |
57+ Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).
.github/workflows/periodic-merge-6h.ymlnew file+51
@@ -0,0 +1,51 @@
1+# This action periodically merges base branches into staging branches.
2+# This is done to
3+# * prevent conflicts or rather resolve them early
4+# * make all potential breakage happen on the staging branch
5+# * and make sure that all major rebuilds happen before the staging
6+# branch get’s merged back into its base branch.
7+
8+name: "Periodic Merges (6h)"
9+
10+
11+on:
12+ schedule:
13+ # * is a special character in YAML so you have to quote this string
14+ # Merge every 6 hours
15+ - cron: '0 */6 * * *'
16+
17+jobs:
18+ periodic-merge:
19+ if: github.repository_owner == 'NixOS'
20+ runs-on: ubuntu-latest
21+ strategy:
22+ # don't fail fast, so that all pairs are tried
23+ fail-fast: false
24+ # certain branches need to be merged in order, like master->staging-next->staging
25+ # and disabling parallelism ensures the order of the pairs below.
26+ max-parallel: 1
27+ matrix:
28+ pairs:
29+ - from: master
30+ into: staging-next
31+ - from: staging-next
32+ into: staging
33+ name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
34+ steps:
35+ - uses: actions/checkout@v3
36+
37+ - name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
38+ uses: devmasx/merge-branch@1.4.0
39+ with:
40+ type: now
41+ from_branch: ${{ matrix.pairs.from }}
42+ target_branch: ${{ matrix.pairs.into }}
43+ github_token: ${{ secrets.GITHUB_TOKEN }}
44+
45+ - name: Comment on failure
46+ uses: peter-evans/create-or-update-comment@v2
47+ if: ${{ failure() }}
48+ with:
49+ issue-number: 105153
50+ body: |
51+ Periodic merge from `${{ matrix.pairs.from }}` into `${{ matrix.pairs.into }}` has [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).
.github/workflows/update-terraform-providers.ymlnew file+48
@@ -0,0 +1,48 @@
1+name: "Update terraform-providers"
2+
3+on:
4+ schedule:
5+ - cron: "14 3 * * 1"
6+ workflow_dispatch:
7+
8+jobs:
9+ tf-providers:
10+ if: github.repository_owner == 'NixOS' && github.ref == 'refs/heads/master' # ensure workflow_dispatch only runs on master
11+ runs-on: ubuntu-latest
12+ steps:
13+ - uses: actions/checkout@v3
14+ - uses: cachix/install-nix-action@v17
15+ - name: setup
16+ id: setup
17+ run: |
18+ echo ::set-output name=title::"terraform-providers: update $(date -u +"%Y-%m-%d")"
19+ - name: update terraform-providers
20+ run: |
21+ git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
22+ git config user.name "github-actions[bot]"
23+ pushd pkgs/applications/networking/cluster/terraform-providers
24+ ./update-all-providers --no-build
25+ git commit -m "${{ steps.setup.outputs.title }}" providers.json
26+ popd
27+ - name: create PR
28+ uses: peter-evans/create-pull-request@v4
29+ with:
30+ body: |
31+ Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
32+
33+ Check that all providers build with:
34+ ```
35+ @ofborg build terraform-full
36+ ```
37+ branch: terraform-providers-update
38+ delete-branch: false
39+ labels: "2.status: work-in-progress"
40+ title: ${{ steps.setup.outputs.title }}
41+ token: ${{ secrets.GITHUB_TOKEN }}
42+ - name: comment on failure
43+ uses: peter-evans/create-or-update-comment@v2
44+ if: ${{ failure() }}
45+ with:
46+ issue-number: 153416
47+ body: |
48+ Automatic update of terraform providers [failed](https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}).
.gitignore+14−1
@@ -2,8 +2,12 @@
22,*
33.*.swp
44.*.swo
5+.idea/
6+.vscode/
7+outputs/
58result
69result-*
10+source/
711/doc/NEWS.html
812/doc/NEWS.txt
913/doc/manual.html
@@ -11,6 +15,15 @@ result-*
1115.version-suffix
1216
1317.DS_Store
18+.mypy_cache
19+__pycache__
1420
1521/pkgs/development/libraries/qt-5/*/tmp/
16−/pkgs/desktops/kde-5/*/tmp/
22+/pkgs/desktops/kde-5/*/tmp/
23+/pkgs/development/mobile/androidenv/xml/*
24+
25+# generated by pkgs/common-updater/update-script.nix
26+update-git-commits.txt
27+
28+# JetBrains IDEA module declaration file
29+/nixpkgs.iml
.version+1−1
@@ -1 +1 @@
1−19.03
1+22.05
CONTRIBUTING.mdnew file+130
@@ -0,0 +1,130 @@
1+# How to contribute
2+
3+Note: contributing implies licensing those contributions
4+under the terms of [COPYING](COPYING), which is an MIT-like license.
5+
6+## Opening issues
7+
8+* Make sure you have a [GitHub account](https://github.com/signup/free)
9+* Make sure there is no open issue on the topic
10+* [Submit a new issue](https://github.com/NixOS/nixpkgs/issues/new/choose) by choosing the kind of topic and fill out the template
11+
12+## Submitting changes
13+
14+Read the ["Submitting changes"](https://nixos.org/nixpkgs/manual/#chap-submitting-changes) section of the nixpkgs manual. It explains how to write, test, and iterate on your change, and which branch to base your pull request against.
15+
16+Below is a short excerpt of some points in there:
17+
18+* Format the commit messages in the following way:
19+
20+ ```
21+ (pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
22+
23+ (Motivation for change. Link to release notes. Additional information.)
24+ ```
25+
26+ For consistency, there should not be a period at the end of the commit message's summary line (the first line of the commit message).
27+
28+ Examples:
29+
30+ * nginx: init at 2.0.1
31+ * firefox: 54.0.1 -> 55.0
32+ https://www.mozilla.org/en-US/firefox/55.0/releasenotes/
33+ * nixos/hydra: add bazBaz option
34+
35+ Dual baz behavior is needed to do foo.
36+ * nixos/nginx: refactor config generation
37+
38+ The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
39+
40+* `meta.description` should:
41+ * Be capitalized.
42+ * Not start with the package name.
43+ * Not have a period at the end.
44+* `meta.license` must be set and fit the upstream license.
45+ * If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
46+* `meta.maintainers` must be set.
47+
48+See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes).
49+
50+## Writing good commit messages
51+
52+In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
53+
54+For package version upgrades and such a one-line commit message is usually sufficient.
55+
56+## Rebasing between branches (i.e. from master to staging)
57+
58+From time to time, changes between branches must be rebased, for example, if the
59+number of new rebuilds they would cause is too large for the target branch. When
60+rebasing, care must be taken to include only the intended changes, otherwise
61+many CODEOWNERS will be inadvertently requested for review. To achieve this,
62+rebasing should not be performed directly on the target branch, but on the merge
63+base between the current and target branch.
64+
65+In the following example, we see a rebase from `master` onto the merge base
66+between `master` and `staging`, so that a change can eventually be retargeted to
67+`staging`. The example uses `upstream` as the remote for `NixOS/nixpkgs.git`
68+while the `origin` remote is used for the remote you are pushing to.
69+
70+
71+```console
72+# Find the common base between two branches
73+common=$(git merge-base upstream/master upstream/staging)
74+# Find the common base between your feature branch and master
75+commits=$(git merge-base $(git branch --show-current) upstream/master)
76+# Rebase all commits onto the common base
77+git rebase --onto=$common $commits
78+# Force push your changes
79+git push origin $(git branch --show-current) --force-with-lease
80+```
81+
82+Then change the base branch in the GitHub PR using the *Edit* button in the upper
83+right corner, and switch from `master` to `staging`. After the PR has been
84+retargeted it might be necessary to do a final rebase onto the target branch, to
85+resolve any outstanding merge conflicts.
86+
87+```console
88+# Rebase onto target branch
89+git rebase upstream/staging
90+# Review and fixup possible conflicts
91+git status
92+# Force push your changes
93+git push origin $(git branch --show-current) --force-with-lease
94+```
95+
96+## Backporting changes
97+
98+Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
99+
100+1. Take note of the commits in which the change was introduced into `master` branch.
101+2. Check out the target _release branch_, e.g. `release-21.11`. Do not use a _channel branch_ like `nixos-21.11` or `nixpkgs-21.11-darwin`.
102+3. Create a branch for your change, e.g. `git checkout -b backport`.
103+4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
104+5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-21.11`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[21.11]`.
105+6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
106+
107+## Criteria for Backporting changes
108+
109+Anything that does not cause user or downstream dependency regressions can be backported. This includes:
110+- New Packages / Modules
111+- Security / Patch updates
112+- Version updates which include new functionality (but no breaking changes)
113+- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
114+- Security critical applications (E.g. `firefox`)
115+
116+## Generating 22.05 Release Notes
117+
118+(This section also applies to backporting 21.11 release notes: substitute "rl-2205" for "rl-2111".)
119+
120+Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
121+
122+Steps for updating 22.05 Release notes:
123+
124+1. Edit `nixos/doc/manual/release-notes/rl-2205.section.md` with the desired changes
125+2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2205.section.xml`
126+3. Include changes to `rl-2205.section.md` and `rl-2205.section.xml` in the same commit.
127+
128+## Reviewing contributions
129+
130+See the nixpkgs manual for more details on how to [Review contributions](https://nixos.org/nixpkgs/manual/#chap-reviewing-contributions).
COPYING+1−1
@@ -1,4 +1,4 @@
1−Copyright (c) 2003-2018 Eelco Dolstra and the Nixpkgs/NixOS contributors
1+Copyright (c) 2003-2022 Eelco Dolstra and the Nixpkgs/NixOS contributors
22
33Permission is hereby granted, free of charge, to any person obtaining
44a copy of this software and associated documentation files (the
README.md+106−34
@@ -1,47 +1,119 @@
1−[<img src="https://nixos.org/logo/nixos-hires.png" width="500px" alt="logo" />](https://nixos.org/nixos)
1+<p align="center">
2+ <a href="https://nixos.org#gh-light-mode-only">
3+ <img src="https://raw.githubusercontent.com/NixOS/nixos-homepage/master/logo/nixos-hires.png" width="500px" alt="NixOS logo"/>
4+ </a>
5+ <a href="https://nixos.org#gh-dark-mode-only">
6+ <img src="https://raw.githubusercontent.com/NixOS/nixos-artwork/master/logo/nixos-white.png" width="500px" alt="NixOS logo"/>
7+ </a>
8+</p>
29
3−[](https://www.codetriage.com/nixos/nixpkgs)
10+<p align="center">
11+ <a href="https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md"><img src="https://img.shields.io/github/contributors-anon/NixOS/nixpkgs" alt="Contributors badge" /></a>
12+ <a href="https://opencollective.com/nixos"><img src="https://opencollective.com/nixos/tiers/supporter/badge.svg?label=supporters&color=brightgreen" alt="Open Collective supporters" /></a>
13+</p>
414
5−Nixpkgs is a collection of packages for the [Nix](https://nixos.org/nix/) package
6−manager. It is periodically built and tested by the [Hydra](https://hydra.nixos.org/)
7−build daemon as so-called channels. To get channel information via git, add
8−[nixpkgs-channels](https://github.com/NixOS/nixpkgs-channels.git) as a remote:
15+[Nixpkgs](https://github.com/nixos/nixpkgs) is a collection of over
16+80,000 software packages that can be installed with the
17+[Nix](https://nixos.org/nix/) package manager. It also implements
18+[NixOS](https://nixos.org/nixos/), a purely-functional Linux distribution.
919
10−```
11−% git remote add channels https://github.com/NixOS/nixpkgs-channels.git
12−```
20+# Manuals
1321
14−For stability and maximum binary package support, it is recommended to maintain
15−custom changes on top of one of the channels, e.g. `nixos-18.09` for the latest
16−release and `nixos-unstable` for the latest successful build of master:
22+* [NixOS Manual](https://nixos.org/nixos/manual) - how to install, configure, and maintain a purely-functional Linux distribution
23+* [Nixpkgs Manual](https://nixos.org/nixpkgs/manual/) - contributing to Nixpkgs and using programming-language-specific Nix expressions
24+* [Nix Package Manager Manual](https://nixos.org/nix/manual) - how to write Nix expressions (programs), and how to use Nix command line tools
1725
18−```
19−% git remote update channels
20−% git rebase channels/nixos-18.09
21−```
26+# Community
2227
23−For pull requests, please rebase onto nixpkgs `master`.
28+* [Discourse Forum](https://discourse.nixos.org/)
29+* [Matrix Chat](https://matrix.to/#/#community:nixos.org)
30+* [NixOS Weekly](https://weekly.nixos.org/)
31+* [Community-maintained wiki](https://nixos.wiki/)
32+* [Community-maintained list of ways to get in touch](https://nixos.wiki/wiki/Get_In_Touch#Chat) (Discord, Telegram, IRC, etc.)
33+
34+# Other Project Repositories
35+
36+The sources of all official Nix-related projects are in the [NixOS
37+organization on GitHub](https://github.com/NixOS/). Here are some of
38+the main ones:
39+
40+* [Nix](https://github.com/NixOS/nix) - the purely functional package manager
41+* [NixOps](https://github.com/NixOS/nixops) - the tool to remotely deploy NixOS machines
42+* [nixos-hardware](https://github.com/NixOS/nixos-hardware) - NixOS profiles to optimize settings for different hardware
43+* [Nix RFCs](https://github.com/NixOS/rfcs) - the formal process for making substantial changes to the community
44+* [NixOS homepage](https://github.com/NixOS/nixos-homepage) - the [NixOS.org](https://nixos.org) website
45+* [hydra](https://github.com/NixOS/hydra) - our continuous integration system
46+* [NixOS Artwork](https://github.com/NixOS/nixos-artwork) - NixOS artwork
47+
48+# Continuous Integration and Distribution
2449
25−[NixOS](https://nixos.org/nixos/) Linux distribution source code is located inside
26−`nixos/` folder.
50+Nixpkgs and NixOS are built and tested by our continuous integration
51+system, [Hydra](https://hydra.nixos.org/).
2752
28−* [NixOS installation instructions](https://nixos.org/nixos/manual/#ch-installation)
29−* [Documentation (Nix Expression Language chapter)](https://nixos.org/nix/manual/#ch-expression-language)
30−* [Manual (How to write packages for Nix)](https://nixos.org/nixpkgs/manual/)
31−* [Manual (NixOS)](https://nixos.org/nixos/manual/)
32−* [Community maintained wiki](https://nixos.wiki/)
3353* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
34−* [Continuous package builds for 18.09 release](https://hydra.nixos.org/jobset/nixos/release-18.09)
54+* [Continuous package builds for the NixOS 21.11 release](https://hydra.nixos.org/jobset/nixos/release-21.11)
3555* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
36−* [Tests for 18.09 release](https://hydra.nixos.org/job/nixos/release-18.09/tested#tabs-constituents)
56+* [Tests for the NixOS 21.11 release](https://hydra.nixos.org/job/nixos/release-21.11/tested#tabs-constituents)
3757
38−Communication:
58+Artifacts successfully built with Hydra are published to cache at
59+https://cache.nixos.org/. When successful build and test criteria are
60+met, the Nixpkgs expressions are distributed via [Nix
61+channels](https://nixos.org/manual/nix/stable/package-management/channels.html).
3962
40−* [Discourse Forum](https://discourse.nixos.org/)
41−* [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
63+# Contributing
64+
65+Nixpkgs is among the most active projects on GitHub. While thousands
66+of open issues and pull requests might seem a lot at first, it helps
67+consider it in the context of the scope of the project. Nixpkgs
68+describes how to build tens of thousands of pieces of software and implements a
69+Linux distribution. The [GitHub Insights](https://github.com/NixOS/nixpkgs/pulse)
70+page gives a sense of the project activity.
71+
72+Community contributions are always welcome through GitHub Issues and
73+Pull Requests. When pull requests are made, our tooling automation bot,
74+[OfBorg](https://github.com/NixOS/ofborg) will perform various checks
75+to help ensure expression quality.
76+
77+The *Nixpkgs maintainers* are people who have assigned themselves to
78+maintain specific individual packages. We encourage people who care
79+about a package to assign themselves as a maintainer. When a pull
80+request is made against a package, OfBorg will notify the appropriate
81+maintainer(s). The *Nixpkgs committers* are people who have been given
82+permission to merge.
83+
84+Most contributions are based on and merged into these branches:
85+
86+* `master` is the main branch where all small contributions go
87+* `staging` is branched from master, changes that have a big impact on
88+ Hydra builds go to this branch
89+* `staging-next` is branched from staging and only fixes to stabilize
90+ and security fixes with a big impact on Hydra builds should be
91+ contributed to this branch. This branch is merged into master when
92+ deemed of sufficiently high quality
93+
94+For more information about contributing to the project, please visit
95+the [contributing page](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md).
96+
97+# Donations
98+
99+The infrastructure for NixOS and related projects is maintained by a
100+nonprofit organization, the [NixOS
101+Foundation](https://nixos.org/nixos/foundation.html). To ensure the
102+continuity and expansion of the NixOS infrastructure, we are looking
103+for donations to our organization.
104+
105+You can donate to the NixOS foundation through [SEPA bank
106+transfers](https://nixos.org/donate.html) or by using Open Collective:
107+
108+<a href="https://opencollective.com/nixos#support"><img src="https://opencollective.com/nixos/tiers/supporter.svg?width=890" /></a>
109+
110+# License
111+
112+Nixpkgs is licensed under the [MIT License](COPYING).
42113
43−Note: MIT license does not apply to the packages built by Nixpkgs, merely to
44−the package descriptions (Nix expressions, build scripts, and so on). It also
45−might not apply to patches included in Nixpkgs, which may be derivative works
46−of the packages to which they apply. The aforementioned artifacts are all
47−covered by the licenses of the respective packages.
114+Note: MIT license does not apply to the packages built by Nixpkgs,
115+merely to the files in this repository (the Nix expressions, build
116+scripts, NixOS modules, etc.). It also might not apply to patches
117+included in Nixpkgs, which may be derivative works of the packages to
118+which they apply. The aforementioned artifacts are all covered by the
119+licenses of the respective packages.
default.nix+1−1
@@ -14,7 +14,7 @@ if ! builtins ? nixVersion || builtins.compareVersions requiredVersion builtins.
1414 - If you installed Nix using the install script (https://nixos.org/nix/install),
1515 it is safe to upgrade by running it again:
1616
17− curl https://nixos.org/nix/install | sh
17+ curl -L https://nixos.org/nix/install | sh
1818
1919 For more information, please see the NixOS release notes at
2020 https://nixos.org/nixos/manual or locally at
doc/.gitignore+4−3
@@ -1,7 +1,8 @@
11*.chapter.xml
22*.section.xml
33.version
4−out
5−manual-full.xml
6−highlightjs
4+functions/library/generated
75functions/library/locations.xml
6+highlightjs
7+manual-full.xml
8+out
doc/Makefile+57−45
@@ -1,4 +1,20 @@
1−MD_TARGETS=$(addsuffix .xml, $(basename $(wildcard ./*.md ./**/*.md)))
1+MD_TARGETS=$(addsuffix .xml, $(basename $(shell find . -type f -regex '.*\.md$$' -not -name README.md)))
2+
3+PANDOC ?= pandoc
4+
5+pandoc_media_dir = media
6+# NOTE: Keep in sync with NixOS manual (/nixos/doc/manual/md-to-db.sh) and conversion script (/maintainers/scripts/db-to-md.sh).
7+# TODO: Remove raw-attribute when we can get rid of DocBook altogether.
8+pandoc_commonmark_enabled_extensions = +attributes+fenced_divs+footnotes+bracketed_spans+definition_lists+pipe_tables+raw_attribute
9+# Not needed:
10+# - docbook-reader/citerefentry-to-rst-role.lua (only relevant for DocBook → MarkDown/rST/MyST)
11+pandoc_flags = --extract-media=$(pandoc_media_dir) \
12+ --lua-filter=$(PANDOC_LUA_FILTERS_DIR)/diagram-generator.lua \
13+ --lua-filter=build-aux/pandoc-filters/myst-reader/roles.lua \
14+ --lua-filter=build-aux/pandoc-filters/link-unix-man-references.lua \
15+ --lua-filter=build-aux/pandoc-filters/docbook-writer/rst-roles.lua \
16+ --lua-filter=build-aux/pandoc-filters/docbook-writer/labelless-link-is-xref.lua \
17+ -f commonmark$(pandoc_commonmark_enabled_extensions)+smart
218
319.PHONY: all
420all: validate format out/html/index.html out/epub/manual.epub
@@ -8,9 +24,11 @@ debug:
824 nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"
925
1026.PHONY: format
11−format:
12− find . -iname '*.xml' -type f -print0 | xargs -0 -I{} -n1 \
13− xmlformat --config-file "$$XMLFORMAT_CONFIG" -i {}
27+format: doc-support/result
28+ find . -iname '*.xml' -type f | while read f; do \
29+ echo $$f ;\
30+ xmlformat --config-file "doc-support/result/xmlformat.conf" -i $$f ;\
31+ done
1432
1533.PHONY: fix-misc-xml
1634fix-misc-xml:
@@ -19,86 +37,80 @@ fix-misc-xml:
1937
2038.PHONY: clean
2139clean:
22− rm -f ${MD_TARGETS} .version manual-full.xml functions/library/locations.xml
23− rm -rf ./out/ ./highlightjs
40+ rm -f ${MD_TARGETS} doc-support/result .version manual-full.xml functions/library/locations.xml functions/library/generated
41+ rm -rf ./out/ ./highlightjs ./media
2442
2543.PHONY: validate
26−validate: manual-full.xml
27− jing "$$RNG" manual-full.xml
44+validate: manual-full.xml doc-support/result
45+ jing doc-support/result/docbook.rng manual-full.xml
2846
29−out/html/index.html: manual-full.xml style.css highlightjs
47+out/html/index.html: doc-support/result manual-full.xml style.css highlightjs
3048 mkdir -p out/html
31− xsltproc ${xsltFlags} \
49+ xsltproc \
3250 --nonet --xinclude \
3351 --output $@ \
34− "$$XSL/docbook/xhtml/docbook.xsl" \
52+ doc-support/result/xhtml.xsl \
3553 ./manual-full.xml
3654
3755 mkdir -p out/html/highlightjs/
3856 cp -r highlightjs out/html/
3957
58+ cp -r $(pandoc_media_dir) out/html/
4059 cp ./overrides.css out/html/
4160 cp ./style.css out/html/style.css
4261
4362 mkdir -p out/html/images/callouts
44− cp "$$XSL/docbook/images/callouts/"*.svg out/html/images/callouts/
63+ cp doc-support/result/xsl/docbook/images/callouts/*.svg out/html/images/callouts/
4564 chmod u+w -R out/html/
4665
4766out/epub/manual.epub: manual-full.xml
4867 mkdir -p out/epub/scratch
49− xsltproc ${xsltFlags} --nonet \
68+ xsltproc --nonet \
5069 --output out/epub/scratch/ \
51− "$$XSL/docbook/epub/docbook.xsl" \
70+ doc-support/result/epub.xsl \
5271 ./manual-full.xml
5372
73+ cp -r $(pandoc_media_dir) out/epub/scratch/OEBPS
5474 cp ./overrides.css out/epub/scratch/OEBPS
5575 cp ./style.css out/epub/scratch/OEBPS
5676 mkdir -p out/epub/scratch/OEBPS/images/callouts/
57− cp "$$XSL/docbook/images/callouts/"*.svg out/epub/scratch/OEBPS/images/callouts/
77+ cp doc-support/result/xsl/docbook/images/callouts/*.svg out/epub/scratch/OEBPS/images/callouts/
5878 echo "application/epub+zip" > mimetype
5979 zip -0Xq "out/epub/manual.epub" mimetype
6080 rm mimetype
6181 cd "out/epub/scratch/" && zip -Xr9D "../manual.epub" *
6282 rm -rf "out/epub/scratch/"
6383
64−highlightjs:
84+highlightjs: doc-support/result
6585 mkdir -p highlightjs
66− cp -r "$$HIGHLIGHTJS/highlight.pack.js" highlightjs/
67− cp -r "$$HIGHLIGHTJS/LICENSE" highlightjs/
68− cp -r "$$HIGHLIGHTJS/mono-blue.css" highlightjs/
69− cp -r "$$HIGHLIGHTJS/loader.js" highlightjs/
86+ cp -r doc-support/result/highlightjs/highlight.pack.js highlightjs/
87+ cp -r doc-support/result/highlightjs/LICENSE highlightjs/
88+ cp -r doc-support/result/highlightjs/mono-blue.css highlightjs/
89+ cp -r doc-support/result/highlightjs/loader.js highlightjs/
7090
7191
72−manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml *.xml **/*.xml **/**/*.xml
92+manual-full.xml: ${MD_TARGETS} .version functions/library/locations.xml functions/library/generated *.xml **/*.xml **/**/*.xml
7393 xmllint --nonet --xinclude --noxincludenode manual.xml --output manual-full.xml
7494
75−.version:
76− nix-instantiate --eval \
77− -E '(import ../lib).version' > .version
95+.version: doc-support/result
96+ ln -rfs ./doc-support/result/version .version
7897
79−functions/library/locations.xml:
80− nix-build ./lib-function-locations.nix \
81− --out-link ./functions/library/locations.xml
98+doc-support/result: doc-support/default.nix
99+ (cd doc-support; nix-build)
100+
101+functions/library/locations.xml: doc-support/result
102+ ln -rfs ./doc-support/result/function-locations.xml functions/library/locations.xml
103+
104+functions/library/generated: doc-support/result
105+ ln -rfs ./doc-support/result/function-docs functions/library/generated
82106
83107%.section.xml: %.section.md
84− pandoc $^ -w docbook+smart \
85− -f markdown+smart \
86− | sed -e 's|<ulink url=|<link xlink:href=|' \
87− -e 's|</ulink>|</link>|' \
88− -e 's|<sect. id=|<section xml:id=|' \
89− -e 's|</sect[0-9]>|</section>|' \
90− -e '1s| id=| xml:id=|' \
91− -e '1s|\(<[^ ]* \)|\1xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" |' \
92− | cat > $@
108+ $(PANDOC) $^ -t docbook \
109+ $(pandoc_flags) \
110+ -o $@
93111
94112%.chapter.xml: %.chapter.md
95− pandoc $^ -w docbook+smart \
113+ $(PANDOC) $^ -t docbook \
96114 --top-level-division=chapter \
97− -f markdown+smart \
98− | sed -e 's|<ulink url=|<link xlink:href=|' \
99− -e 's|</ulink>|</link>|' \
100− -e 's|<sect. id=|<section xml:id=|' \
101− -e 's|</sect[0-9]>|</section>|' \
102− -e '1s| id=| xml:id=|' \
103− -e '1s|\(<[^ ]* \)|\1|' \
104− | cat > $@
115+ $(pandoc_flags) \
116+ -o $@
doc/README.mdnew file+12
@@ -0,0 +1,12 @@
1+
2+# Nixpkgs/doc
3+
4+This directory houses the sources files for the Nixpkgs manual.
5+
6+You can find the [rendered documentation for Nixpkgs `unstable` on nixos.org](https://nixos.org/manual/nixpkgs/unstable/).
7+
8+[Docs for Nixpkgs stable](https://nixos.org/manual/nixpkgs/stable/) are also available.
9+
10+If you want to contribute to the documentation, [here's how to do it](https://nixos.org/manual/nixpkgs/unstable/#chap-contributing).
11+
12+If you're only getting started with Nix, go to [nixos.org/learn](https://nixos.org/learn).
doc/build-aux/pandoc-filters/docbook-reader/citerefentry-to-rst-role.luanew file+23
@@ -0,0 +1,23 @@
1+--[[
2+Converts Code AST nodes produced by pandoc’s DocBook reader
3+from citerefentry elements into AST for corresponding role
4+for reStructuredText.
5+
6+We use subset of MyST syntax (CommonMark with features from rST)
7+so let’s use the rST AST for rST features.
8+
9+Reference: https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage
10+]]
11+
12+function Code(elem)
13+ elem.classes = elem.classes:map(function (x)
14+ if x == 'citerefentry' then
15+ elem.attributes['role'] = 'manpage'
16+ return 'interpreted-text'
17+ else
18+ return x
19+ end
20+ end)
21+
22+ return elem
23+end
doc/build-aux/pandoc-filters/docbook-writer/labelless-link-is-xref.luanew file+34
@@ -0,0 +1,34 @@
1+--[[
2+Converts Link AST nodes with empty label to DocBook xref elements.
3+
4+This is a temporary script to be able use cross-references conveniently
5+using syntax taken from MyST, while we still use docbook-xsl
6+for generating the documentation.
7+
8+Reference: https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing
9+]]
10+
11+local function starts_with(start, str)
12+ return str:sub(1, #start) == start
13+end
14+
15+local function escape_xml_arg(arg)
16+ amps = arg:gsub('&', '&')
17+ amps_quotes = amps:gsub('"', '"')
18+ amps_quotes_lt = amps_quotes:gsub('<', '<')
19+
20+ return amps_quotes_lt
21+end
22+
23+function Link(elem)
24+ has_no_content = #elem.content == 0
25+ targets_anchor = starts_with('#', elem.target)
26+ has_no_attributes = elem.title == '' and elem.identifier == '' and #elem.classes == 0 and #elem.attributes == 0
27+
28+ if has_no_content and targets_anchor and has_no_attributes then
29+ -- xref expects idref without the pound-sign
30+ target_without_hash = elem.target:sub(2, #elem.target)
31+
32+ return pandoc.RawInline('docbook', '<xref linkend="' .. escape_xml_arg(target_without_hash) .. '" />')
33+ end
34+end
doc/build-aux/pandoc-filters/docbook-writer/rst-roles.luanew file+36
@@ -0,0 +1,36 @@
1+--[[
2+Converts AST for reStructuredText roles into corresponding
3+DocBook elements.
4+
5+Currently, only a subset of roles is supported.
6+
7+Reference:
8+ List of roles:
9+ https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html
10+ manpage:
11+ https://tdg.docbook.org/tdg/5.1/citerefentry.html
12+ file:
13+ https://tdg.docbook.org/tdg/5.1/filename.html
14+]]
15+
16+function Code(elem)
17+ if elem.classes:includes('interpreted-text') then
18+ local tag = nil
19+ local content = elem.text
20+ if elem.attributes['role'] == 'manpage' then
21+ tag = 'citerefentry'
22+ local title, volnum = content:match('^(.+)%((%w+)%)$')
23+ if title == nil then
24+ -- No volnum in parentheses.
25+ title = content
26+ end
27+ content = '<refentrytitle>' .. title .. '</refentrytitle>' .. (volnum ~= nil and ('<manvolnum>' .. volnum .. '</manvolnum>') or '')
28+ elseif elem.attributes['role'] == 'file' then
29+ tag = 'filename'
30+ end
31+
32+ if tag ~= nil then
33+ return pandoc.RawInline('docbook', '<' .. tag .. '>' .. content .. '</' .. tag .. '>')
34+ end
35+ end
36+end
doc/build-aux/pandoc-filters/link-unix-man-references.luanew file+17
@@ -0,0 +1,17 @@
1+--[[
2+Turns a manpage reference into a link, when a mapping is defined below.
3+]]
4+
5+local man_urls = {
6+ ["tmpfiles.d(5)"] = "https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html",
7+ ["nix.conf(5)"] = "https://nixos.org/manual/nix/stable/#sec-conf-file",
8+ ["systemd.time(7)"] = "https://www.freedesktop.org/software/systemd/man/systemd.time.html",
9+ ["systemd.timer(5)"] = "https://www.freedesktop.org/software/systemd/man/systemd.timer.html",
10+}
11+
12+function Code(elem)
13+ local is_man_role = elem.classes:includes('interpreted-text') and elem.attributes['role'] == 'manpage'
14+ if is_man_role and man_urls[elem.text] ~= nil then
15+ return pandoc.Link(elem, man_urls[elem.text])
16+ end
17+end
doc/build-aux/pandoc-filters/myst-reader/roles.luanew file+29
@@ -0,0 +1,29 @@
1+--[[
2+Replaces Str AST nodes containing {role}, followed by a Code node
3+by a Code node with attrs that would be produced by rST reader
4+from the role syntax.
5+
6+This is to emulate MyST syntax in Pandoc.
7+(MyST is a CommonMark flavour with rST features mixed in.)
8+
9+Reference: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point
10+]]
11+
12+function Inlines(inlines)
13+ for i = #inlines-1,1,-1 do
14+ local first = inlines[i]
15+ local second = inlines[i+1]
16+ local correct_tags = first.tag == 'Str' and second.tag == 'Code'
17+ if correct_tags then
18+ -- docutils supports alphanumeric strings separated by [-._:]
19+ -- We are slightly more liberal for simplicity.
20+ local role = first.text:match('^{([-._+:%w]+)}$')
21+ if role ~= nil then
22+ inlines:remove(i)
23+ second.attributes['role'] = role
24+ second.classes:insert('interpreted-text')
25+ end
26+ end
27+ end
28+ return inlines
29+end
doc/build-aux/pandoc-filters/myst-writer/roles.luanew file+25
@@ -0,0 +1,25 @@
1+--[[
2+Replaces Code nodes with attrs that would be produced by rST reader
3+from the role syntax by a Str AST node containing {role}, followed by a Code node.
4+
5+This is to emulate MyST syntax in Pandoc.
6+(MyST is a CommonMark flavour with rST features mixed in.)
7+
8+Reference: https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point
9+]]
10+
11+function Code(elem)
12+ local role = elem.attributes['role']
13+
14+ if elem.classes:includes('interpreted-text') and role ~= nil then
15+ elem.classes = elem.classes:filter(function (c)
16+ return c ~= 'interpreted-text'
17+ end)
18+ elem.attributes['role'] = nil
19+
20+ return {
21+ pandoc.Str('{' .. role .. '}'),
22+ elem,
23+ }
24+ end
25+end
doc/builders/fetchers.chapter.mdnew file+114
@@ -0,0 +1,114 @@
1+# Fetchers {#chap-pkgs-fetchers}
2+
3+When using Nix, you will frequently need to download source code and other files from the internet. For this purpose, Nix provides the [_fixed output derivation_](https://nixos.org/manual/nix/stable/#fixed-output-drvs) feature and Nixpkgs provides various functions that implement the actual fetching from various protocols and services.
4+
5+## Caveats
6+
7+Because fixed output derivations are _identified_ by their hash, a common mistake is to update a fetcher's URL or a version parameter, without updating the hash. **This will cause the old contents to be used.** So remember to always invalidate the hash argument.
8+
9+For those who develop and maintain fetchers, a similar problem arises with changes to the implementation of a fetcher. These may cause a fixed output derivation to fail, but won't normally be caught by tests because the supposed output is already in the store or cache. For the purpose of testing, you can use a trick that is embodied by the [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function. It uses the derivation `name` to create a unique output path per fetcher implementation, defeating the caching precisely where it would be harmful.
10+
11+## `fetchurl` and `fetchzip` {#fetchurl}
12+
13+Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
14+
15+```nix
16+{ stdenv, fetchurl }:
17+
18+stdenv.mkDerivation {
19+ name = "hello";
20+ src = fetchurl {
21+ url = "http://www.example.org/hello.tar.gz";
22+ sha256 = "1111111111111111111111111111111111111111111111111111";
23+ };
24+}
25+```
26+
27+The main difference between `fetchurl` and `fetchzip` is in how they store the contents. `fetchurl` will store the unaltered contents of the URL within the Nix store. `fetchzip` on the other hand, will decompress the archive for you, making files and directories directly accessible in the future. `fetchzip` can only be used with archives. Despite the name, `fetchzip` is not limited to .zip files and can also be used with any tarball.
28+
29+`fetchpatch` works very similarly to `fetchurl` with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
30+
31+Most other fetchers return a directory rather than a single file.
32+
33+## `fetchsvn` {#fetchsvn}
34+
35+Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha256`.
36+
37+## `fetchgit` {#fetchgit}
38+
39+Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
40+
41+Additionally, the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
42+
43+If only parts of the repository are needed, `sparseCheckout` can be used. This will prevent git from fetching unnecessary blobs from server, see [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) and [git clone --filter](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---filterltfilter-specgt) for more information:
44+
45+```nix
46+{ stdenv, fetchgit }:
47+
48+stdenv.mkDerivation {
49+ name = "hello";
50+ src = fetchgit {
51+ url = "https://...";
52+ sparseCheckout = ''
53+ path/to/be/included
54+ another/path
55+ '';
56+ sha256 = "0000000000000000000000000000000000000000000000000000";
57+ };
58+}
59+```
60+
61+## `fetchfossil` {#fetchfossil}
62+
63+Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `sha256`.
64+
65+## `fetchcvs` {#fetchcvs}
66+
67+Used with CVS. Expects `cvsRoot`, `tag`, and `sha256`.
68+
69+## `fetchhg` {#fetchhg}
70+
71+Used with Mercurial. Expects `url`, `rev`, and `sha256`.
72+
73+A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
74+
75+## `fetchFromGitea` {#fetchfromgitea}
76+
77+`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
78+
79+## `fetchFromGitHub` {#fetchfromgithub}
80+
81+`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` is currently preferred.
82+
83+`fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.
84+
85+## `fetchFromGitLab` {#fetchfromgitlab}
86+
87+This is used with GitLab repositories. The arguments expected are very similar to `fetchFromGitHub` above.
88+
89+## `fetchFromGitiles` {#fetchfromgitiles}
90+
91+This is used with Gitiles repositories. The arguments expected are similar to `fetchgit`.
92+
93+## `fetchFromBitbucket` {#fetchfrombitbucket}
94+
95+This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
96+
97+## `fetchFromSavannah` {#fetchfromsavannah}
98+
99+This is used with Savannah repositories. The arguments expected are very similar to `fetchFromGitHub` above.
100+
101+## `fetchFromRepoOrCz` {#fetchfromrepoorcz}
102+
103+This is used with repo.or.cz repositories. The arguments expected are very similar to `fetchFromGitHub` above.
104+
105+## `fetchFromSourcehut` {#fetchfromsourcehut}
106+
107+This is used with sourcehut repositories. Similar to `fetchFromGitHub` above,
108+it expects `owner`, `repo`, `rev` and `sha256`, but don't forget the tilde (~)
109+in front of the username! Expected arguments also include `vc` ("git" (default)
110+or "hg"), `domain` and `fetchSubmodules`.
111+
112+If `fetchSubmodules` is `true`, `fetchFromSourcehut` uses `fetchgit`
113+or `fetchhg` with `fetchSubmodules` or `fetchSubrepos` set to `true`,
114+respectively. Otherwise, the fetcher uses `fetchzip`.
doc/builders/images.xmlnew file+12
@@ -0,0 +1,12 @@
1+<chapter xmlns="http://docbook.org/ns/docbook"
2+ xmlns:xi="http://www.w3.org/2001/XInclude"
3+ xml:id="chap-images">
4+ <title>Images</title>
5+ <para>
6+ This chapter describes tools for creating various types of images.
7+ </para>
8+ <xi:include href="images/appimagetools.section.xml" />
9+ <xi:include href="images/dockertools.section.xml" />
10+ <xi:include href="images/ocitools.section.xml" />
11+ <xi:include href="images/snaptools.section.xml" />
12+</chapter>
doc/builders/images/appimagetools.section.mdnew file+48
@@ -0,0 +1,48 @@
1+# pkgs.appimageTools {#sec-pkgs-appimageTools}
2+
3+`pkgs.appimageTools` is a set of functions for extracting and wrapping [AppImage](https://appimage.org/) files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, `pkgs.appimage-run` can be used as well.
4+
5+::: {.warning}
6+The `appimageTools` API is unstable and may be subject to backwards-incompatible changes in the future.
7+:::
8+
9+## AppImage formats {#ssec-pkgs-appimageTools-formats}
10+
11+There are different formats for AppImages, see [the specification](https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format) for details.
12+
13+- Type 1 images are ISO 9660 files that are also ELF executables.
14+- Type 2 images are ELF executables with an appended filesystem.
15+
16+They can be told apart with `file -k`:
17+
18+```ShellSession
19+$ file -k type1.AppImage
20+type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0,
21+spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped\012- data
22+
23+$ file -k type2.AppImage
24+type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped\012- data
25+```
26+
27+Note how the type 1 AppImage is described as an `ISO 9660 CD-ROM filesystem`, and the type 2 AppImage is not.
28+
29+## Wrapping {#ssec-pkgs-appimageTools-wrapping}
30+
31+Depending on the type of AppImage you're wrapping, you'll have to use `wrapType1` or `wrapType2`.
32+
33+```nix
34+appimageTools.wrapType2 { # or wrapType1
35+ name = "patchwork";
36+ src = fetchurl {
37+ url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
38+ sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
39+ };
40+ extraPkgs = pkgs: with pkgs; [ ];
41+}
42+```
43+
44+- `name` specifies the name of the resulting image.
45+- `src` specifies the AppImage file to extract.
46+- `extraPkgs` allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs:
47+ - Looking through the extracted AppImage files, reading its scripts and running `patchelf` and `ldd` on its executables. This can also be done in `appimage-run`, by setting `APPIMAGE_DEBUG_EXEC=bash`.
48+ - Running `strace -vfefile` on the wrapped executable, looking for libraries that can't be found.
doc/builders/images/dockertools.section.mdnew file+314
@@ -0,0 +1,314 @@
1+# pkgs.dockerTools {#sec-pkgs-dockerTools}
2+
3+`pkgs.dockerTools` is a set of functions for creating and manipulating Docker images according to the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120). Docker itself is not used to perform any of the operations done by these functions.
4+
5+## buildImage {#ssec-pkgs-dockerTools-buildImage}
6+
7+This function is analogous to the `docker build` command, in that it can be 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`.
8+
9+The parameters of `buildImage` with relative example values are described below:
10+
11+[]{#ex-dockerTools-buildImage}
12+[]{#ex-dockerTools-buildImage-runAsRoot}
13+
14+```nix
15+buildImage {
16+ name = "redis";
17+ tag = "latest";
18+
19+ fromImage = someBaseImage;
20+ fromImageName = null;
21+ fromImageTag = "latest";
22+
23+ contents = pkgs.redis;
24+ runAsRoot = ''
25+ #!${pkgs.runtimeShell}
26+ mkdir -p /data
27+ '';
28+
29+ config = {
30+ Cmd = [ "/bin/redis-server" ];
31+ WorkingDir = "/data";
32+ Volumes = { "/data" = { }; };
33+ };
34+}
35+```
36+
37+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.
38+
39+- `name` specifies the name of the resulting image. This is the only required argument for `buildImage`.
40+
41+- `tag` specifies the tag of the resulting image. By default it's `null`, which indicates that the nix output hash will be used as tag.
42+
43+- `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`.
44+
45+- `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.
46+
47+- `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.
48+
49+- `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`.
50+
51+- `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`.
52+
53+> **_NOTE:_** Using this parameter requires the `kvm` device to be available.
54+
55+- `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.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
56+
57+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.
58+
59+At the end of the process, only one new single layer will be produced and added to the resulting image.
60+
61+The resulting repository will only list the single image `image/tag`. In the case of [the `buildImage` example](#ex-dockerTools-buildImage), it would be `redis/latest`.
62+
63+It is possible to inspect the arguments with which an image was built using its `buildArgs` attribute.
64+
65+> **_NOTE:_** If you see errors similar to `getProtocolByName: does not exist (no such protocol name: tcp)` you may need to add `pkgs.iana-etc` to `contents`.
66+
67+> **_NOTE:_** If you see errors similar to `Error_Protocol ("certificate has unknown CA",True,UnknownCa)` you may need to add `pkgs.cacert` to `contents`.
68+
69+By default `buildImage` will use a static date of one second past the UNIX Epoch. This allows `buildImage` to produce binary reproducible images. When listing images with `docker images`, the newly created images will be listed like this:
70+
71+```ShellSession
72+$ docker images
73+REPOSITORY TAG IMAGE ID CREATED SIZE
74+hello latest 08c791c7846e 48 years ago 25.2MB
75+```
76+
77+You can break binary reproducibility but have a sorted, meaningful `CREATED` column by setting `created` to `now`.
78+
79+```nix
80+pkgs.dockerTools.buildImage {
81+ name = "hello";
82+ tag = "latest";
83+ created = "now";
84+ contents = pkgs.hello;
85+
86+ config.Cmd = [ "/bin/hello" ];
87+}
88+```
89+
90+Now the Docker CLI will display a reasonable date and sort the images as expected:
91+
92+```ShellSession
93+$ docker images
94+REPOSITORY TAG IMAGE ID CREATED SIZE
95+hello latest de2bf4786de6 About a minute ago 25.2MB
96+```
97+
98+However, the produced images will not be binary reproducible.
99+
100+## buildLayeredImage {#ssec-pkgs-dockerTools-buildLayeredImage}
101+
102+Create a Docker image with many of the store paths being on their own layer to improve sharing between images. The image is realized into the Nix store as a gzipped tarball. Depending on the intended usage, many users might prefer to use `streamLayeredImage` instead, which this function uses internally.
103+
104+`name`
105+
106+: The name of the resulting image.
107+
108+`tag` _optional_
109+
110+: Tag of the generated image.
111+
112+ *Default:* the output path's hash
113+
114+`fromImage` _optional_
115+
116+: The repository tarball containing the base image. It must be a valid Docker image, such as one exported by `docker save`.
117+
118+ *Default:* `null`, which can be seen as equivalent to `FROM scratch` of a `Dockerfile`.
119+
120+`contents` _optional_
121+
122+: Top-level paths in the container. Either a single derivation, or a list of derivations.
123+
124+ *Default:* `[]`
125+
126+`config` _optional_
127+
128+: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
129+
130+ *Default:* `{}`
131+
132+`created` _optional_
133+
134+: Date and time the layers were created. Follows the same `now` exception supported by `buildImage`.
135+
136+ *Default:* `1970-01-01T00:00:01Z`
137+
138+`maxLayers` _optional_
139+
140+: Maximum number of layers to create.
141+
142+ *Default:* `100`
143+
144+ *Maximum:* `125`
145+
146+`extraCommands` _optional_
147+
148+: Shell commands to run while building the final layer, without access to most of the layer contents. Changes to this layer are "on top" of all the other layers, so can create additional directories and files.
149+
150+`fakeRootCommands` _optional_
151+
152+: Shell commands to run while creating the archive for the final layer in a fakeroot environment. Unlike `extraCommands`, you can run `chown` to change the owners of the files in the archive, changing fakeroot's state instead of the real filesystem. The latter would require privileges that the build user does not have. Static binaries do not interact with the fakeroot environment. By default all files in the archive will be owned by root.
153+
154+`enableFakechroot` _optional_
155+
156+: Whether to run in `fakeRootCommands` in `fakechroot`, making programs behave as though `/` is the root of the image being created, while files in the Nix store are available as usual. This allows scripts that perform installation in `/` to work as expected. Considering that `fakechroot` is implemented via the same mechanism as `fakeroot`, the same caveats apply.
157+
158+ *Default:* `false`
159+
160+### Behavior of `contents` in the final image {#dockerTools-buildLayeredImage-arg-contents}
161+
162+Each path directly listed in `contents` will have a symlink in the root of the image.
163+
164+For example:
165+
166+```nix
167+pkgs.dockerTools.buildLayeredImage {
168+ name = "hello";
169+ contents = [ pkgs.hello ];
170+}
171+```
172+
173+will create symlinks for all the paths in the `hello` package:
174+
175+```ShellSession
176+/bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello
177+/share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info
178+/share/locale/bg/LC_MESSAGES/hello.mo -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/locale/bg/LC_MESSAGES/hello.mo
179+```
180+
181+### Automatic inclusion of `config` references {#dockerTools-buildLayeredImage-arg-config}
182+
183+The closure of `config` is automatically included in the closure of the final image.
184+
185+This allows you to make very simple Docker images with very little code. This container will start up and run `hello`:
186+
187+```nix
188+pkgs.dockerTools.buildLayeredImage {
189+ name = "hello";
190+ config.Cmd = [ "${pkgs.hello}/bin/hello" ];
191+}
192+```
193+
194+### Adjusting `maxLayers` {#dockerTools-buildLayeredImage-arg-maxLayers}
195+
196+Increasing the `maxLayers` increases the number of layers which have a chance to be shared between different images.
197+
198+Modern Docker installations support up to 128 layers, but older versions support as few as 42.
199+
200+If the produced image will not be extended by other Docker builds, it is safe to set `maxLayers` to `128`. However, it will be impossible to extend the image further.
201+
202+The first (`maxLayers-2`) most "popular" paths will have their own individual layers, then layer \#`maxLayers-1` will contain all the remaining "unpopular" paths, and finally layer \#`maxLayers` will contain the Image configuration.
203+
204+Docker's Layers are not inherently ordered, they are content-addressable and are not explicitly layered until they are composed in to an Image.
205+
206+## streamLayeredImage {#ssec-pkgs-dockerTools-streamLayeredImage}
207+
208+Builds a script which, when run, will stream an uncompressed tarball of a Docker image to stdout. The arguments to this function are as for `buildLayeredImage`. This method of constructing an image does not realize the image into the Nix store, so it saves on IO and disk/cache space, particularly with large images.
209+
210+The image produced by running the output script can be piped directly into `docker load`, to load it into the local docker daemon:
211+
212+```ShellSession
213+$(nix-build) | docker load
214+```
215+
216+Alternatively, the image be piped via `gzip` into `skopeo`, e.g., to copy it into a registry:
217+
218+```ShellSession
219+$(nix-build) | gzip --fast | skopeo copy docker-archive:/dev/stdin docker://some_docker_registry/myimage:tag
220+```
221+
222+## pullImage {#ssec-pkgs-dockerTools-fetchFromRegistry}
223+
224+This function is analogous to the `docker pull` command, in that it can be used to pull a Docker image from a Docker registry. By default [Docker Hub](https://hub.docker.com/) is used to pull images.
225+
226+Its parameters are described in the example below:
227+
228+```nix
229+pullImage {
230+ imageName = "nixos/nix";
231+ imageDigest =
232+ "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b";
233+ finalImageName = "nix";
234+ finalImageTag = "1.11";
235+ sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8";
236+ os = "linux";
237+ arch = "x86_64";
238+}
239+```
240+
241+- `imageName` specifies the name of the image to be downloaded, which can also include the registry namespace (e.g. `nixos`). This argument is required.
242+
243+- `imageDigest` specifies the digest of the image to be downloaded. This argument is required.
244+
245+- `finalImageName`, if specified, this is the name of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's equal to `imageName`.
246+
247+- `finalImageTag`, if specified, this is the tag of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's `latest`.
248+
249+- `sha256` is the checksum of the whole fetched image. This argument is required.
250+
251+- `os`, if specified, is the operating system of the fetched image. By default it's `linux`.
252+
253+- `arch`, if specified, is the cpu architecture of the fetched image. By default it's `x86_64`.
254+
255+`nix-prefetch-docker` command can be used to get required image parameters:
256+
257+```ShellSession
258+$ nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
259+```
260+
261+Since a given `imageName` may transparently refer to a manifest list of images which support multiple architectures and/or operating systems, you can supply the `--os` and `--arch` arguments to specify exactly which image you want. By default it will match the OS and architecture of the host the command is run on.
262+
263+```ShellSession
264+$ nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
265+```
266+
267+Desired image name and tag can be set using `--final-image-name` and `--final-image-tag` arguments:
268+
269+```ShellSession
270+$ nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
271+```
272+
273+## exportImage {#ssec-pkgs-dockerTools-exportImage}
274+
275+This function is analogous to the `docker export` command, in that it can be 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`.
276+
277+> **_NOTE:_** Using this function requires the `kvm` device to be available.
278+
279+The parameters of `exportImage` are the following:
280+
281+```nix
282+exportImage {
283+ fromImage = someLayeredImage;
284+ fromImageName = null;
285+ fromImageTag = null;
286+
287+ name = someLayeredImage.name;
288+}
289+```
290+
291+The parameters relative to the base image have the same synopsis as described in [buildImage](#ssec-pkgs-dockerTools-buildImage), except that `fromImage` is the only required argument in this case.
292+
293+The `name` argument is the name of the derivation output, which defaults to `fromImage.name`.
294+
295+## shadowSetup {#ssec-pkgs-dockerTools-shadowSetup}
296+
297+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 [`buildImage` `runAsRoot`](#ex-dockerTools-buildImage-runAsRoot) script for cases like in the example below:
298+
299+```nix
300+buildImage {
301+ name = "shadow-basic";
302+
303+ runAsRoot = ''
304+ #!${pkgs.runtimeShell}
305+ ${shadowSetup}
306+ groupadd -r redis
307+ useradd -r -g redis redis
308+ mkdir /data
309+ chown redis:redis /data
310+ '';
311+}
312+```
313+
314+Creating base files like `/etc/passwd` or `/etc/login.defs` is necessary for shadow-utils to manipulate users and groups.
doc/builders/images/ocitools.section.mdnew file+37
@@ -0,0 +1,37 @@
1+# pkgs.ociTools {#sec-pkgs-ociTools}
2+
3+`pkgs.ociTools` is a set of functions for creating containers according to the [OCI container specification v1.0.0](https://github.com/opencontainers/runtime-spec). Beyond that, it makes no assumptions about the container runner you choose to use to run the created container.
4+
5+## buildContainer {#ssec-pkgs-ociTools-buildContainer}
6+
7+This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a `config.json` and a rootfs directory. The nix store of the container will contain all referenced dependencies of the given command.
8+
9+The parameters of `buildContainer` with an example value are described below:
10+
11+```nix
12+buildContainer {
13+ args = [
14+ (with pkgs;
15+ writeScript "run.sh" ''
16+ #!${bash}/bin/bash
17+ exec ${bash}/bin/bash
18+ '').outPath
19+ ];
20+
21+ mounts = {
22+ "/data" = {
23+ type = "none";
24+ source = "/var/lib/mydata";
25+ options = [ "bind" ];
26+ };
27+ };
28+
29+ readonly = false;
30+}
31+```
32+
33+- `args` specifies a set of arguments to run inside the container. This is the only required argument for `buildContainer`. All referenced packages inside the derivation will be made available inside the container.
34+
35+- `mounts` specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
36+
37+- `readonly` makes the container\'s rootfs read-only if it is set to true. The default value is false `false`.
doc/builders/images/snaptools.section.mdnew file+71
@@ -0,0 +1,71 @@
1+# pkgs.snapTools {#sec-pkgs-snapTools}
2+
3+`pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations.
4+
5+## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature}
6+
7+`makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly.
8+
9+The `base` should not be specified, as `makeSnap` will force set it.
10+
11+Currently, `makeSnap` does not support creating GUI stubs.
12+
13+## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello}
14+
15+The following expression packages GNU Hello as a Snapcraft snap.
16+
17+``` {#ex-snapTools-buildSnap-hello .nix}
18+let
19+ inherit (import <nixpkgs> { }) snapTools hello;
20+in snapTools.makeSnap {
21+ meta = {
22+ name = "hello";
23+ summary = hello.meta.description;
24+ description = hello.meta.longDescription;
25+ architectures = [ "amd64" ];
26+ confinement = "strict";
27+ apps.hello.command = "${hello}/bin/hello";
28+ };
29+}
30+```
31+
32+`nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package.
33+
34+## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox}
35+
36+Graphical programs require many more integrations with the host. This example uses Firefox as an example because it is one of the most complicated programs we could package.
37+
38+``` {#ex-snapTools-buildSnap-firefox .nix}
39+let
40+ inherit (import <nixpkgs> { }) snapTools firefox;
41+in snapTools.makeSnap {
42+ meta = {
43+ name = "nix-example-firefox";
44+ summary = firefox.meta.description;
45+ architectures = [ "amd64" ];
46+ apps.nix-example-firefox = {
47+ command = "${firefox}/bin/firefox";
48+ plugs = [
49+ "pulseaudio"
50+ "camera"
51+ "browser-support"
52+ "avahi-observe"
53+ "cups-control"
54+ "desktop"
55+ "desktop-legacy"
56+ "gsettings"
57+ "home"
58+ "network"
59+ "mount-observe"
60+ "removable-media"
61+ "x11"
62+ ];
63+ };
64+ confinement = "strict";
65+ };
66+}
67+```
68+
69+`nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package.
70+
71+The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces).
doc/builders/packages/cataclysm-dda.section.mdnew file+129
@@ -0,0 +1,129 @@
1+# Cataclysm: Dark Days Ahead {#cataclysm-dark-days-ahead}
2+
3+## How to install Cataclysm DDA {#how-to-install-cataclysm-dda}
4+
5+To install the latest stable release of Cataclysm DDA to your profile, execute
6+`nix-env -f "<nixpkgs>" -iA cataclysm-dda`. For the curses build (build
7+without tiles), install `cataclysmDDA.stable.curses`. Note: `cataclysm-dda` is
8+an alias to `cataclysmDDA.stable.tiles`.
9+
10+If you like access to a development build of your favorite git revision,
11+override `cataclysm-dda-git` (or `cataclysmDDA.git.curses` if you like curses
12+build):
13+
14+```nix
15+cataclysm-dda-git.override {
16+ version = "YYYY-MM-DD";
17+ rev = "YOUR_FAVORITE_REVISION";
18+ sha256 = "CHECKSUM_OF_THE_REVISION";
19+}
20+```
21+
22+The sha256 checksum can be obtained by
23+
24+```sh
25+nix-prefetch-url --unpack "https://github.com/CleverRaven/Cataclysm-DDA/archive/${YOUR_FAVORITE_REVISION}.tar.gz"
26+```
27+
28+The default configuration directory is `~/.cataclysm-dda`. If you prefer
29+`$XDG_CONFIG_HOME/cataclysm-dda`, override the derivation:
30+
31+```nix
32+cataclysm-dda.override {
33+ useXdgDir = true;
34+}
35+```
36+
37+## Important note for overriding packages {#important-note-for-overriding-packages}
38+
39+After applying `overrideAttrs`, you need to fix `passthru.pkgs` and
40+`passthru.withMods` attributes either manually or by using `attachPkgs`:
41+
42+```nix
43+let
44+ # You enabled parallel building.
45+ myCDDA = cataclysm-dda-git.overrideAttrs (_: {
46+ enableParallelBuilding = true;
47+ });
48+
49+ # Unfortunately, this refers to the package before overriding and
50+ # parallel building is still disabled.
51+ badExample = myCDDA.withMods (_: []);
52+
53+ inherit (cataclysmDDA) attachPkgs pkgs wrapCDDA;
54+
55+ # You can fix it by hand
56+ goodExample1 = myCDDA.overrideAttrs (old: {
57+ passthru = old.passthru // {
58+ pkgs = pkgs.override { build = goodExample1; };
59+ withMods = wrapCDDA goodExample1;
60+ };
61+ });
62+
63+ # or by using a helper function `attachPkgs`.
64+ goodExample2 = attachPkgs pkgs myCDDA;
65+in
66+
67+# badExample # parallel building disabled
68+# goodExample1.withMods (_: []) # parallel building enabled
69+goodExample2.withMods (_: []) # parallel building enabled
70+```
71+
72+## Customizing with mods {#customizing-with-mods}
73+
74+To install Cataclysm DDA with mods of your choice, you can use `withMods`
75+attribute:
76+
77+```nix
78+cataclysm-dda.withMods (mods: with mods; [
79+ tileset.UndeadPeople
80+])
81+```
82+
83+All mods, soundpacks, and tilesets available in nixpkgs are found in
84+`cataclysmDDA.pkgs`.
85+
86+Here is an example to modify existing mods and/or add more mods not available
87+in nixpkgs:
88+
89+```nix
90+let
91+ customMods = self: super: lib.recursiveUpdate super {
92+ # Modify existing mod
93+ tileset.UndeadPeople = super.tileset.UndeadPeople.overrideAttrs (old: {
94+ # If you like to apply a patch to the tileset for example
95+ patches = [ ./path/to/your.patch ];
96+ });
97+
98+ # Add another mod
99+ mod.Awesome = cataclysmDDA.buildMod {
100+ modName = "Awesome";
101+ version = "0.x";
102+ src = fetchFromGitHub {
103+ owner = "Someone";
104+ repo = "AwesomeMod";
105+ rev = "...";
106+ sha256 = "...";
107+ };
108+ # Path to be installed in the unpacked source (default: ".")
109+ modRoot = "contents/under/this/path/will/be/installed";
110+ };
111+
112+ # Add another soundpack
113+ soundpack.Fantastic = cataclysmDDA.buildSoundPack {
114+ # ditto
115+ };
116+
117+ # Add another tileset
118+ tileset.SuperDuper = cataclysmDDA.buildTileSet {
119+ # ditto
120+ };
121+ };
122+in
123+cataclysm-dda.withMods (mods: with mods.extend customMods; [
124+ tileset.UndeadPeople
125+ mod.Awesome
126+ soundpack.Fantastic
127+ tileset.SuperDuper
128+])
129+```
doc/builders/packages/citrix.section.mdnew file+32
@@ -0,0 +1,32 @@
1+# Citrix Workspace {#sec-citrix}
2+
3+The [Citrix Workspace App](https://www.citrix.com/products/workspace-app/) is a remote desktop viewer which provides access to [XenDesktop](https://www.citrix.com/products/xenapp-xendesktop/) installations.
4+
5+## Basic usage {#sec-citrix-base}
6+
7+The tarball archive needs to be downloaded manually, as the license agreements of the vendor for [Citrix Workspace](https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html) needs to be accepted first. Then run `nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz`. With the archive available in the store, the package can be built and installed with Nix.
8+
9+## Citrix Self-service {#sec-citrix-selfservice}
10+
11+The [self-service](https://support.citrix.com/article/CTX200337) is an application managing Citrix desktops and applications. Please note that this feature only works with at least citrix_workspace_20_06_0 and later versions.
12+
13+In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
14+
15+```ShellSession
16+$ storebrowse -C ~/Downloads/receiverconfig.cr
17+$ selfservice
18+```
19+
20+## Custom certificates {#sec-citrix-custom-certs}
21+
22+The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/), however this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
23+
24+```nix
25+with import <nixpkgs> { config.allowUnfree = true; };
26+let
27+ extraCerts = [
28+ ./custom-cert-1.pem
29+ ./custom-cert-2.pem # ...
30+ ];
31+in citrix_workspace.override { inherit extraCerts; }
32+```
doc/builders/packages/dlib.section.mdnew file+13
@@ -0,0 +1,13 @@
1+# DLib {#dlib}
2+
3+[DLib](http://dlib.net/) is a modern, C++-based toolkit which provides several machine learning algorithms.
4+
5+## Compiling without AVX support {#compiling-without-avx-support}
6+
7+Especially older CPUs don\'t support [AVX](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions) (Advanced Vector Extensions) instructions that are used by DLib to optimize their algorithms.
8+
9+On the affected hardware errors like `Illegal instruction` will occur. In those cases AVX support needs to be disabled:
10+
11+```nix
12+self: super: { dlib = super.dlib.override { avxSupport = false; }; }
13+```
doc/builders/packages/eclipse.section.mdnew file+64
@@ -0,0 +1,64 @@
1+# Eclipse {#sec-eclipse}
2+
3+The Nix expressions related to the Eclipse platform and IDE are in [`pkgs/applications/editors/eclipse`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse).
4+
5+Nixpkgs provides a number of packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages and multiple version are often available. It is possible to list available Eclipse packages by issuing the command:
6+
7+```ShellSession
8+$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
9+```
10+
11+Once an Eclipse variant is installed, it can be run using the `eclipse` command, as expected. From within Eclipse, it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
12+
13+If you prefer to install plugins in a more declarative manner, then Nixpkgs also offer a number of Eclipse plugins that can be installed in an _Eclipse environment_. This type of environment is created using the function `eclipseWithPlugins` found inside the `nixpkgs.eclipses` attribute set. This function takes as argument `{ eclipse, plugins ? [], jvmArgs ? [] }` where `eclipse` is a one of the Eclipse packages described above, `plugins` is a list of plugin derivations, and `jvmArgs` is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add:
14+
15+```nix
16+packageOverrides = pkgs: {
17+ myEclipse = with pkgs.eclipses; eclipseWithPlugins {
18+ eclipse = eclipse-platform;
19+ jvmArgs = [ "-Xmx2048m" ];
20+ plugins = [ plugins.color-theme ];
21+ };
22+}
23+```
24+
25+to your Nixpkgs configuration (`~/.config/nixpkgs/config.nix`) and install it by running `nix-env -f '<nixpkgs>' -iA myEclipse` and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using `eclipseWithPlugins` by running:
26+
27+```ShellSession
28+$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
29+```
30+
31+If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the `buildEclipseUpdateSite` and `buildEclipsePlugin` functions found in the `nixpkgs.eclipses.plugins` attribute set. Use the `buildEclipseUpdateSite` function to install a plugin distributed as an Eclipse update site. This function takes `{ name, src }` as argument, where `src` indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available, then the `buildEclipsePlugin` function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument `{ name, srcFeature, srcPlugin }` where `srcFeature` and `srcPlugin` are the feature and plugin JARs, respectively.
32+
33+Expanding the previous example with two plugins using the above functions, we have:
34+
35+```nix
36+packageOverrides = pkgs: {
37+ myEclipse = with pkgs.eclipses; eclipseWithPlugins {
38+ eclipse = eclipse-platform;
39+ jvmArgs = [ "-Xmx2048m" ];
40+ plugins = [
41+ plugins.color-theme
42+ (plugins.buildEclipsePlugin {
43+ name = "myplugin1-1.0";
44+ srcFeature = fetchurl {
45+ url = "http://…/features/myplugin1.jar";
46+ sha256 = "123…";
47+ };
48+ srcPlugin = fetchurl {
49+ url = "http://…/plugins/myplugin1.jar";
50+ sha256 = "123…";
51+ };
52+ });
53+ (plugins.buildEclipseUpdateSite {
54+ name = "myplugin2-1.0";
55+ src = fetchurl {
56+ stripRoot = false;
57+ url = "http://…/myplugin2.zip";
58+ sha256 = "123…";
59+ };
60+ });
61+ ];
62+ };
63+}
64+```
doc/builders/packages/elm.section.mdnew file+11
@@ -0,0 +1,11 @@
1+# Elm {#sec-elm}
2+
3+To start a development environment, run:
4+
5+```ShellSession
6+nix-shell -p elmPackages.elm elmPackages.elm-format
7+```
8+
9+To update the Elm compiler, see `nixpkgs/pkgs/development/compilers/elm/README.md`.
10+
11+To package Elm applications, [read about elm2nix](https://github.com/hercules-ci/elm2nix#elm2nix).
doc/builders/packages/emacs.section.mdnew file+119
@@ -0,0 +1,119 @@
1+# Emacs {#sec-emacs}
2+
3+## Configuring Emacs {#sec-emacs-config}
4+
5+The Emacs package comes with some extra helpers to make it easier to configure. `emacs.pkgs.withPackages` allows you to manage packages from ELPA. This means that you will not have to install that packages from within Emacs. For instance, if you wanted to use `company` `counsel`, `flycheck`, `ivy`, `magit`, `projectile`, and `use-package` you could use this as a `~/.config/nixpkgs/config.nix` override:
6+
7+```nix
8+{
9+ packageOverrides = pkgs: with pkgs; {
10+ myEmacs = emacs.pkgs.withPackages (epkgs: (with epkgs.melpaStablePackages; [
11+ company
12+ counsel
13+ flycheck
14+ ivy
15+ magit
16+ projectile
17+ use-package
18+ ]));
19+ }
20+}
21+```
22+
23+You can install it like any other packages via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
24+
25+```nix
26+{
27+ packageOverrides = pkgs: with pkgs; rec {
28+ myEmacsConfig = writeText "default.el" ''
29+ ;; initialize package
30+
31+ (require 'package)
32+ (package-initialize 'noactivate)
33+ (eval-when-compile
34+ (require 'use-package))
35+
36+ ;; load some packages
37+
38+ (use-package company
39+ :bind ("<C-tab>" . company-complete)
40+ :diminish company-mode
41+ :commands (company-mode global-company-mode)
42+ :defer 1
43+ :config
44+ (global-company-mode))
45+
46+ (use-package counsel
47+ :commands (counsel-descbinds)
48+ :bind (([remap execute-extended-command] . counsel-M-x)
49+ ("C-x C-f" . counsel-find-file)
50+ ("C-c g" . counsel-git)
51+ ("C-c j" . counsel-git-grep)
52+ ("C-c k" . counsel-ag)
53+ ("C-x l" . counsel-locate)
54+ ("M-y" . counsel-yank-pop)))
55+
56+ (use-package flycheck
57+ :defer 2
58+ :config (global-flycheck-mode))
59+
60+ (use-package ivy
61+ :defer 1
62+ :bind (("C-c C-r" . ivy-resume)
63+ ("C-x C-b" . ivy-switch-buffer)
64+ :map ivy-minibuffer-map
65+ ("C-j" . ivy-call))
66+ :diminish ivy-mode
67+ :commands ivy-mode
68+ :config
69+ (ivy-mode 1))
70+
71+ (use-package magit
72+ :defer
73+ :if (executable-find "git")
74+ :bind (("C-x g" . magit-status)
75+ ("C-x G" . magit-dispatch-popup))
76+ :init
77+ (setq magit-completing-read-function 'ivy-completing-read))
78+
79+ (use-package projectile
80+ :commands projectile-mode
81+ :bind-keymap ("C-c p" . projectile-command-map)
82+ :defer 5
83+ :config
84+ (projectile-global-mode))
85+ '';
86+
87+ myEmacs = emacs.pkgs.withPackages (epkgs: (with epkgs.melpaStablePackages; [
88+ (runCommand "default.el" {} ''
89+ mkdir -p $out/share/emacs/site-lisp
90+ cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
91+ '')
92+ company
93+ counsel
94+ flycheck
95+ ivy
96+ magit
97+ projectile
98+ use-package
99+ ]));
100+ };
101+}
102+```
103+
104+This provides a fairly full Emacs start file. It will load in addition to the user's personal config. You can always disable it by passing `-q` to the Emacs command.
105+
106+Sometimes `emacs.pkgs.withPackages` is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in `pkgs/top-level/emacs-packages.nix`). But you can't control these priorities when some package is installed as a dependency. You can override it on a per-package-basis, providing all the required dependencies manually, but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package, you can use `overrideScope'`.
107+
108+```nix
109+overrides = self: super: rec {
110+ haskell-mode = self.melpaPackages.haskell-mode;
111+ ...
112+};
113+((emacsPackagesFor emacs).overrideScope' overrides).withPackages
114+ (p: with p; [
115+ # here both these package will use haskell-mode of our own choice
116+ ghc-mod
117+ dante
118+ ])
119+```
doc/builders/packages/etc-files.section.mdnew file+18
@@ -0,0 +1,18 @@
1+# /etc files {#etc}
2+
3+Certain calls in glibc require access to runtime files found in `/etc` such as `/etc/protocols` or `/etc/services` -- [getprotobyname](https://linux.die.net/man/3/getprotobyname) is one such function.
4+
5+On non-NixOS distributions these files are typically provided by packages (i.e., [netbase](https://packages.debian.org/sid/netbase)) if not already pre-installed in your distribution. This can cause non-reproducibility for code if they rely on these files being present.
6+
7+If [iana-etc](https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.iana-etc.x86_64-linux) is part of your `buildInputs`, then it will set the environment variables `NIX_ETC_PROTOCOLS` and `NIX_ETC_SERVICES` to the corresponding files in the package through a setup hook.
8+
9+
10+```bash
11+> nix-shell -p iana-etc
12+
13+[nix-shell:~]$ env | grep NIX_ETC
14+NIX_ETC_SERVICES=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/services
15+NIX_ETC_PROTOCOLS=/nix/store/aj866hr8fad8flnggwdhrldm0g799ccz-iana-etc-20210225/etc/protocols
16+```
17+
18+Nixpkg's version of [glibc](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/glibc/default.nix) has been patched to check for the existence of these environment variables. If the environment variables are *not* set, then it will attempt to find the files at the default location within `/etc`.
doc/builders/packages/firefox.section.mdnew file+51
@@ -0,0 +1,51 @@
1+# Firefox {#sec-firefox}
2+
3+## Build wrapped Firefox with extensions and policies {#build-wrapped-firefox-with-extensions-and-policies}
4+
5+The `wrapFirefox` function allows to pass policies, preferences and extensions that are available to Firefox. With the help of `fetchFirefoxAddon` this allows to build a Firefox version that already comes with add-ons pre-installed:
6+
7+```nix
8+{
9+ # Nix firefox addons only work with the firefox-esr package.
10+ myFirefox = wrapFirefox firefox-esr-unwrapped {
11+ nixExtensions = [
12+ (fetchFirefoxAddon {
13+ name = "ublock"; # Has to be unique!
14+ url = "https://addons.mozilla.org/firefox/downloads/file/3679754/ublock_origin-1.31.0-an+fx.xpi";
15+ sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
16+ })
17+ ];
18+
19+ extraPolicies = {
20+ CaptivePortal = false;
21+ DisableFirefoxStudies = true;
22+ DisablePocket = true;
23+ DisableTelemetry = true;
24+ DisableFirefoxAccounts = true;
25+ FirefoxHome = {
26+ Pocket = false;
27+ Snippets = false;
28+ };
29+ UserMessaging = {
30+ ExtensionRecommendations = false;
31+ SkipOnboarding = true;
32+ };
33+ };
34+
35+ extraPrefs = ''
36+ // Show more ssl cert infos
37+ lockPref("security.identityblock.show_extended_validation", true);
38+ '';
39+ };
40+}
41+```
42+
43+If `nixExtensions != null`, then all manually installed add-ons will be uninstalled from your browser profile.
44+To view available enterprise policies, visit [enterprise policies](https://github.com/mozilla/policy-templates#enterprisepoliciesenabled)
45+or type into the Firefox URL bar: `about:policies#documentation`.
46+Nix installed add-ons do not have a valid signature, which is why signature verification is disabled. This does not compromise security because downloaded add-ons are checksummed and manual add-ons can't be installed. Also, make sure that the `name` field of `fetchFirefoxAddon` is unique. If you remove an add-on from the `nixExtensions` array, rebuild and start Firefox: the removed add-on will be completely removed with all of its settings.
47+
48+## Troubleshooting {#sec-firefox-troubleshooting}
49+If add-ons are marked as broken or the signature is invalid, make sure you have Firefox ESR installed. Normal Firefox does not provide the ability anymore to disable signature verification for add-ons thus nix add-ons get disabled by the normal Firefox binary.
50+
51+If add-ons do not appear installed despite being defined in your nix configuration file, reset the local add-on state of your Firefox profile by clicking `Help -> More Troubleshooting Information -> Refresh Firefox`. This can happen if you switch from manual add-on mode to nix add-on mode and then back to manual mode and then again to nix add-on mode.
doc/builders/packages/fish.section.mdnew file+50
@@ -0,0 +1,50 @@
1+# Fish {#sec-fish}
2+
3+Fish is a "smart and user-friendly command line shell" with support for plugins.
4+
5+
6+## Vendor Fish scripts {#sec-fish-vendor}
7+
8+Any package may ship its own Fish completions, configuration snippets, and
9+functions. Those should be installed to
10+`$out/share/fish/vendor_{completions,conf,functions}.d` respectively.
11+
12+When the `programs.fish.enable` and
13+`programs.fish.vendor.{completions,config,functions}.enable` options from the
14+NixOS Fish module are set to true, those paths are symlinked in the current
15+system environment and automatically loaded by Fish.
16+
17+
18+## Packaging Fish plugins {#sec-fish-plugins-pkg}
19+
20+While packages providing standalone executables belong to the top level,
21+packages which have the sole purpose of extending Fish belong to the
22+`fishPlugins` scope and should be registered in
23+`pkgs/shells/fish/plugins/default.nix`.
24+
25+The `buildFishPlugin` utility function can be used to automatically copy Fish
26+scripts from `$src/{completions,conf,conf.d,functions}` to the standard vendor
27+installation paths. It also sets up the test environment so that the optional
28+`checkPhase` is executed in a Fish shell with other already packaged plugins
29+and package-local Fish functions specified in `checkPlugins` and
30+`checkFunctionDirs` respectively.
31+
32+See `pkgs/shells/fish/plugins/pure.nix` for an example of Fish plugin package
33+using `buildFishPlugin` and running unit tests with the `fishtape` test runner.
34+
35+
36+## Fish wrapper {#sec-fish-wrapper}
37+
38+The `wrapFish` package is a wrapper around Fish which can be used to create
39+Fish shells initialized with some plugins as well as completions, configuration
40+snippets and functions sourced from the given paths. This provides a convenient
41+way to test Fish plugins and scripts without having to alter the environment.
42+
43+```nix
44+wrapFish {
45+ pluginPkgs = with fishPlugins; [ pure foreign-env ];
46+ completionDirs = [];
47+ functionDirs = [];
48+ confDirs = [ "/path/to/some/fish/init/dir/" ];
49+}
50+```
doc/builders/packages/fuse.section.mdnew file+45
@@ -0,0 +1,45 @@
1+# FUSE {#sec-fuse}
2+
3+Some packages rely on
4+[FUSE](https://www.kernel.org/doc/html/latest/filesystems/fuse.html) to provide
5+support for additional filesystems not supported by the kernel.
6+
7+In general, FUSE software are primarily developed for Linux but many of them can
8+also run on macOS. Nixpkgs supports FUSE packages on macOS, but it requires
9+[macFUSE](https://osxfuse.github.io) to be installed outside of Nix. macFUSE
10+currently isn't packaged in Nixpkgs mainly because it includes a kernel
11+extension, which isn't supported by Nix outside of NixOS.
12+
13+If a package fails to run on macOS with an error message similar to the
14+following, it's a likely sign that you need to have macFUSE installed.
15+
16+ dyld: Library not loaded: /usr/local/lib/libfuse.2.dylib
17+ Referenced from: /nix/store/w8bi72bssv0bnxhwfw3xr1mvn7myf37x-sshfs-fuse-2.10/bin/sshfs
18+ Reason: image not found
19+ [1] 92299 abort /nix/store/w8bi72bssv0bnxhwfw3xr1mvn7myf37x-sshfs-fuse-2.10/bin/sshfs
20+
21+Package maintainers may often encounter the following error when building FUSE
22+packages on macOS:
23+
24+ checking for fuse.h... no
25+ configure: error: No fuse.h found.
26+
27+This happens on autoconf based projects that use `AC_CHECK_HEADERS` or
28+`AC_CHECK_LIBS` to detect libfuse, and will occur even when the `fuse` package
29+is included in `buildInputs`. It happens because libfuse headers throw an error
30+on macOS if the `FUSE_USE_VERSION` macro is undefined. Many projects do define
31+`FUSE_USE_VERSION`, but only inside C source files. This results in the above
32+error at configure time because the configure script would attempt to compile
33+sample FUSE programs without defining `FUSE_USE_VERSION`.
34+
35+There are two possible solutions for this problem in Nixpkgs:
36+
37+1. Pass `FUSE_USE_VERSION` to the configure script by adding
38+ `CFLAGS=-DFUSE_USE_VERSION=25` in `configureFlags`. The actual value would
39+ have to match the definition used in the upstream source code.
40+2. Remove `AC_CHECK_HEADERS` / `AC_CHECK_LIBS` for libfuse.
41+
42+However, a better solution might be to fix the build script upstream to use
43+`PKG_CHECK_MODULES` instead. This approach wouldn't suffer from the problem that
44+`AC_CHECK_HEADERS`/`AC_CHECK_LIBS` has at the price of introducing a dependency
45+on pkg-config.
doc/builders/packages/ibus.section.mdnew file+38
@@ -0,0 +1,38 @@
1+# ibus-engines.typing-booster {#sec-ibus-typing-booster}
2+
3+This package is an ibus-based completion method to speed up typing.
4+
5+## Activating the engine {#sec-ibus-typing-booster-activate}
6+
7+IBus needs to be configured accordingly to activate `typing-booster`. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the [upstream docs](https://mike-fabian.github.io/ibus-typing-booster/documentation.html).
8+
9+On NixOS, you need to explicitly enable `ibus` with given engines before customizing your desktop to use `typing-booster`. This can be achieved using the `ibus` module:
10+
11+```nix
12+{ pkgs, ... }: {
13+ i18n.inputMethod = {
14+ enabled = "ibus";
15+ ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
16+ };
17+}
18+```
19+
20+## Using custom hunspell dictionaries {#sec-ibus-typing-booster-customize-hunspell}
21+
22+The IBus engine is based on `hunspell` to support completion in many languages. By default, the dictionaries `de-de`, `en-us`, `fr-moderne` `es-es`, `it-it`, `sv-se` and `sv-fi` are in use. To add another dictionary, the package can be overridden like this:
23+
24+```nix
25+ibus-engines.typing-booster.override { langs = [ "de-at" "en-gb" ]; }
26+```
27+
28+_Note: each language passed to `langs` must be an attribute name in `pkgs.hunspellDicts`._
29+
30+## Built-in emoji picker {#sec-ibus-typing-booster-emoji-picker}
31+
32+The `ibus-engines.typing-booster` package contains a program named `emoji-picker`. To display all emojis correctly, a special font such as `noto-fonts-emoji` is needed:
33+
34+On NixOS, it can be installed using the following expression:
35+
36+```nix
37+{ pkgs, ... }: { fonts.fonts = with pkgs; [ noto-fonts-emoji ]; }
38+```
doc/builders/packages/index.xmlnew file+29
@@ -0,0 +1,29 @@
1+<chapter xmlns="http://docbook.org/ns/docbook"
2+ xmlns:xi="http://www.w3.org/2001/XInclude"
3+ xml:id="chap-packages">
4+ <title>Packages</title>
5+ <para>
6+ This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org.
7+ </para>
8+ <xi:include href="citrix.section.xml" />
9+ <xi:include href="dlib.section.xml" />
10+ <xi:include href="eclipse.section.xml" />
11+ <xi:include href="elm.section.xml" />
12+ <xi:include href="emacs.section.xml" />
13+ <xi:include href="firefox.section.xml" />
14+ <xi:include href="fish.section.xml" />
15+ <xi:include href="fuse.section.xml" />
16+ <xi:include href="ibus.section.xml" />
17+ <xi:include href="kakoune.section.xml" />
18+ <xi:include href="linux.section.xml" />
19+ <xi:include href="locales.section.xml" />
20+ <xi:include href="etc-files.section.xml" />
21+ <xi:include href="nginx.section.xml" />
22+ <xi:include href="opengl.section.xml" />
23+ <xi:include href="shell-helpers.section.xml" />
24+ <xi:include href="steam.section.xml" />
25+ <xi:include href="cataclysm-dda.section.xml" />
26+ <xi:include href="urxvt.section.xml" />
27+ <xi:include href="weechat.section.xml" />
28+ <xi:include href="xorg.section.xml" />
29+</chapter>
doc/builders/packages/kakoune.section.mdnew file+9
@@ -0,0 +1,9 @@
1+# Kakoune {#sec-kakoune}
2+
3+Kakoune can be built to autoload plugins:
4+
5+```nix
6+(kakoune.override {
7+ plugins = with pkgs.kakounePlugins; [ parinfer-rust ];
8+})
9+```
doc/builders/packages/linux.section.mdnew file+41
@@ -0,0 +1,41 @@
1+# Linux kernel {#sec-linux-kernel}
2+
3+The Nix expressions to build the Linux kernel are in [`pkgs/os-specific/linux/kernel`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel).
4+
5+The function that builds the kernel has an argument `kernelPatches` which should be a list of `{name, patch, extraConfig}` attribute sets, where `name` is the name of the patch (which is included in the kernel’s `meta.description` attribute), `patch` is the patch itself (possibly compressed), and `extraConfig` (optional) is a string specifying extra options to be concatenated to the kernel configuration file (`.config`).
6+
7+The kernel derivation exports an attribute `features` specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the `iwlwifi` feature (i.e., has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external `iwlwifi` package:
8+
9+```nix
10+modulesTree = [kernel]
11+ ++ pkgs.lib.optional (!kernel.features ? iwlwifi) kernelPackages.iwlwifi
12+ ++ ...;
13+```
14+
15+How to add a new (major) version of the Linux kernel to Nixpkgs:
16+
17+1. Copy the old Nix expression (e.g., `linux-2.6.21.nix`) to the new one (e.g., `linux-2.6.22.nix`) and update it.
18+
19+2. Add the new kernel to the `kernels` attribute set in `linux-kernels.nix` (e.g., create an attribute `kernel_2_6_22`).
20+
21+3. Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (`i686`, `x86_64`, `uml`) do the following:
22+
23+ 1. Make a copy from the old config (e.g., `config-2.6.21-i686-smp`) to the new one (e.g., `config-2.6.22-i686-smp`).
24+
25+ 2. Copy the config file for this platform (e.g., `config-2.6.22-i686-smp`) to `.config` in the kernel source tree.
26+
27+ 3. Run `make oldconfig ARCH={i386,x86_64,um}` and answer all questions. (For the uml configuration, also add `SHELL=bash`.) Make sure to keep the configuration consistent between platforms (i.e., don’t enable some feature on `i686` and disable it on `x86_64`).
28+
29+ 4. If needed, you can also run `make menuconfig`:
30+
31+ ```ShellSession
32+ $ nix-env -f "<nixpkgs>" -iA ncurses
33+ $ export NIX_CFLAGS_LINK=-lncurses
34+ $ make menuconfig ARCH=arch
35+ ```
36+
37+ 5. Copy `.config` over the new config file (e.g., `config-2.6.22-i686-smp`).
38+
39+4. Test building the kernel: `nix-build -A linuxKernel.kernels.kernel_2_6_22`. If it compiles, ship it! For extra credit, try booting NixOS with it.
40+
41+5. It may be that the new kernel requires updating the external kernel modules and kernel-dependent packages listed in the `linuxPackagesFor` function in `linux-kernels.nix` (such as the NVIDIA drivers, AUFS, etc.). If the updated packages aren’t backwards compatible with older kernels, you may need to keep the older versions around.
doc/builders/packages/locales.section.mdnew file+5
@@ -0,0 +1,5 @@
1+# Locales {#locales}
2+
3+To allow simultaneous use of packages linked against different versions of `glibc` with different locale archive formats, Nixpkgs patches `glibc` to rely on `LOCALE_ARCHIVE` environment variable.
4+
5+On non-NixOS distributions, this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the `LOCALE_ARCHIVE` variable pointing to `${glibcLocales}/lib/locale/locale-archive`. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters `allLocales` and `locales` of the package.
doc/builders/packages/nginx.section.mdnew file+11
@@ -0,0 +1,11 @@
1+# Nginx {#sec-nginx}
2+
3+[Nginx](https://nginx.org) is a reverse proxy and lightweight webserver.
4+
5+## ETags on static files served from the Nix store {#sec-nginx-etag}
6+
7+HTTP has a couple of different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the [`Last-Modified`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the `Last-Modified` header. This doesn't give the desired behavior when the file is in the Nix store because all file timestamps are set to 0 (for reasons related to build reproducibility).
8+
9+Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the [`ETag`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) response header. The value of the `ETag` header specifies some identifier for the particular content that the server is sending (e.g., a hash). When a client makes a second request for the same resource, it sends that value back in an `If-None-Match` header. If the ETag value is unchanged, then the server does not need to resend the content.
10+
11+As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of `/nix/store`, the hash in the store path is used as the `ETag` header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
doc/builders/packages/opengl.section.mdnew file+15
@@ -0,0 +1,15 @@
1+# OpenGL {#sec-opengl}
2+
3+OpenGL support varies depending on which hardware is used and which drivers are available and loaded.
4+
5+Broadly, we support both GL vendors: Mesa and NVIDIA.
6+
7+## NixOS Desktop {#nixos-desktop}
8+
9+The NixOS desktop or other non-headless configurations are the primary target for OpenGL libraries and applications. The current solution for discovering which drivers are available is based on [libglvnd](https://gitlab.freedesktop.org/glvnd/libglvnd). `libglvnd` performs "vendor-neutral dispatch", trying a variety of techniques to find the system's GL implementation. In practice, this will be either via standard GLX for X11 users or EGL for Wayland users, and supporting either NVIDIA or Mesa extensions.
10+
11+## Nix on GNU/Linux {#nix-on-gnulinux}
12+
13+If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of `libglvnd` and `mesa.drivers` in `LD_LIBRARY_PATH`. For Mesa drivers, the Linux kernel version doesn't have to match nixpkgs.
14+
15+For proprietary video drivers, you might have luck with also adding the corresponding video driver package.
doc/builders/packages/shell-helpers.section.mdnew file+12
@@ -0,0 +1,12 @@
1+# Interactive shell helpers {#sec-shell-helpers}
2+
3+Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn't have a standard `share` directory location. This is why a bunch `PACKAGE-share` scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:
4+
5+- `fzf` : `fzf-share`
6+
7+E.g. `fzf` can then be used in the `.bashrc` like this:
8+
9+```bash
10+source "$(fzf-share)/completion.bash"
11+source "$(fzf-share)/key-bindings.bash"
12+```
doc/builders/packages/steam.section.mdnew file+63
@@ -0,0 +1,63 @@
1+# Steam {#sec-steam}
2+
3+## Steam in Nix {#sec-steam-nix}
4+
5+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`.
6+
7+Nix problems and constraints:
8+
9+- We don't have `/bin/bash` and many scripts point there. Same thing for `/usr/bin/python`.
10+- We don't have the dynamic loader in `/lib`.
11+- The `steam.sh` script in `$HOME` cannot be patched, as it is checked and rewritten by steam.
12+- The steam binary cannot be patched, it's also checked.
13+
14+The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented [here](http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html). 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.
15+
16+## How to play {#sec-steam-play}
17+
18+Use `programs.steam.enable = true;` if you want to add steam to `systemPackages` and also enable a few workarounds as well as Steam controller support or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pro Controller.
19+
20+## Troubleshooting {#sec-steam-troub}
21+
22+- **Steam fails to start. What do I do?**
23+
24+ Try to run
25+
26+ ```ShellSession
27+ strace steam
28+ ```
29+
30+ to see what is causing steam to fail.
31+
32+- **Using the FOSS Radeon or nouveau (nvidia) drivers**
33+
34+ - The `newStdcpp` parameter was removed since NixOS 17.09 and should not be needed anymore.
35+ - Steam ships statically linked with a version of `libcrypto` that conflicts with the one dynamically loaded by radeonsi_dri.so. If you get the error:
36+
37+ ```
38+ steam.sh: line 713: 7842 Segmentation fault (core dumped)
39+ ```
40+
41+ have a look at [this pull request](https://github.com/NixOS/nixpkgs/pull/20269).
42+
43+- **Java**
44+
45+ 1. There is no java in steam chrootenv by default. If you get a message like:
46+
47+ ```
48+ /home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found
49+ ```
50+
51+ you need to add:
52+
53+ ```nix
54+ steam.override { withJava = true; };
55+ ```
56+
57+## steam-run {#sec-steam-run}
58+
59+The FHS-compatible chroot used for Steam can also be used to run other Linux games that expect a FHS environment. To use it, install the `steam-run` package and run the game with:
60+
61+```
62+steam-run ./foo
63+```
doc/builders/packages/unfree.xmlnew file+13
@@ -0,0 +1,13 @@
1+<section xmlns="http://docbook.org/ns/docbook"
2+ xmlns:xlink="http://www.w3.org/1999/xlink"
3+ xml:id="unfree-software">
4+ <title>Unfree software</title>
5+
6+ <para>
7+ All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
8+ </para>
9+
10+ <para>
11+ Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
12+ </para>
13+</section>
doc/builders/packages/urxvt.section.mdnew file+71
@@ -0,0 +1,71 @@
1+# Urxvt {#sec-urxvt}
2+
3+Urxvt, also known as rxvt-unicode, is a highly customizable terminal emulator.
4+
5+## Configuring urxvt {#sec-urxvt-conf}
6+
7+In `nixpkgs`, urxvt is provided by the package `rxvt-unicode`. It can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, use an overlay or directly install an expression that overrides its configuration, such as:
8+
9+```nix
10+rxvt-unicode.override {
11+ configure = { availablePlugins, ... }: {
12+ plugins = with availablePlugins; [ perls resize-font vtwheel ];
13+ };
14+}
15+```
16+
17+If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically.
18+
19+In order to add plugins but also keep all default plugins installed, it is possible to use the following method:
20+
21+```nix
22+rxvt-unicode.override {
23+ configure = { availablePlugins, ... }: {
24+ plugins = (builtins.attrValues availablePlugins) ++ [ custom-plugin ];
25+ };
26+}
27+```
28+
29+To get a list of all the plugins available, open the Nix REPL and run
30+
31+```ShellSession
32+$ nix repl
33+:l <nixpkgs>
34+map (p: p.name) pkgs.rxvt-unicode.plugins
35+```
36+
37+Alternatively, if your shell is bash or zsh and have completion enabled, simply type `nixpkgs.rxvt-unicode.plugins.<tab>`.
38+
39+In addition to `plugins` the options `extraDeps` and `perlDeps` can be used to install extra packages. `extraDeps` can be used, for example, to provide `xsel` (a clipboard manager) to the clipboard plugin, without installing it globally:
40+
41+```nix
42+rxvt-unicode.override {
43+ configure = { availablePlugins, ... }: {
44+ pluginsDeps = [ xsel ];
45+ };
46+}
47+```
48+
49+`perlDeps` is a handy way to provide Perl packages to your custom plugins (in `$HOME/.urxvt/ext`). For example, if you need `AnyEvent` you can do:
50+
51+```nix
52+rxvt-unicode.override {
53+ configure = { availablePlugins, ... }: {
54+ perlDeps = with perlPackages; [ AnyEvent ];
55+ };
56+}
57+```
58+
59+## Packaging urxvt plugins {#sec-urxvt-pkg}
60+
61+Urxvt plugins resides in `pkgs/applications/misc/rxvt-unicode-plugins`. To add a new plugin, create an expression in a subdirectory and add the package to the set in `pkgs/applications/misc/rxvt-unicode-plugins/default.nix`.
62+
63+A plugin can be any kind of derivation, the only requirement is that it should always install perl scripts in `$out/lib/urxvt/perl`. Look for existing plugins for examples.
64+
65+If the plugin is itself a Perl package that needs to be imported from other plugins or scripts, add the following passthrough:
66+
67+```nix
68+passthru.perlPackages = [ "self" ];
69+```
70+
71+This will make the urxvt wrapper pick up the dependency and set up the Perl path accordingly.
doc/builders/packages/weechat.section.mdnew file+85
@@ -0,0 +1,85 @@
1+# WeeChat {#sec-weechat}
2+
3+WeeChat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration, such as:
4+
5+```nix
6+weechat.override {configure = {availablePlugins, ...}: {
7+ plugins = with availablePlugins; [ python perl ];
8+ }
9+}
10+```
11+
12+If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically.
13+
14+The plugins currently available are `python`, `perl`, `ruby`, `guile`, `tcl` and `lua`.
15+
16+The Python and Perl plugins allows the addition of extra libraries. For instance, the `inotify.py` script in `weechat-scripts` requires D-Bus or libnotify, and the `fish.py` script requires `pycrypto`. To use these scripts, use the plugin's `withPackages` attribute:
17+
18+```nix
19+weechat.override { configure = {availablePlugins, ...}: {
20+ plugins = with availablePlugins; [
21+ (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
22+ ];
23+ };
24+}
25+```
26+
27+In order to also keep all default plugins installed, it is possible to use the following method:
28+
29+```nix
30+weechat.override { configure = { availablePlugins, ... }: {
31+ plugins = builtins.attrValues (availablePlugins // {
32+ python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
33+ });
34+}; }
35+```
36+
37+WeeChat allows to set defaults on startup using the `--run-command`. The `configure` method can be used to pass commands to the program:
38+
39+```nix
40+weechat.override {
41+ configure = { availablePlugins, ... }: {
42+ init = ''
43+ /set foo bar
44+ /server add libera irc.libera.chat
45+ '';
46+ };
47+}
48+```
49+
50+Further values can be added to the list of commands when running `weechat --run-command "your-commands"`.
51+
52+Additionally, it's possible to specify scripts to be loaded when starting `weechat`. These will be loaded before the commands from `init`:
53+
54+```nix
55+weechat.override {
56+ configure = { availablePlugins, ... }: {
57+ scripts = with pkgs.weechatScripts; [
58+ weechat-xmpp weechat-matrix-bridge wee-slack
59+ ];
60+ init = ''
61+ /set plugins.var.python.jabber.key "val"
62+ '':
63+ };
64+}
65+```
66+
67+In `nixpkgs` there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a `passthru.scripts` attribute, which contains a list of all scripts inside the store path. Furthermore, all scripts have to live in `$out/share`. An exemplary derivation looks like this:
68+
69+```nix
70+{ stdenv, fetchurl }:
71+
72+stdenv.mkDerivation {
73+ name = "exemplary-weechat-script";
74+ src = fetchurl {
75+ url = "https://scripts.tld/your-scripts.tar.gz";
76+ sha256 = "...";
77+ };
78+ passthru.scripts = [ "foo.py" "bar.lua" ];
79+ installPhase = ''
80+ mkdir $out/share
81+ cp foo.py $out/share
82+ cp bar.lua $out/share
83+ '';
84+}
85+```
doc/builders/packages/xorg.section.mdnew file+34
@@ -0,0 +1,34 @@
1+# X.org {#sec-xorg}
2+
3+The Nix expressions for the X.org packages reside in `pkgs/servers/x11/xorg/default.nix`. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file `pkgs/servers/x11/xorg/overrides.nix`, in which you can override or add to the derivations produced by the generator.
4+
5+## Katamari Tarballs {#katamari-tarballs}
6+
7+X.org upstream releases used to include [katamari](https://en.wiktionary.org/wiki/%E3%81%8B%E3%81%9F%E3%81%BE%E3%82%8A) releases, which included a holistic recommended version for each tarball, up until 7.7. To create a list of tarballs in a katamari release:
8+
9+```ShellSession
10+export release="X11R7.7"
11+export url="mirror://xorg/$release/src/everything/"
12+cat $(PRINT_PATH=1 nix-prefetch-url $url | tail -n 1) \
13+ | perl -e 'while (<>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'url'}$2\n"; }; }' \
14+ | sort > "tarballs-$release.list"
15+```
16+
17+## Individual Tarballs {#individual-tarballs}
18+
19+The upstream release process for [X11R7.8](https://x.org/wiki/Releases/7.8/) does not include a planned katamari. Instead, each component of X.org is released as its own tarball. We maintain `pkgs/servers/x11/xorg/tarballs.list` as a list of tarballs for each individual package. This list includes X.org core libraries and protocol descriptions, extra newer X11 interface libraries, like `xorg.libxcb`, and classic utilities which are largely unused but still available if needed, like `xorg.imake`.
20+
21+## Generating Nix Expressions {#generating-nix-expressions}
22+
23+The generator is invoked as follows:
24+
25+```ShellSession
26+cd pkgs/servers/x11/xorg
27+<tarballs.list perl ./generate-expr-from-tarballs.pl
28+```
29+
30+For each of the tarballs in the `.list` files, the script downloads it, unpacks it, and searches its `configure.ac` and `*.pc.in` files for dependencies. This information is used to generate `default.nix`. The generator caches downloaded tarballs between runs. Pay close attention to the `NOT FOUND: $NAME` messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
31+
32+## Overriding the Generator {#overriding-the-generator}
33+
34+If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, `patches` or a `postInstall` hook), you should modify `pkgs/servers/x11/xorg/overrides.nix`.
doc/builders/special.xmlnew file+10
@@ -0,0 +1,10 @@
1+<chapter xmlns="http://docbook.org/ns/docbook"
2+ xmlns:xi="http://www.w3.org/2001/XInclude"
3+ xml:id="chap-special">
4+ <title>Special builders</title>
5+ <para>
6+ This chapter describes several special builders.
7+ </para>
8+ <xi:include href="special/fhs-environments.section.xml" />
9+ <xi:include href="special/mkshell.section.xml" />
10+</chapter>
doc/builders/special/fhs-environments.section.mdnew file+49
@@ -0,0 +1,49 @@
1+# buildFHSUserEnv {#sec-fhs-environments}
2+
3+`buildFHSUserEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
4+
5+- `name`
6+ Environment name.
7+- `targetPkgs`
8+ Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
9+- `multiPkgs`
10+ Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
11+- `extraBuildCommands`
12+ Additional commands to be executed for finalizing the directory structure.
13+- `extraBuildCommandsMulti`
14+ Like `extraBuildCommands`, but executed only on multilib architectures.
15+- `extraOutputsToInstall`
16+ Additional derivation outputs to be linked for both target and multi-architecture packages.
17+- `extraInstallCommands`
18+ Additional commands to be executed for finalizing the derivation with runner script.
19+- `runScript`
20+ A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to `bash`.
21+- `profile`
22+ Optional script for `/etc/profile` within the sandbox.
23+
24+One can create a simple environment using a `shell.nix` like that:
25+
26+```nix
27+{ pkgs ? import <nixpkgs> {} }:
28+
29+(pkgs.buildFHSUserEnv {
30+ name = "simple-x11-env";
31+ targetPkgs = pkgs: (with pkgs;
32+ [ udev
33+ alsa-lib
34+ ]) ++ (with pkgs.xorg;
35+ [ libX11
36+ libXcursor
37+ libXrandr
38+ ]);
39+ multiPkgs = pkgs: (with pkgs;
40+ [ udev
41+ alsa-lib
42+ ]);
43+ runScript = "bash";
44+}).env
45+```
46+
47+Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported.
48+
49+Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.
doc/builders/special/mkshell.section.mdnew file+37
@@ -0,0 +1,37 @@
1+# pkgs.mkShell {#sec-pkgs-mkShell}
2+
3+`pkgs.mkShell` is a specialized `stdenv.mkDerivation` that removes some
4+repetition when using it with `nix-shell` (or `nix develop`).
5+
6+## Usage {#sec-pkgs-mkShell-usage}
7+
8+Here is a common usage example:
9+
10+```nix
11+{ pkgs ? import <nixpkgs> {} }:
12+pkgs.mkShell {
13+ packages = [ pkgs.gnumake ];
14+
15+ inputsFrom = [ pkgs.hello pkgs.gnutar ];
16+
17+ shellHook = ''
18+ export DEBUG=1
19+ '';
20+}
21+```
22+
23+## Attributes
24+
25+* `name` (default: `nix-shell`). Set the name of the derivation.
26+* `packages` (default: `[]`). Add executable packages to the `nix-shell` environment.
27+* `inputsFrom` (default: `[]`). Add build dependencies of the listed derivations to the `nix-shell` environment.
28+* `shellHook` (default: `""`). Bash statements that are executed by `nix-shell`.
29+
30+... all the attributes of `stdenv.mkDerivation`.
31+
32+## Building the shell
33+
34+This derivation output will contain a text file that contains a reference to
35+all the build inputs. This is useful in CI where we want to make sure that
36+every derivation, and its dependencies, build properly. Or when creating a GC
37+root so that the build dependencies don't get garbage-collected.
doc/builders/testers.chapter.mdnew file+82
@@ -0,0 +1,82 @@
1+# Testers {#chap-testers}
2+This chapter describes several testing builders which are available in the <literal>testers</literal> namespace.
3+
4+## `testVersion` {#tester-testVersion}
5+
6+Checks the command output contains the specified version
7+
8+Although simplistic, this test assures that the main program
9+can run. While there's no substitute for a real test case,
10+it does catch dynamic linking errors and such. It also provides
11+some protection against accidentally building the wrong version,
12+for example when using an 'old' hash in a fixed-output derivation.
13+
14+Examples:
15+
16+```nix
17+passthru.tests.version = testVersion { package = hello; };
18+
19+passthru.tests.version = testVersion {
20+ package = seaweedfs;
21+ command = "weed version";
22+};
23+
24+passthru.tests.version = testVersion {
25+ package = key;
26+ command = "KeY --help";
27+ # Wrong '2.5' version in the code. Drop on next version.
28+ version = "2.5";
29+};
30+```
31+
32+## `testEqualDerivation` {#tester-testEqualDerivation}
33+
34+Checks that two packages produce the exact same build instructions.
35+
36+This can be used to make sure that a certain difference of configuration,
37+such as the presence of an overlay does not cause a cache miss.
38+
39+When the derivations are equal, the return value is an empty file.
40+Otherwise, the build log explains the difference via `nix-diff`.
41+
42+Example:
43+
44+```nix
45+testEqualDerivation
46+ "The hello package must stay the same when enabling checks."
47+ hello
48+ (hello.overrideAttrs(o: { doCheck = true; }))
49+```
50+
51+## `invalidateFetcherByDrvHash` {#tester-invalidateFetcherByDrvHash}
52+
53+Use the derivation hash to invalidate the output via name, for testing.
54+
55+Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation`
56+
57+Normally, fixed output derivations can and should be cached by their output
58+hash only, but for testing we want to re-fetch everytime the fetcher changes.
59+
60+Changes to the fetcher become apparent in the drvPath, which is a hash of
61+how to fetch, rather than a fixed store path.
62+By inserting this hash into the name, we can make sure to re-run the fetcher
63+every time the fetcher changes.
64+
65+This relies on the assumption that Nix isn't clever enough to reuse its
66+database of local store contents to optimize fetching.
67+
68+You might notice that the "salted" name derives from the normal invocation,
69+not the final derivation. `invalidateFetcherByDrvHash` has to invoke the fetcher
70+function twice: once to get a derivation hash, and again to produce the final
71+fixed output derivation.
72+
73+Example:
74+
75+```nix
76+tests.fetchgit = invalidateFetcherByDrvHash fetchgit {
77+ name = "nix-source";
78+ url = "https://github.com/NixOS/nix";
79+ rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
80+ sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
81+};
82+```
doc/builders/trivial-builders.chapter.mdnew file+223
@@ -0,0 +1,223 @@
1+# Trivial builders {#chap-trivial-builders}
2+
3+Nixpkgs provides a couple of functions that help with building derivations. The most important one, `stdenv.mkDerivation`, has already been documented above. The following functions wrap `stdenv.mkDerivation`, making it easier to use in certain cases.
4+
5+## `runCommand` {#trivial-builder-runCommand}
6+
7+This takes three arguments, `name`, `env`, and `buildCommand`. `name` is just the name that Nix will append to the store path in the same way that `stdenv.mkDerivation` uses its `name` attribute. `env` is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped `stdenv.mkDerivation`. `buildCommand` specifies the commands that will be run to create this derivation. Note that you will need to create `$out` for Nix to register the command as successful.
8+
9+An example of using `runCommand` is provided below.
10+
11+```nix
12+(import <nixpkgs> {}).runCommand "my-example" {} ''
13+ echo My example command is running
14+
15+ mkdir $out
16+
17+ echo I can write data to the Nix store > $out/message
18+
19+ echo I can also run basic commands like:
20+
21+ echo ls
22+ ls
23+
24+ echo whoami
25+ whoami
26+
27+ echo date
28+ date
29+''
30+```
31+
32+## `runCommandCC` {#trivial-builder-runCommandCC}
33+
34+This works just like `runCommand`. The only difference is that it also provides a C compiler in `buildCommand`'s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
35+
36+## `runCommandLocal` {#trivial-builder-runCommandLocal}
37+
38+Variant of `runCommand` that forces the derivation to be built locally, it is not substituted. This is intended for very cheap commands (<1s execution time). It saves on the network round-trip and can speed up a build.
39+
40+::: {.note}
41+This sets [`allowSubstitutes` to `false`](https://nixos.org/nix/manual/#adv-attr-allowSubstitutes), so only use `runCommandLocal` if you are certain the user will always have a builder for the `system` of the derivation. This should be true for most trivial use cases (e.g., just copying some files to a different location or adding symlinks) because there the `system` is usually the same as `builtins.currentSystem`.
42+:::
43+
44+## `writeTextFile`, `writeText`, `writeTextDir`, `writeScript`, `writeScriptBin` {#trivial-builder-writeText}
45+
46+These functions write `text` to the Nix store. This is useful for creating scripts from Nix expressions. `writeTextFile` takes an attribute set and expects two arguments, `name` and `text`. `name` corresponds to the name used in the Nix store path. `text` will be the contents of the file. You can also set `executable` to true to make this file have the executable bit set.
47+
48+Many more commands wrap `writeTextFile` including `writeText`, `writeTextDir`, `writeScript`, and `writeScriptBin`. These are convenience functions over `writeTextFile`.
49+
50+Here are a few examples:
51+```nix
52+# Writes my-file to /nix/store/<store path>
53+writeTextFile {
54+ name = "my-file";
55+ text = ''
56+ Contents of File
57+ '';
58+}
59+# See also the `writeText` helper function below.
60+
61+# Writes executable my-file to /nix/store/<store path>/bin/my-file
62+writeTextFile {
63+ name = "my-file";
64+ text = ''
65+ Contents of File
66+ '';
67+ executable = true;
68+ destination = "/bin/my-file";
69+}
70+# Writes contents of file to /nix/store/<store path>
71+writeText "my-file"
72+ ''
73+ Contents of File
74+ '';
75+# Writes contents of file to /nix/store/<store path>/share/my-file
76+writeTextDir "share/my-file"
77+ ''
78+ Contents of File
79+ '';
80+# Writes my-file to /nix/store/<store path> and makes executable
81+writeScript "my-file"
82+ ''
83+ Contents of File
84+ '';
85+# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
86+writeScriptBin "my-file"
87+ ''
88+ Contents of File
89+ '';
90+# Writes my-file to /nix/store/<store path> and makes executable.
91+writeShellScript "my-file"
92+ ''
93+ Contents of File
94+ '';
95+# Writes my-file to /nix/store/<store path>/bin/my-file and makes executable.
96+writeShellScriptBin "my-file"
97+ ''
98+ Contents of File
99+ '';
100+
101+```
102+
103+## `concatTextFile`, `concatText`, `concatScript` {#trivial-builder-concatText}
104+
105+These functions concatenate `files` to the Nix store in a single file. This is useful for configuration files structured in lines of text. `concatTextFile` takes an attribute set and expects two arguments, `name` and `files`. `name` corresponds to the name used in the Nix store path. `files` will be the files to be concatenated. You can also set `executable` to true to make this file have the executable bit set.
106+`concatText` and`concatScript` are simple wrappers over `concatTextFile`.
107+
108+Here are a few examples:
109+```nix
110+
111+# Writes my-file to /nix/store/<store path>
112+concatTextFile {
113+ name = "my-file";
114+ files = [ drv1 "${drv2}/path/to/file" ];
115+}
116+# See also the `concatText` helper function below.
117+
118+# Writes executable my-file to /nix/store/<store path>/bin/my-file
119+concatTextFile {
120+ name = "my-file";
121+ files = [ drv1 "${drv2}/path/to/file" ];
122+ executable = true;
123+ destination = "/bin/my-file";
124+}
125+# Writes contents of files to /nix/store/<store path>
126+concatText "my-file" [ file1 file2 ]
127+
128+# Writes contents of files to /nix/store/<store path>
129+concatScript "my-file" [ file1 file2 ]
130+```
131+
132+## `writeShellApplication` {#trivial-builder-writeShellApplication}
133+
134+This can be used to easily produce a shell script that has some dependencies (`runtimeInputs`). It automatically sets the `PATH` of the script to contain all of the listed inputs, sets some sanity shellopts (`errexit`, `nounset`, `pipefail`), and checks the resulting script with [`shellcheck`](https://github.com/koalaman/shellcheck).
135+
136+For example, look at the following code:
137+
138+```nix
139+writeShellApplication {
140+ name = "show-nixos-org";
141+
142+ runtimeInputs = [ curl w3m ];
143+
144+ text = ''
145+ curl -s 'https://nixos.org' | w3m -dump -T text/html
146+ '';
147+}
148+```
149+
150+Unlike with normal `writeShellScriptBin`, there is no need to manually write out `${curl}/bin/curl`, setting the PATH
151+was handled by `writeShellApplication`. Moreover, the script is being checked with `shellcheck` for more strict
152+validation.
153+
154+## `symlinkJoin` {#trivial-builder-symlinkJoin}
155+
156+This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, `name`, and `paths`. `name` is the name used in the Nix store path for the created derivation. `paths` is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
157+Here is an example:
158+```nix
159+# adds symlinks of hello and stack to current build and prints "links added"
160+symlinkJoin { name = "myexample"; paths = [ pkgs.hello pkgs.stack ]; postBuild = "echo links added"; }
161+```
162+This creates a derivation with a directory structure like the following:
163+```
164+/nix/store/sglsr5g079a5235hy29da3mq3hv8sjmm-myexample
165+|-- bin
166+| |-- hello -> /nix/store/qy93dp4a3rqyn2mz63fbxjg228hffwyw-hello-2.10/bin/hello
167+| `-- stack -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/bin/stack
168+`-- share
169+ |-- bash-completion
170+ | `-- completions
171+ | `-- stack -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/share/bash-completion/completions/stack
172+ |-- fish
173+ | `-- vendor_completions.d
174+ | `-- stack.fish -> /nix/store/6lzdpxshx78281vy056lbk553ijsdr44-stack-2.1.3.1/share/fish/vendor_completions.d/stack.fish
175+...
176+```
177+
178+## `writeReferencesToFile` {#trivial-builder-writeReferencesToFile}
179+
180+Writes the closure of transitive dependencies to a file.
181+
182+This produces the equivalent of `nix-store -q --requisites`.
183+
184+For example,
185+
186+```nix
187+writeReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
188+```
189+
190+produces an output path `/nix/store/<hash>-runtime-deps` containing
191+
192+```nix
193+/nix/store/<hash>-hello-2.10
194+/nix/store/<hash>-hi
195+/nix/store/<hash>-libidn2-2.3.0
196+/nix/store/<hash>-libunistring-0.9.10
197+/nix/store/<hash>-glibc-2.32-40
198+```
199+
200+You can see that this includes `hi`, the original input path,
201+`hello`, which is a direct reference, but also
202+the other paths that are indirectly required to run `hello`.
203+
204+## `writeDirectReferencesToFile` {#trivial-builder-writeDirectReferencesToFile}
205+
206+Writes the set of references to the output file, that is, their immediate dependencies.
207+
208+This produces the equivalent of `nix-store -q --references`.
209+
210+For example,
211+
212+```nix
213+writeDirectReferencesToFile (writeScriptBin "hi" ''${hello}/bin/hello'')
214+```
215+
216+produces an output path `/nix/store/<hash>-runtime-references` containing
217+
218+```nix
219+/nix/store/<hash>-hello-2.10
220+```
221+
222+but none of `hello`'s dependencies because those are not referenced directly
223+by `hi`'s output.
doc/coding-conventions.xmldeleted−948
@@ -1,948 +0,0 @@
1−<chapter xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="chap-conventions">
4− <title>Coding conventions</title>
5− <section xml:id="sec-syntax">
6− <title>Syntax</title>
7−
8− <itemizedlist>
9− <listitem>
10− <para>
11− Use 2 spaces of indentation per indentation level in Nix expressions, 4
12− spaces in shell scripts.
13− </para>
14− </listitem>
15− <listitem>
16− <para>
17− Do not use tab characters, i.e. configure your editor to use soft tabs.
18− For instance, use <literal>(setq-default indent-tabs-mode nil)</literal>
19− in Emacs. Everybody has different tab settings so it’s asking for
20− trouble.
21− </para>
22− </listitem>
23− <listitem>
24− <para>
25− Use <literal>lowerCamelCase</literal> for variable names, not
26− <literal>UpperCamelCase</literal>. Note, this rule does not apply to
27− package attribute names, which instead follow the rules in
28− <xref linkend="sec-package-naming"/>.
29− </para>
30− </listitem>
31− <listitem>
32− <para>
33− Function calls with attribute set arguments are written as
34−<programlisting>
35−foo {
36− arg = ...;
37−}
38−</programlisting>
39− not
40−<programlisting>
41−foo
42−{
43− arg = ...;
44−}
45−</programlisting>
46− Also fine is
47−<programlisting>
48−foo { arg = ...; }
49−</programlisting>
50− if it's a short call.
51− </para>
52− </listitem>
53− <listitem>
54− <para>
55− In attribute sets or lists that span multiple lines, the attribute names
56− or list elements should be aligned:
57−<programlisting>
58−# A long list.
59−list = [
60− elem1
61− elem2
62− elem3
63−];
64−
65−# A long attribute set.
66−attrs = {
67− attr1 = short_expr;
68− attr2 =
69− if true then big_expr else big_expr;
70−};
71−
72−# Combined
73−listOfAttrs = [
74− {
75− attr1 = 3;
76− attr2 = "fff";
77− }
78− {
79− attr1 = 5;
80− attr2 = "ggg";
81− }
82−];
83−</programlisting>
84− </para>
85− </listitem>
86− <listitem>
87− <para>
88− Short lists or attribute sets can be written on one line:
89−<programlisting>
90−# A short list.
91−list = [ elem1 elem2 elem3 ];
92−
93−# A short set.
94−attrs = { x = 1280; y = 1024; };
95−</programlisting>
96− </para>
97− </listitem>
98− <listitem>
99− <para>
100− Breaking in the middle of a function argument can give hard-to-read code,
101− like
102−<programlisting>
103−someFunction { x = 1280;
104− y = 1024; } otherArg
105− yetAnotherArg
106−</programlisting>
107− (especially if the argument is very large, spanning multiple lines).
108− </para>
109− <para>
110− Better:
111−<programlisting>
112−someFunction
113− { x = 1280; y = 1024; }
114− otherArg
115− yetAnotherArg
116−</programlisting>
117− or
118−<programlisting>
119−let res = { x = 1280; y = 1024; };
120−in someFunction res otherArg yetAnotherArg
121−</programlisting>
122− </para>
123− </listitem>
124− <listitem>
125− <para>
126− The bodies of functions, asserts, and withs are not indented to prevent a
127− lot of superfluous indentation levels, i.e.
128−<programlisting>
129−{ arg1, arg2 }:
130−assert system == "i686-linux";
131−stdenv.mkDerivation { ...
132−</programlisting>
133− not
134−<programlisting>
135−{ arg1, arg2 }:
136− assert system == "i686-linux";
137− stdenv.mkDerivation { ...
138−</programlisting>
139− </para>
140− </listitem>
141− <listitem>
142− <para>
143− Function formal arguments are written as:
144−<programlisting>
145−{ arg1, arg2, arg3 }:
146−</programlisting>
147− but if they don't fit on one line they're written as:
148−<programlisting>
149−{ arg1, arg2, arg3
150−, arg4, ...
151−, # Some comment...
152− argN
153−}:
154−</programlisting>
155− </para>
156− </listitem>
157− <listitem>
158− <para>
159− Functions should list their expected arguments as precisely as possible.
160− That is, write
161−<programlisting>
162−{ stdenv, fetchurl, perl }: <replaceable>...</replaceable>
163−</programlisting>
164− instead of
165−<programlisting>
166−args: with args; <replaceable>...</replaceable>
167−</programlisting>
168− or
169−<programlisting>
170−{ stdenv, fetchurl, perl, ... }: <replaceable>...</replaceable>
171−</programlisting>
172− </para>
173− <para>
174− For functions that are truly generic in the number of arguments (such as
175− wrappers around <varname>mkDerivation</varname>) that have some required
176− arguments, you should write them using an <literal>@</literal>-pattern:
177−<programlisting>
178−{ stdenv, doCoverageAnalysis ? false, ... } @ args:
179−
180−stdenv.mkDerivation (args // {
181− <replaceable>...</replaceable> if doCoverageAnalysis then "bla" else "" <replaceable>...</replaceable>
182−})
183−</programlisting>
184− instead of
185−<programlisting>
186−args:
187−
188−args.stdenv.mkDerivation (args // {
189− <replaceable>...</replaceable> if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" <replaceable>...</replaceable>
190−})
191−</programlisting>
192− </para>
193− </listitem>
194− </itemizedlist>
195− </section>
196− <section xml:id="sec-package-naming">
197− <title>Package naming</title>
198−
199− <para>
200− The key words
201− <emphasis>must</emphasis>,
202− <emphasis>must not</emphasis>,
203− <emphasis>required</emphasis>,
204− <emphasis>shall</emphasis>,
205− <emphasis>shall not</emphasis>,
206− <emphasis>should</emphasis>,
207− <emphasis>should not</emphasis>,
208− <emphasis>recommended</emphasis>,
209− <emphasis>may</emphasis>,
210− and <emphasis>optional</emphasis> in this section
211− are to be interpreted as described in
212− <link xlink:href="https://tools.ietf.org/html/rfc2119">RFC 2119</link>.
213− Only <emphasis>emphasized</emphasis> words are to be interpreted in this way.
214− </para>
215−
216− <para>
217− In Nixpkgs, there are generally three different names associated with a
218− package:
219− <itemizedlist>
220− <listitem>
221− <para>
222− The <varname>name</varname> attribute of the derivation (excluding the
223− version part). This is what most users see, in particular when using
224− <command>nix-env</command>.
225− </para>
226− </listitem>
227− <listitem>
228− <para>
229− The variable name used for the instantiated package in
230− <filename>all-packages.nix</filename>, and when passing it as a
231− dependency to other functions. Typically this is called the
232− <emphasis>package attribute name</emphasis>. This is what Nix expression
233− authors see. It can also be used when installing using <command>nix-env
234− -iA</command>.
235− </para>
236− </listitem>
237− <listitem>
238− <para>
239− The filename for (the directory containing) the Nix expression.
240− </para>
241− </listitem>
242− </itemizedlist>
243− Most of the time, these are the same. For instance, the package
244− <literal>e2fsprogs</literal> has a <varname>name</varname> attribute
245− <literal>"e2fsprogs-<replaceable>version</replaceable>"</literal>, is bound
246− to the variable name <varname>e2fsprogs</varname> in
247− <filename>all-packages.nix</filename>, and the Nix expression is in
248− <filename>pkgs/os-specific/linux/e2fsprogs/default.nix</filename>.
249− </para>
250−
251− <para>
252− There are a few naming guidelines:
253− <itemizedlist>
254− <listitem>
255− <para>
256− The <literal>name</literal> attribute <emphasis>should</emphasis>
257− be identical to the upstream package name.
258− </para>
259− </listitem>
260− <listitem>
261− <para>
262− The <literal>name</literal> attribute <emphasis>must not</emphasis>
263− contain uppercase letters — e.g., <literal>"mplayer-1.0rc2"</literal>
264− instead of <literal>"MPlayer-1.0rc2"</literal>.
265− </para>
266− </listitem>
267− <listitem>
268− <para>
269− The version part of the <literal>name</literal> attribute
270− <emphasis>must</emphasis> start with a digit (following a dash) — e.g.,
271− <literal>"hello-0.3.1rc2"</literal>.
272− </para>
273− </listitem>
274− <listitem>
275− <para>
276− If a package is not a release but a commit from a repository, then the
277− version part of the name <emphasis>must</emphasis> be the date of that
278− (fetched) commit. The date <emphasis>must</emphasis> be in <literal>"YYYY-MM-DD"</literal>
279− format. Also append <literal>"unstable"</literal> to the name - e.g.,
280− <literal>"pkgname-unstable-2014-09-23"</literal>.
281− </para>
282− </listitem>
283− <listitem>
284− <para>
285− Dashes in the package name <emphasis>should</emphasis> be preserved in new variable names,
286− rather than converted to underscores or camel cased — e.g.,
287− <varname>http-parser</varname> instead of <varname>http_parser</varname>
288− or <varname>httpParser</varname>. The hyphenated style is preferred in
289− all three package names.
290− </para>
291− </listitem>
292− <listitem>
293− <para>
294− If there are multiple versions of a package, this <emphasis>should</emphasis> be reflected in
295− the variable names in <filename>all-packages.nix</filename>, e.g.
296− <varname>json-c-0-9</varname> and <varname>json-c-0-11</varname>. If
297− there is an obvious “default” version, make an attribute like
298− <literal>json-c = json-c-0-9;</literal>. See also
299− <xref linkend="sec-versioning" />
300− </para>
301− </listitem>
302− </itemizedlist>
303− </para>
304− </section>
305− <section xml:id="sec-organisation">
306− <title>File naming and organisation</title>
307−
308− <para>
309− Names of files and directories should be in lowercase, with dashes between
310− words — not in camel case. For instance, it should be
311− <filename>all-packages.nix</filename>, not
312− <filename>allPackages.nix</filename> or
313− <filename>AllPackages.nix</filename>.
314− </para>
315−
316− <section xml:id="sec-hierarchy">
317− <title>Hierarchy</title>
318−
319− <para>
320− Each package should be stored in its own directory somewhere in the
321− <filename>pkgs/</filename> tree, i.e. in
322− <filename>pkgs/<replaceable>category</replaceable>/<replaceable>subcategory</replaceable>/<replaceable>...</replaceable>/<replaceable>pkgname</replaceable></filename>.
323− Below are some rules for picking the right category for a package. Many
324− packages fall under several categories; what matters is the
325− <emphasis>primary</emphasis> purpose of a package. For example, the
326− <literal>libxml2</literal> package builds both a library and some tools;
327− but it’s a library foremost, so it goes under
328− <filename>pkgs/development/libraries</filename>.
329− </para>
330−
331− <para>
332− When in doubt, consider refactoring the <filename>pkgs/</filename> tree,
333− e.g. creating new categories or splitting up an existing category.
334− </para>
335−
336− <variablelist>
337− <varlistentry>
338− <term>
339− If it’s used to support <emphasis>software development</emphasis>:
340− </term>
341− <listitem>
342− <variablelist>
343− <varlistentry>
344− <term>
345− If it’s a <emphasis>library</emphasis> used by other packages:
346− </term>
347− <listitem>
348− <para>
349− <filename>development/libraries</filename> (e.g.
350− <filename>libxml2</filename>)
351− </para>
352− </listitem>
353− </varlistentry>
354− <varlistentry>
355− <term>
356− If it’s a <emphasis>compiler</emphasis>:
357− </term>
358− <listitem>
359− <para>
360− <filename>development/compilers</filename> (e.g.
361− <filename>gcc</filename>)
362− </para>
363− </listitem>
364− </varlistentry>
365− <varlistentry>
366− <term>
367− If it’s an <emphasis>interpreter</emphasis>:
368− </term>
369− <listitem>
370− <para>
371− <filename>development/interpreters</filename> (e.g.
372− <filename>guile</filename>)
373− </para>
374− </listitem>
375− </varlistentry>
376− <varlistentry>
377− <term>
378− If it’s a (set of) development <emphasis>tool(s)</emphasis>:
379− </term>
380− <listitem>
381− <variablelist>
382− <varlistentry>
383− <term>
384− If it’s a <emphasis>parser generator</emphasis> (including lexers):
385− </term>
386− <listitem>
387− <para>
388− <filename>development/tools/parsing</filename> (e.g.
389− <filename>bison</filename>, <filename>flex</filename>)
390− </para>
391− </listitem>
392− </varlistentry>
393− <varlistentry>
394− <term>
395− If it’s a <emphasis>build manager</emphasis>:
396− </term>
397− <listitem>
398− <para>
399− <filename>development/tools/build-managers</filename> (e.g.
400− <filename>gnumake</filename>)
401− </para>
402− </listitem>
403− </varlistentry>
404− <varlistentry>
405− <term>
406− Else:
407− </term>
408− <listitem>
409− <para>
410− <filename>development/tools/misc</filename> (e.g.
411− <filename>binutils</filename>)
412− </para>
413− </listitem>
414− </varlistentry>
415− </variablelist>
416− </listitem>
417− </varlistentry>
418− <varlistentry>
419− <term>
420− Else:
421− </term>
422− <listitem>
423− <para>
424− <filename>development/misc</filename>
425− </para>
426− </listitem>
427− </varlistentry>
428− </variablelist>
429− </listitem>
430− </varlistentry>
431− <varlistentry>
432− <term>
433− If it’s a (set of) <emphasis>tool(s)</emphasis>:
434− </term>
435− <listitem>
436− <para>
437− (A tool is a relatively small program, especially one intended to be
438− used non-interactively.)
439− </para>
440− <variablelist>
441− <varlistentry>
442− <term>
443− If it’s for <emphasis>networking</emphasis>:
444− </term>
445− <listitem>
446− <para>
447− <filename>tools/networking</filename> (e.g.
448− <filename>wget</filename>)
449− </para>
450− </listitem>
451− </varlistentry>
452− <varlistentry>
453− <term>
454− If it’s for <emphasis>text processing</emphasis>:
455− </term>
456− <listitem>
457− <para>
458− <filename>tools/text</filename> (e.g. <filename>diffutils</filename>)
459− </para>
460− </listitem>
461− </varlistentry>
462− <varlistentry>
463− <term>
464− If it’s a <emphasis>system utility</emphasis>, i.e., something related or essential to the operation of a system:
465− </term>
466− <listitem>
467− <para>
468− <filename>tools/system</filename> (e.g. <filename>cron</filename>)
469− </para>
470− </listitem>
471− </varlistentry>
472− <varlistentry>
473− <term>
474− If it’s an <emphasis>archiver</emphasis> (which may include a compression function):
475− </term>
476− <listitem>
477− <para>
478− <filename>tools/archivers</filename> (e.g. <filename>zip</filename>,
479− <filename>tar</filename>)
480− </para>
481− </listitem>
482− </varlistentry>
483− <varlistentry>
484− <term>
485− If it’s a <emphasis>compression</emphasis> program:
486− </term>
487− <listitem>
488− <para>
489− <filename>tools/compression</filename> (e.g.
490− <filename>gzip</filename>, <filename>bzip2</filename>)
491− </para>
492− </listitem>
493− </varlistentry>
494− <varlistentry>
495− <term>
496− If it’s a <emphasis>security</emphasis>-related program:
497− </term>
498− <listitem>
499− <para>
500− <filename>tools/security</filename> (e.g. <filename>nmap</filename>,
501− <filename>gnupg</filename>)
502− </para>
503− </listitem>
504− </varlistentry>
505− <varlistentry>
506− <term>
507− Else:
508− </term>
509− <listitem>
510− <para>
511− <filename>tools/misc</filename>
512− </para>
513− </listitem>
514− </varlistentry>
515− </variablelist>
516− </listitem>
517− </varlistentry>
518− <varlistentry>
519− <term>
520− If it’s a <emphasis>shell</emphasis>:
521− </term>
522− <listitem>
523− <para>
524− <filename>shells</filename> (e.g. <filename>bash</filename>)
525− </para>
526− </listitem>
527− </varlistentry>
528− <varlistentry>
529− <term>
530− If it’s a <emphasis>server</emphasis>:
531− </term>
532− <listitem>
533− <variablelist>
534− <varlistentry>
535− <term>
536− If it’s a web server:
537− </term>
538− <listitem>
539− <para>
540− <filename>servers/http</filename> (e.g.
541− <filename>apache-httpd</filename>)
542− </para>
543− </listitem>
544− </varlistentry>
545− <varlistentry>
546− <term>
547− If it’s an implementation of the X Windowing System:
548− </term>
549− <listitem>
550− <para>
551− <filename>servers/x11</filename> (e.g. <filename>xorg</filename> —
552− this includes the client libraries and programs)
553− </para>
554− </listitem>
555− </varlistentry>
556− <varlistentry>
557− <term>
558− Else:
559− </term>
560− <listitem>
561− <para>
562− <filename>servers/misc</filename>
563− </para>
564− </listitem>
565− </varlistentry>
566− </variablelist>
567− </listitem>
568− </varlistentry>
569− <varlistentry>
570− <term>
571− If it’s a <emphasis>desktop environment</emphasis>:
572− </term>
573− <listitem>
574− <para>
575− <filename>desktops</filename> (e.g. <filename>kde</filename>,
576− <filename>gnome</filename>, <filename>enlightenment</filename>)
577− </para>
578− </listitem>
579− </varlistentry>
580− <varlistentry>
581− <term>
582− If it’s a <emphasis>window manager</emphasis>:
583− </term>
584− <listitem>
585− <para>
586− <filename>applications/window-managers</filename> (e.g.
587− <filename>awesome</filename>, <filename>stumpwm</filename>)
588− </para>
589− </listitem>
590− </varlistentry>
591− <varlistentry>
592− <term>
593− If it’s an <emphasis>application</emphasis>:
594− </term>
595− <listitem>
596− <para>
597− A (typically large) program with a distinct user interface, primarily
598− used interactively.
599− </para>
600− <variablelist>
601− <varlistentry>
602− <term>
603− If it’s a <emphasis>version management system</emphasis>:
604− </term>
605− <listitem>
606− <para>
607− <filename>applications/version-management</filename> (e.g.
608− <filename>subversion</filename>)
609− </para>
610− </listitem>
611− </varlistentry>
612− <varlistentry>
613− <term>
614− If it’s for <emphasis>video playback / editing</emphasis>:
615− </term>
616− <listitem>
617− <para>
618− <filename>applications/video</filename> (e.g.
619− <filename>vlc</filename>)
620− </para>
621− </listitem>
622− </varlistentry>
623− <varlistentry>
624− <term>
625− If it’s for <emphasis>graphics viewing / editing</emphasis>:
626− </term>
627− <listitem>
628− <para>
629− <filename>applications/graphics</filename> (e.g.
630− <filename>gimp</filename>)
631− </para>
632− </listitem>
633− </varlistentry>
634− <varlistentry>
635− <term>
636− If it’s for <emphasis>networking</emphasis>:
637− </term>
638− <listitem>
639− <variablelist>
640− <varlistentry>
641− <term>
642− If it’s a <emphasis>mailreader</emphasis>:
643− </term>
644− <listitem>
645− <para>
646− <filename>applications/networking/mailreaders</filename> (e.g.
647− <filename>thunderbird</filename>)
648− </para>
649− </listitem>
650− </varlistentry>
651− <varlistentry>
652− <term>
653− If it’s a <emphasis>newsreader</emphasis>:
654− </term>
655− <listitem>
656− <para>
657− <filename>applications/networking/newsreaders</filename> (e.g.
658− <filename>pan</filename>)
659− </para>
660− </listitem>
661− </varlistentry>
662− <varlistentry>
663− <term>
664− If it’s a <emphasis>web browser</emphasis>:
665− </term>
666− <listitem>
667− <para>
668− <filename>applications/networking/browsers</filename> (e.g.
669− <filename>firefox</filename>)
670− </para>
671− </listitem>
672− </varlistentry>
673− <varlistentry>
674− <term>
675− Else:
676− </term>
677− <listitem>
678− <para>
679− <filename>applications/networking/misc</filename>
680− </para>
681− </listitem>
682− </varlistentry>
683− </variablelist>
684− </listitem>
685− </varlistentry>
686− <varlistentry>
687− <term>
688− Else:
689− </term>
690− <listitem>
691− <para>
692− <filename>applications/misc</filename>
693− </para>
694− </listitem>
695− </varlistentry>
696− </variablelist>
697− </listitem>
698− </varlistentry>
699− <varlistentry>
700− <term>
701− If it’s <emphasis>data</emphasis> (i.e., does not have a straight-forward executable semantics):
702− </term>
703− <listitem>
704− <variablelist>
705− <varlistentry>
706− <term>
707− If it’s a <emphasis>font</emphasis>:
708− </term>
709− <listitem>
710− <para>
711− <filename>data/fonts</filename>
712− </para>
713− </listitem>
714− </varlistentry>
715− <varlistentry>
716− <term>
717− If it’s related to <emphasis>SGML/XML processing</emphasis>:
718− </term>
719− <listitem>
720− <variablelist>
721− <varlistentry>
722− <term>
723− If it’s an <emphasis>XML DTD</emphasis>:
724− </term>
725− <listitem>
726− <para>
727− <filename>data/sgml+xml/schemas/xml-dtd</filename> (e.g.
728− <filename>docbook</filename>)
729− </para>
730− </listitem>
731− </varlistentry>
732− <varlistentry>
733− <term>
734− If it’s an <emphasis>XSLT stylesheet</emphasis>:
735− </term>
736− <listitem>
737− <para>
738− (Okay, these are executable...)
739− </para>
740− <para>
741− <filename>data/sgml+xml/stylesheets/xslt</filename> (e.g.
742− <filename>docbook-xsl</filename>)
743− </para>
744− </listitem>
745− </varlistentry>
746− </variablelist>
747− </listitem>
748− </varlistentry>
749− </variablelist>
750− </listitem>
751− </varlistentry>
752− <varlistentry>
753− <term>
754− If it’s a <emphasis>game</emphasis>:
755− </term>
756− <listitem>
757− <para>
758− <filename>games</filename>
759− </para>
760− </listitem>
761− </varlistentry>
762− <varlistentry>
763− <term>
764− Else:
765− </term>
766− <listitem>
767− <para>
768− <filename>misc</filename>
769− </para>
770− </listitem>
771− </varlistentry>
772− </variablelist>
773− </section>
774−
775− <section xml:id="sec-versioning">
776− <title>Versioning</title>
777−
778− <para>
779− Because every version of a package in Nixpkgs creates a potential
780− maintenance burden, old versions of a package should not be kept unless
781− there is a good reason to do so. For instance, Nixpkgs contains several
782− versions of GCC because other packages don’t build with the latest
783− version of GCC. Other examples are having both the latest stable and latest
784− pre-release version of a package, or to keep several major releases of an
785− application that differ significantly in functionality.
786− </para>
787−
788− <para>
789− If there is only one version of a package, its Nix expression should be
790− named <filename>e2fsprogs/default.nix</filename>. If there are multiple
791− versions, this should be reflected in the filename, e.g.
792− <filename>e2fsprogs/1.41.8.nix</filename> and
793− <filename>e2fsprogs/1.41.9.nix</filename>. The version in the filename
794− should leave out unnecessary detail. For instance, if we keep the latest
795− Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named
796− <filename>firefox/2.0.nix</filename> and
797− <filename>firefox/3.5.nix</filename>, respectively (which, at a given
798− point, might contain versions <literal>2.0.0.20</literal> and
799− <literal>3.5.4</literal>). If a version requires many auxiliary files, you
800− can use a subdirectory for each version, e.g.
801− <filename>firefox/2.0/default.nix</filename> and
802− <filename>firefox/3.5/default.nix</filename>.
803− </para>
804−
805− <para>
806− All versions of a package <emphasis>must</emphasis> be included in
807− <filename>all-packages.nix</filename> to make sure that they evaluate
808− correctly.
809− </para>
810− </section>
811− </section>
812− <section xml:id="sec-sources">
813− <title>Fetching Sources</title>
814−
815− <para>
816− There are multiple ways to fetch a package source in nixpkgs. The general
817− guideline is that you should package sources with a high degree of
818− availability. Right now there is only one fetcher which has mirroring
819− support and that is <literal>fetchurl</literal>. Note that you should also
820− prefer protocols which have a corresponding proxy environment variable.
821− </para>
822−
823− <para>
824− You can find many source fetch helpers in
825− <literal>pkgs/build-support/fetch*</literal>.
826− </para>
827−
828− <para>
829− In the file <literal>pkgs/top-level/all-packages.nix</literal> you can find
830− fetch helpers, these have names on the form <literal>fetchFrom*</literal>.
831− The intention of these are to provide snapshot fetches but using the same
832− api as some of the version controlled fetchers from
833− <literal>pkgs/build-support/</literal>. As an example going from bad to
834− good:
835− <itemizedlist>
836− <listitem>
837− <para>
838− Bad: Uses <literal>git://</literal> which won't be proxied.
839−<programlisting>
840−src = fetchgit {
841− url = "git://github.com/NixOS/nix.git";
842− rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
843− sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
844−}
845−</programlisting>
846− </para>
847− </listitem>
848− <listitem>
849− <para>
850− Better: This is ok, but an archive fetch will still be faster.
851−<programlisting>
852−src = fetchgit {
853− url = "https://github.com/NixOS/nix.git";
854− rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
855− sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
856−}
857−</programlisting>
858− </para>
859− </listitem>
860− <listitem>
861− <para>
862− Best: Fetches a snapshot archive and you get the rev you want.
863−<programlisting>
864−src = fetchFromGitHub {
865− owner = "NixOS";
866− repo = "nix";
867− rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
868− sha256 = "1i2yxndxb6yc9l6c99pypbd92lfq5aac4klq7y2v93c9qvx2cgpc";
869−}
870−</programlisting>
871− Find the value to put as <literal>sha256</literal> by running
872− <literal>nix run -f '<nixpkgs>' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix</literal>
873− or <literal>nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz</literal>.
874− </para>
875− </listitem>
876− </itemizedlist>
877− </para>
878− </section>
879− <section xml:id="sec-patches">
880− <title>Patches</title>
881−
882− <para>
883− Patches available online should be retrieved using
884− <literal>fetchpatch</literal>.
885− </para>
886−
887− <para>
888−<programlisting>
889−patches = [
890− (fetchpatch {
891− name = "fix-check-for-using-shared-freetype-lib.patch";
892− url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285";
893− sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr";
894− })
895−];
896−</programlisting>
897− </para>
898−
899− <para>
900− Otherwise, you can add a <literal>.patch</literal> file to the
901− <literal>nixpkgs</literal> repository. In the interest of keeping our
902− maintenance burden to a minimum, only patches that are unique to
903− <literal>nixpkgs</literal> should be added in this way.
904− </para>
905−
906− <para>
907−<programlisting>
908−patches = [ ./0001-changes.patch ];
909−</programlisting>
910− </para>
911−
912− <para>
913− If you do need to do create this sort of patch file, one way to do so is
914− with git:
915− <orderedlist>
916− <listitem>
917− <para>
918− Move to the root directory of the source code you're patching.
919−<screen>
920−$ cd the/program/source</screen>
921− </para>
922− </listitem>
923− <listitem>
924− <para>
925− If a git repository is not already present, create one and stage all of
926− the source files.
927−<screen>
928−$ git init
929−$ git add .</screen>
930− </para>
931− </listitem>
932− <listitem>
933− <para>
934− Edit some files to make whatever changes need to be included in the
935− patch.
936− </para>
937− </listitem>
938− <listitem>
939− <para>
940− Use git to create a diff, and pipe the output to a patch file:
941−<screen>
942−$ git diff > nixpkgs/pkgs/the/package/0001-changes.patch</screen>
943− </para>
944− </listitem>
945− </orderedlist>
946− </para>
947− </section>
948−</chapter>
doc/configuration.xmldeleted−510
@@ -1,510 +0,0 @@
1−<chapter xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="chap-packageconfig">
4− <title>Global configuration</title>
5− <para>
6− Nix comes with certain defaults about what packages can and cannot be
7− installed, based on a package's metadata. By default, Nix will prevent
8− installation if any of the following criteria are true:
9− </para>
10− <itemizedlist>
11− <listitem>
12− <para>
13− The package is thought to be broken, and has had its
14− <literal>meta.broken</literal> set to <literal>true</literal>.
15− </para>
16− </listitem>
17− <listitem>
18− <para>
19− The package isn't intended to run on the given system, as none of its
20− <literal>meta.platforms</literal> match the given system.
21− </para>
22− </listitem>
23− <listitem>
24− <para>
25− The package's <literal>meta.license</literal> is set to a license which is
26− considered to be unfree.
27− </para>
28− </listitem>
29− <listitem>
30− <para>
31− The package has known security vulnerabilities but has not or can not be
32− updated for some reason, and a list of issues has been entered in to the
33− package's <literal>meta.knownVulnerabilities</literal>.
34− </para>
35− </listitem>
36− </itemizedlist>
37− <para>
38− Note that all this is checked during evaluation already, and the check
39− includes any package that is evaluated. In particular, all build-time
40− dependencies are checked. <literal>nix-env -qa</literal> will (attempt to)
41− hide any packages that would be refused.
42− </para>
43− <para>
44− Each of these criteria can be altered in the nixpkgs configuration.
45− </para>
46− <para>
47− The nixpkgs configuration for a NixOS system is set in the
48− <literal>configuration.nix</literal>, as in the following example:
49−<programlisting>
50−{
51− nixpkgs.config = {
52− allowUnfree = true;
53− };
54−}
55−</programlisting>
56− However, this does not allow unfree software for individual users. Their
57− configurations are managed separately.
58− </para>
59− <para>
60− A user's of nixpkgs configuration is stored in a user-specific configuration
61− file located at <filename>~/.config/nixpkgs/config.nix</filename>. For
62− example:
63−<programlisting>
64−{
65− allowUnfree = true;
66−}
67−</programlisting>
68− </para>
69− <para>
70− Note that we are not able to test or build unfree software on Hydra due to
71− policy. Most unfree licenses prohibit us from either executing or
72− distributing the software.
73− </para>
74− <section xml:id="sec-allow-broken">
75− <title>Installing broken packages</title>
76−
77− <para>
78− There are two ways to try compiling a package which has been marked as
79− broken.
80− </para>
81−
82− <itemizedlist>
83− <listitem>
84− <para>
85− For allowing the build of a broken package once, you can use an
86− environment variable for a single invocation of the nix tools:
87−<programlisting>$ export NIXPKGS_ALLOW_BROKEN=1</programlisting>
88− </para>
89− </listitem>
90− <listitem>
91− <para>
92− For permanently allowing broken packages to be built, you may add
93− <literal>allowBroken = true;</literal> to your user's configuration file,
94− like this:
95−<programlisting>
96−{
97− allowBroken = true;
98−}
99−</programlisting>
100− </para>
101− </listitem>
102− </itemizedlist>
103− </section>
104− <section xml:id="sec-allow-unsupported-system">
105− <title>Installing packages on unsupported systems</title>
106−
107− <para>
108− There are also two ways to try compiling a package which has been marked as
109− unsuported for the given system.
110− </para>
111−
112− <itemizedlist>
113− <listitem>
114− <para>
115− For allowing the build of a broken package once, you can use an
116− environment variable for a single invocation of the nix tools:
117−<programlisting>$ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1</programlisting>
118− </para>
119− </listitem>
120− <listitem>
121− <para>
122− For permanently allowing broken packages to be built, you may add
123− <literal>allowUnsupportedSystem = true;</literal> to your user's
124− configuration file, like this:
125−<programlisting>
126−{
127− allowUnsupportedSystem = true;
128−}
129−</programlisting>
130− </para>
131− </listitem>
132− </itemizedlist>
133−
134− <para>
135− The difference between a package being unsupported on some system and
136− being broken is admittedly a bit fuzzy. If a program
137− <emphasis>ought</emphasis> to work on a certain platform, but doesn't, the
138− platform should be included in <literal>meta.platforms</literal>, but marked
139− as broken with e.g. <literal>meta.broken =
140− !hostPlatform.isWindows</literal>. Of course, this begs the question of what
141− "ought" means exactly. That is left to the package maintainer.
142− </para>
143− </section>
144− <section xml:id="sec-allow-unfree">
145− <title>Installing unfree packages</title>
146−
147− <para>
148− There are several ways to tweak how Nix handles a package which has been
149− marked as unfree.
150− </para>
151−
152− <itemizedlist>
153− <listitem>
154− <para>
155− To temporarily allow all unfree packages, you can use an environment
156− variable for a single invocation of the nix tools:
157−<programlisting>$ export NIXPKGS_ALLOW_UNFREE=1</programlisting>
158− </para>
159− </listitem>
160− <listitem>
161− <para>
162− It is possible to permanently allow individual unfree packages, while
163− still blocking unfree packages by default using the
164− <literal>allowUnfreePredicate</literal> configuration option in the user
165− configuration file.
166− </para>
167− <para>
168− This option is a function which accepts a package as a parameter, and
169− returns a boolean. The following example configuration accepts a package
170− and always returns false:
171−<programlisting>
172−{
173− allowUnfreePredicate = (pkg: false);
174−}
175−</programlisting>
176− </para>
177− <para>
178− For a more useful example, try the following. This configuration
179− only allows unfree packages named flash player and visual studio
180− code:
181−<programlisting>
182−{
183− allowUnfreePredicate = (pkg: builtins.elem (builtins.parseDrvName pkg.name).name [ "flashplayer" "vscode" ]);
184−}
185−</programlisting>
186− </para>
187− </listitem>
188− <listitem>
189− <para>
190− It is also possible to whitelist and blacklist licenses that are
191− specifically acceptable or not acceptable, using
192− <literal>whitelistedLicenses</literal> and
193− <literal>blacklistedLicenses</literal>, respectively.
194− </para>
195− <para>
196− The following example configuration whitelists the licenses
197− <literal>amd</literal> and <literal>wtfpl</literal>:
198−<programlisting>
199−{
200− whitelistedLicenses = with stdenv.lib.licenses; [ amd wtfpl ];
201−}
202−</programlisting>
203− </para>
204− <para>
205− The following example configuration blacklists the <literal>gpl3</literal>
206− and <literal>agpl3</literal> licenses:
207−<programlisting>
208−{
209− blacklistedLicenses = with stdenv.lib.licenses; [ agpl3 gpl3 ];
210−}
211−</programlisting>
212− </para>
213− </listitem>
214− </itemizedlist>
215−
216− <para>
217− A complete list of licenses can be found in the file
218− <filename>lib/licenses.nix</filename> of the nixpkgs tree.
219− </para>
220− </section>
221− <section xml:id="sec-allow-insecure">
222− <title>Installing insecure packages</title>
223−
224− <para>
225− There are several ways to tweak how Nix handles a package which has been
226− marked as insecure.
227− </para>
228−
229− <itemizedlist>
230− <listitem>
231− <para>
232− To temporarily allow all insecure packages, you can use an environment
233− variable for a single invocation of the nix tools:
234−<programlisting>$ export NIXPKGS_ALLOW_INSECURE=1</programlisting>
235− </para>
236− </listitem>
237− <listitem>
238− <para>
239− It is possible to permanently allow individual insecure packages, while
240− still blocking other insecure packages by default using the
241− <literal>permittedInsecurePackages</literal> configuration option in the
242− user configuration file.
243− </para>
244− <para>
245− The following example configuration permits the installation of the
246− hypothetically insecure package <literal>hello</literal>, version
247− <literal>1.2.3</literal>:
248−<programlisting>
249−{
250− permittedInsecurePackages = [
251− "hello-1.2.3"
252− ];
253−}
254−</programlisting>
255− </para>
256− </listitem>
257− <listitem>
258− <para>
259− It is also possible to create a custom policy around which insecure
260− packages to allow and deny, by overriding the
261− <literal>allowInsecurePredicate</literal> configuration option.
262− </para>
263− <para>
264− The <literal>allowInsecurePredicate</literal> option is a function which
265− accepts a package and returns a boolean, much like
266− <literal>allowUnfreePredicate</literal>.
267− </para>
268− <para>
269− The following configuration example only allows insecure packages with
270− very short names:
271−<programlisting>
272−{
273− allowInsecurePredicate = (pkg: (builtins.stringLength (builtins.parseDrvName pkg.name).name) <= 5);
274−}
275−</programlisting>
276− </para>
277− <para>
278− Note that <literal>permittedInsecurePackages</literal> is only checked if
279− <literal>allowInsecurePredicate</literal> is not specified.
280− </para>
281− </listitem>
282− </itemizedlist>
283− </section>
284−<!--============================================================-->
285− <section xml:id="sec-modify-via-packageOverrides">
286− <title>Modify packages via <literal>packageOverrides</literal></title>
287−
288− <para>
289− You can define a function called <varname>packageOverrides</varname> in your
290− local <filename>~/.config/nixpkgs/config.nix</filename> to override Nix
291− packages. It must be a function that takes pkgs as an argument and returns a
292− modified set of packages.
293−<programlisting>
294−{
295− packageOverrides = pkgs: rec {
296− foo = pkgs.foo.override { ... };
297− };
298−}
299−</programlisting>
300− </para>
301− </section>
302− <section xml:id="sec-declarative-package-management">
303− <title>Declarative Package Management</title>
304−
305− <section xml:id="sec-building-environment">
306− <title>Build an environment</title>
307−
308− <para>
309− Using <literal>packageOverrides</literal>, it is possible to manage
310− packages declaratively. This means that we can list all of our desired
311− packages within a declarative Nix expression. For example, to have
312− <literal>aspell</literal>, <literal>bc</literal>,
313− <literal>ffmpeg</literal>, <literal>coreutils</literal>,
314− <literal>gdb</literal>, <literal>nixUnstable</literal>,
315− <literal>emscripten</literal>, <literal>jq</literal>,
316− <literal>nox</literal>, and <literal>silver-searcher</literal>, we could
317− use the following in <filename>~/.config/nixpkgs/config.nix</filename>:
318− </para>
319−
320−<screen>
321−{
322− packageOverrides = pkgs: with pkgs; {
323− myPackages = pkgs.buildEnv {
324− name = "my-packages";
325− paths = [ aspell bc coreutils gdb ffmpeg nixUnstable emscripten jq nox silver-searcher ];
326− };
327− };
328−}
329−</screen>
330−
331− <para>
332− To install it into our environment, you can just run <literal>nix-env -iA
333− nixpkgs.myPackages</literal>. If you want to load the packages to be built
334− from a working copy of <literal>nixpkgs</literal> you just run
335− <literal>nix-env -f. -iA myPackages</literal>. To explore what's been
336− installed, just look through <filename>~/.nix-profile/</filename>. You can
337− see that a lot of stuff has been installed. Some of this stuff is useful
338− some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
339− </para>
340−
341−<screen>
342−{
343− packageOverrides = pkgs: with pkgs; {
344− myPackages = pkgs.buildEnv {
345− name = "my-packages";
346− paths = [ aspell bc coreutils gdb ffmpeg nixUnstable emscripten jq nox silver-searcher ];
347− pathsToLink = [ "/share" "/bin" ];
348− };
349− };
350−}
351−</screen>
352−
353− <para>
354− <literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed
355− which gets rid of the extra stuff in the profile. <filename>/bin</filename>
356− and <filename>/share</filename> are good defaults for a user environment,
357− getting rid of the clutter. If you are running on Nix on MacOS, you may
358− want to add another path as well, <filename>/Applications</filename>, that
359− makes GUI apps available.
360− </para>
361− </section>
362−
363− <section xml:id="sec-getting-documentation">
364− <title>Getting documentation</title>
365−
366− <para>
367− After building that new environment, look through
368− <filename>~/.nix-profile</filename> to make sure everything is there that
369− we wanted. Discerning readers will note that some files are missing. Look
370− inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this.
371− There are no man pages for any of the Nix tools! This is because some
372− packages like Nix have multiple outputs for things like documentation (see
373− section 4). Let's make Nix install those as well.
374− </para>
375−
376−<screen>
377−{
378− packageOverrides = pkgs: with pkgs; {
379− myPackages = pkgs.buildEnv {
380− name = "my-packages";
381− paths = [ aspell bc coreutils ffmpeg nixUnstable emscripten jq nox silver-searcher ];
382− pathsToLink = [ "/share/man" "/share/doc" "/bin" ];
383− extraOutputsToInstall = [ "man" "doc" ];
384− };
385− };
386−}
387−</screen>
388−
389− <para>
390− This provides us with some useful documentation for using our packages.
391− However, if we actually want those manpages to be detected by man, we need
392− to set up our environment. This can also be managed within Nix expressions.
393− </para>
394−
395−<screen>
396−{
397− packageOverrides = pkgs: with pkgs; rec {
398− myProfile = writeText "my-profile" ''
399− export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
400− export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
401− '';
402− myPackages = pkgs.buildEnv {
403− name = "my-packages";
404− paths = [
405− (runCommand "profile" {} ''
406− mkdir -p $out/etc/profile.d
407− cp ${myProfile} $out/etc/profile.d/my-profile.sh
408− '')
409− aspell
410− bc
411− coreutils
412− ffmpeg
413− man
414− nixUnstable
415− emscripten
416− jq
417− nox
418− silver-searcher
419− ];
420− pathsToLink = [ "/share/man" "/share/doc" "/bin" "/etc" ];
421− extraOutputsToInstall = [ "man" "doc" ];
422− };
423− };
424−}
425−</screen>
426−
427− <para>
428− For this to work fully, you must also have this script sourced when you are
429− logged in. Try adding something like this to your
430− <filename>~/.profile</filename> file:
431− </para>
432−
433−<screen>
434−#!/bin/sh
435−if [ -d $HOME/.nix-profile/etc/profile.d ]; then
436− for i in $HOME/.nix-profile/etc/profile.d/*.sh; do
437− if [ -r $i ]; then
438− . $i
439− fi
440− done
441−fi
442−</screen>
443−
444− <para>
445− Now just run <literal>source $HOME/.profile</literal> and you can starting
446− loading man pages from your environent.
447− </para>
448− </section>
449−
450− <section xml:id="sec-gnu-info-setup">
451− <title>GNU info setup</title>
452−
453− <para>
454− Configuring GNU info is a little bit trickier than man pages. To work
455− correctly, info needs a database to be generated. This can be done with
456− some small modifications to our environment scripts.
457− </para>
458−
459−<screen>
460−{
461− packageOverrides = pkgs: with pkgs; rec {
462− myProfile = writeText "my-profile" ''
463− export PATH=$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/sbin:/bin:/usr/sbin:/usr/bin
464− export MANPATH=$HOME/.nix-profile/share/man:/nix/var/nix/profiles/default/share/man:/usr/share/man
465− export INFOPATH=$HOME/.nix-profile/share/info:/nix/var/nix/profiles/default/share/info:/usr/share/info
466− '';
467− myPackages = pkgs.buildEnv {
468− name = "my-packages";
469− paths = [
470− (runCommand "profile" {} ''
471− mkdir -p $out/etc/profile.d
472− cp ${myProfile} $out/etc/profile.d/my-profile.sh
473− '')
474− aspell
475− bc
476− coreutils
477− ffmpeg
478− man
479− nixUnstable
480− emscripten
481− jq
482− nox
483− silver-searcher
484− texinfoInteractive
485− ];
486− pathsToLink = [ "/share/man" "/share/doc" "/share/info" "/bin" "/etc" ];
487− extraOutputsToInstall = [ "man" "doc" "info" ];
488− postBuild = ''
489− if [ -x $out/bin/install-info -a -w $out/share/info ]; then
490− shopt -s nullglob
491− for i in $out/share/info/*.info $out/share/info/*.info.gz; do
492− $out/bin/install-info $i $out/share/info/dir
493− done
494− fi
495− '';
496− };
497− };
498−}
499−</screen>
500−
501− <para>
502− <literal>postBuild</literal> tells Nixpkgs to run a command after building
503− the environment. In this case, <literal>install-info</literal> adds the
504− installed info pages to <literal>dir</literal> which is GNU info's default
505− root node. Note that <literal>texinfoInteractive</literal> is added to the
506− environment to give the <literal>install-info</literal> command.
507− </para>
508− </section>
509− </section>
510−</chapter>
doc/contributing.xmldeleted−35
@@ -1,35 +0,0 @@
1−<chapter xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="chap-contributing">
4− <title>Contributing to this documentation</title>
5− <para>
6− The DocBook sources of the Nixpkgs manual are in the
7− <filename
8−xlink:href="https://github.com/NixOS/nixpkgs/tree/master/doc">doc</filename>
9− subdirectory of the Nixpkgs repository.
10− </para>
11− <para>
12− You can quickly check your edits with <command>make</command>:
13− </para>
14−<screen>
15− $ cd /path/to/nixpkgs/doc
16− $ nix-shell
17− [nix-shell]$ make
18−</screen>
19− <para>
20− If you experience problems, run <command>make debug</command> to help
21− understand the docbook errors.
22− </para>
23− <para>
24− After making modifications to the manual, it's important to build it before
25− committing. You can do that as follows:
26−<screen>
27− $ cd /path/to/nixpkgs/doc
28− $ nix-shell
29− [nix-shell]$ make clean
30− [nix-shell]$ nix-build .
31−</screen>
32− If the build succeeds, the manual will be in
33− <filename>./result/share/doc/nixpkgs/manual.html</filename>.
34− </para>
35−</chapter>
doc/contributing/coding-conventions.chapter.mdnew file+665
@@ -0,0 +1,665 @@
1+# Coding conventions {#chap-conventions}
2+
3+## Syntax {#sec-syntax}
4+
5+- Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
6+
7+- Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use `(setq-default indent-tabs-mode nil)` in Emacs. Everybody has different tab settings so it’s asking for trouble.
8+
9+- Use `lowerCamelCase` for variable names, not `UpperCamelCase`. Note, this rule does not apply to package attribute names, which instead follow the rules in [](#sec-package-naming).
10+
11+- Function calls with attribute set arguments are written as
12+
13+ ```nix
14+ foo {
15+ arg = ...;
16+ }
17+ ```
18+
19+ not
20+
21+ ```nix
22+ foo
23+ {
24+ arg = ...;
25+ }
26+ ```
27+
28+ Also fine is
29+
30+ ```nix
31+ foo { arg = ...; }
32+ ```
33+
34+ if it's a short call.
35+
36+- In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
37+
38+ ```nix
39+ # A long list.
40+ list = [
41+ elem1
42+ elem2
43+ elem3
44+ ];
45+
46+ # A long attribute set.
47+ attrs = {
48+ attr1 = short_expr;
49+ attr2 =
50+ if true then big_expr else big_expr;
51+ };
52+
53+ # Combined
54+ listOfAttrs = [
55+ {
56+ attr1 = 3;
57+ attr2 = "fff";
58+ }
59+ {
60+ attr1 = 5;
61+ attr2 = "ggg";
62+ }
63+ ];
64+ ```
65+
66+- Short lists or attribute sets can be written on one line:
67+
68+ ```nix
69+ # A short list.
70+ list = [ elem1 elem2 elem3 ];
71+
72+ # A short set.
73+ attrs = { x = 1280; y = 1024; };
74+ ```
75+
76+- Breaking in the middle of a function argument can give hard-to-read code, like
77+
78+ ```nix
79+ someFunction { x = 1280;
80+ y = 1024; } otherArg
81+ yetAnotherArg
82+ ```
83+
84+ (especially if the argument is very large, spanning multiple lines).
85+
86+ Better:
87+
88+ ```nix
89+ someFunction
90+ { x = 1280; y = 1024; }
91+ otherArg
92+ yetAnotherArg
93+ ```
94+
95+ or
96+
97+ ```nix
98+ let res = { x = 1280; y = 1024; };
99+ in someFunction res otherArg yetAnotherArg
100+ ```
101+
102+- The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.
103+
104+ ```nix
105+ { arg1, arg2 }:
106+ assert system == "i686-linux";
107+ stdenv.mkDerivation { ...
108+ ```
109+
110+ not
111+
112+ ```nix
113+ { arg1, arg2 }:
114+ assert system == "i686-linux";
115+ stdenv.mkDerivation { ...
116+ ```
117+
118+- Function formal arguments are written as:
119+
120+ ```nix
121+ { arg1, arg2, arg3 }:
122+ ```
123+
124+ but if they don't fit on one line they're written as:
125+
126+ ```nix
127+ { arg1, arg2, arg3
128+ , arg4, ...
129+ , # Some comment...
130+ argN
131+ }:
132+ ```
133+
134+- Functions should list their expected arguments as precisely as possible. That is, write
135+
136+ ```nix
137+ { stdenv, fetchurl, perl }: ...
138+ ```
139+
140+ instead of
141+
142+ ```nix
143+ args: with args; ...
144+ ```
145+
146+ or
147+
148+ ```nix
149+ { stdenv, fetchurl, perl, ... }: ...
150+ ```
151+
152+ For functions that are truly generic in the number of arguments (such as wrappers around `mkDerivation`) that have some required arguments, you should write them using an `@`-pattern:
153+
154+ ```nix
155+ { stdenv, doCoverageAnalysis ? false, ... } @ args:
156+
157+ stdenv.mkDerivation (args // {
158+ ... if doCoverageAnalysis then "bla" else "" ...
159+ })
160+ ```
161+
162+ instead of
163+
164+ ```nix
165+ args:
166+
167+ args.stdenv.mkDerivation (args // {
168+ ... if args ? doCoverageAnalysis && args.doCoverageAnalysis then "bla" else "" ...
169+ })
170+ ```
171+
172+- Unnecessary string conversions should be avoided. Do
173+
174+ ```nix
175+ rev = version;
176+ ```
177+
178+ instead of
179+
180+ ```nix
181+ rev = "${version}";
182+ ```
183+
184+- Building lists conditionally _should_ be done with `lib.optional(s)` instead of using `if cond then [ ... ] else null` or `if cond then [ ... ] else [ ]`.
185+
186+ ```nix
187+ buildInputs = lib.optional stdenv.isDarwin iconv;
188+ ```
189+
190+ instead of
191+
192+ ```nix
193+ buildInputs = if stdenv.isDarwin then [ iconv ] else null;
194+ ```
195+
196+ As an exception, an explicit conditional expression with null can be used when fixing a important bug without triggering a mass rebuild.
197+ If this is done a follow up pull request _should_ be created to change the code to `lib.optional(s)`.
198+
199+- Arguments should be listed in the order they are used, with the exception of `lib`, which always goes first.
200+
201+## Package naming {#sec-package-naming}
202+
203+The key words _must_, _must not_, _required_, _shall_, _shall not_, _should_, _should not_, _recommended_, _may_, and _optional_ in this section are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). Only _emphasized_ words are to be interpreted in this way.
204+
205+In Nixpkgs, there are generally three different names associated with a package:
206+
207+- The `name` attribute of the derivation (excluding the version part). This is what most users see, in particular when using `nix-env`.
208+
209+- The variable name used for the instantiated package in `all-packages.nix`, and when passing it as a dependency to other functions. Typically this is called the _package attribute name_. This is what Nix expression authors see. It can also be used when installing using `nix-env -iA`.
210+
211+- The filename for (the directory containing) the Nix expression.
212+
213+Most of the time, these are the same. For instance, the package `e2fsprogs` has a `name` attribute `"e2fsprogs-version"`, is bound to the variable name `e2fsprogs` in `all-packages.nix`, and the Nix expression is in `pkgs/os-specific/linux/e2fsprogs/default.nix`.
214+
215+There are a few naming guidelines:
216+
217+- The `pname` attribute _should_ be identical to the upstream package name.
218+
219+- The `pname` and the `version` attribute _must not_ contain uppercase letters — e.g., `"mplayer" instead of `"MPlayer"`.
220+
221+- The `version` attribute _must_ start with a digit e.g`"0.3.1rc2".
222+
223+- If a package is not a release but a commit from a repository, then the `version` attribute _must_ be the date of that (fetched) commit. The date _must_ be in `"unstable-YYYY-MM-DD"` format.
224+
225+- Dashes in the package `pname` _should_ be preserved in new variable names, rather than converted to underscores or camel cased — e.g., `http-parser` instead of `http_parser` or `httpParser`. The hyphenated style is preferred in all three package names.
226+
227+- If there are multiple versions of a package, this _should_ be reflected in the variable names in `all-packages.nix`, e.g. `json-c_0_9` and `json-c_0_11`. If there is an obvious “default” version, make an attribute like `json-c = json-c_0_9;`. See also [](#sec-versioning)
228+
229+## File naming and organisation {#sec-organisation}
230+
231+Names of files and directories should be in lowercase, with dashes between words — not in camel case. For instance, it should be `all-packages.nix`, not `allPackages.nix` or `AllPackages.nix`.
232+
233+### Hierarchy {#sec-hierarchy}
234+
235+Each package should be stored in its own directory somewhere in the `pkgs/` tree, i.e. in `pkgs/category/subcategory/.../pkgname`. Below are some rules for picking the right category for a package. Many packages fall under several categories; what matters is the _primary_ purpose of a package. For example, the `libxml2` package builds both a library and some tools; but it’s a library foremost, so it goes under `pkgs/development/libraries`.
236+
237+When in doubt, consider refactoring the `pkgs/` tree, e.g. creating new categories or splitting up an existing category.
238+
239+**If it’s used to support _software development_:**
240+
241+- **If it’s a _library_ used by other packages:**
242+
243+ - `development/libraries` (e.g. `libxml2`)
244+
245+- **If it’s a _compiler_:**
246+
247+ - `development/compilers` (e.g. `gcc`)
248+
249+- **If it’s an _interpreter_:**
250+
251+ - `development/interpreters` (e.g. `guile`)
252+
253+- **If it’s a (set of) development _tool(s)_:**
254+
255+ - **If it’s a _parser generator_ (including lexers):**
256+
257+ - `development/tools/parsing` (e.g. `bison`, `flex`)
258+
259+ - **If it’s a _build manager_:**
260+
261+ - `development/tools/build-managers` (e.g. `gnumake`)
262+
263+ - **Else:**
264+
265+ - `development/tools/misc` (e.g. `binutils`)
266+
267+- **Else:**
268+
269+ - `development/misc`
270+
271+**If it’s a (set of) _tool(s)_:**
272+
273+(A tool is a relatively small program, especially one intended to be used non-interactively.)
274+
275+- **If it’s for _networking_:**
276+
277+ - `tools/networking` (e.g. `wget`)
278+
279+- **If it’s for _text processing_:**
280+
281+ - `tools/text` (e.g. `diffutils`)
282+
283+- **If it’s a _system utility_, i.e., something related or essential to the operation of a system:**
284+
285+ - `tools/system` (e.g. `cron`)
286+
287+- **If it’s an _archiver_ (which may include a compression function):**
288+
289+ - `tools/archivers` (e.g. `zip`, `tar`)
290+
291+- **If it’s a _compression_ program:**
292+
293+ - `tools/compression` (e.g. `gzip`, `bzip2`)
294+
295+- **If it’s a _security_-related program:**
296+
297+ - `tools/security` (e.g. `nmap`, `gnupg`)
298+
299+- **Else:**
300+
301+ - `tools/misc`
302+
303+**If it’s a _shell_:**
304+
305+- `shells` (e.g. `bash`)
306+
307+**If it’s a _server_:**
308+
309+- **If it’s a web server:**
310+
311+ - `servers/http` (e.g. `apache-httpd`)
312+
313+- **If it’s an implementation of the X Windowing System:**
314+
315+ - `servers/x11` (e.g. `xorg` — this includes the client libraries and programs)
316+
317+- **Else:**
318+
319+ - `servers/misc`
320+
321+**If it’s a _desktop environment_:**
322+
323+- `desktops` (e.g. `kde`, `gnome`, `enlightenment`)
324+
325+**If it’s a _window manager_:**
326+
327+- `applications/window-managers` (e.g. `awesome`, `stumpwm`)
328+
329+**If it’s an _application_:**
330+
331+A (typically large) program with a distinct user interface, primarily used interactively.
332+
333+- **If it’s a _version management system_:**
334+
335+ - `applications/version-management` (e.g. `subversion`)
336+
337+- **If it’s a _terminal emulator_:**
338+
339+ - `applications/terminal-emulators` (e.g. `alacritty` or `rxvt` or `termite`)
340+
341+- **If it’s for _video playback / editing_:**
342+
343+ - `applications/video` (e.g. `vlc`)
344+
345+- **If it’s for _graphics viewing / editing_:**
346+
347+ - `applications/graphics` (e.g. `gimp`)
348+
349+- **If it’s for _networking_:**
350+
351+ - **If it’s a _mailreader_:**
352+
353+ - `applications/networking/mailreaders` (e.g. `thunderbird`)
354+
355+ - **If it’s a _newsreader_:**
356+
357+ - `applications/networking/newsreaders` (e.g. `pan`)
358+
359+ - **If it’s a _web browser_:**
360+
361+ - `applications/networking/browsers` (e.g. `firefox`)
362+
363+ - **Else:**
364+
365+ - `applications/networking/misc`
366+
367+- **Else:**
368+
369+ - `applications/misc`
370+
371+**If it’s _data_ (i.e., does not have a straight-forward executable semantics):**
372+
373+- **If it’s a _font_:**
374+
375+ - `data/fonts`
376+
377+- **If it’s an _icon theme_:**
378+
379+ - `data/icons`
380+
381+- **If it’s related to _SGML/XML processing_:**
382+
383+ - **If it’s an _XML DTD_:**
384+
385+ - `data/sgml+xml/schemas/xml-dtd` (e.g. `docbook`)
386+
387+ - **If it’s an _XSLT stylesheet_:**
388+
389+ (Okay, these are executable...)
390+
391+ - `data/sgml+xml/stylesheets/xslt` (e.g. `docbook-xsl`)
392+
393+- **If it’s a _theme_ for a _desktop environment_, a _window manager_ or a _display manager_:**
394+
395+ - `data/themes`
396+
397+**If it’s a _game_:**
398+
399+- `games`
400+
401+**Else:**
402+
403+- `misc`
404+
405+### Versioning {#sec-versioning}
406+
407+Because every version of a package in Nixpkgs creates a potential maintenance burden, old versions of a package should not be kept unless there is a good reason to do so. For instance, Nixpkgs contains several versions of GCC because other packages don’t build with the latest version of GCC. Other examples are having both the latest stable and latest pre-release version of a package, or to keep several major releases of an application that differ significantly in functionality.
408+
409+If there is only one version of a package, its Nix expression should be named `e2fsprogs/default.nix`. If there are multiple versions, this should be reflected in the filename, e.g. `e2fsprogs/1.41.8.nix` and `e2fsprogs/1.41.9.nix`. The version in the filename should leave out unnecessary detail. For instance, if we keep the latest Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named `firefox/2.0.nix` and `firefox/3.5.nix`, respectively (which, at a given point, might contain versions `2.0.0.20` and `3.5.4`). If a version requires many auxiliary files, you can use a subdirectory for each version, e.g. `firefox/2.0/default.nix` and `firefox/3.5/default.nix`.
410+
411+All versions of a package _must_ be included in `all-packages.nix` to make sure that they evaluate correctly.
412+
413+## Fetching Sources {#sec-sources}
414+
415+There are multiple ways to fetch a package source in nixpkgs. The general guideline is that you should package reproducible sources with a high degree of availability. Right now there is only one fetcher which has mirroring support and that is `fetchurl`. Note that you should also prefer protocols which have a corresponding proxy environment variable.
416+
417+You can find many source fetch helpers in `pkgs/build-support/fetch*`.
418+
419+In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these have names on the form `fetchFrom*`. The intention of these are to provide snapshot fetches but using the same api as some of the version controlled fetchers from `pkgs/build-support/`. As an example going from bad to good:
420+
421+- Bad: Uses `git://` which won't be proxied.
422+
423+ ```nix
424+ src = fetchgit {
425+ url = "git://github.com/NixOS/nix.git";
426+ rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
427+ sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
428+ }
429+ ```
430+
431+- Better: This is ok, but an archive fetch will still be faster.
432+
433+ ```nix
434+ src = fetchgit {
435+ url = "https://github.com/NixOS/nix.git";
436+ rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
437+ sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
438+ }
439+ ```
440+
441+- Best: Fetches a snapshot archive and you get the rev you want.
442+
443+ ```nix
444+ src = fetchFromGitHub {
445+ owner = "NixOS";
446+ repo = "nix";
447+ rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
448+ sha256 = "1i2yxndxb6yc9l6c99pypbd92lfq5aac4klq7y2v93c9qvx2cgpc";
449+ }
450+ ```
451+
452+ Find the value to put as `sha256` by running `nix run -f '<nixpkgs>' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix` or `nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz`.
453+
454+## Obtaining source hash {#sec-source-hashes}
455+
456+Preferred source hash type is sha256. There are several ways to get it.
457+
458+1. Prefetch URL (with `nix-prefetch-XXX URL`, where `XXX` is one of `url`, `git`, `hg`, `cvs`, `bzr`, `svn`). Hash is printed to stdout.
459+
460+2. Prefetch by package source (with `nix-prefetch-url '<nixpkgs>' -A PACKAGE.src`, where `PACKAGE` is package attribute name). Hash is printed to stdout.
461+
462+ This works well when you've upgraded existing package version and want to find out new hash, but is useless if package can't be accessed by attribute or package has multiple sources (`.srcs`, architecture-dependent sources, etc).
463+
464+3. Upstream provided hash: use it when upstream provides `sha256` or `sha512` (when upstream provides `md5`, don't use it, compute `sha256` instead).
465+
466+ A little nuance is that `nix-prefetch-*` tools produce hash encoded with `base32`, but upstream usually provides hexadecimal (`base16`) encoding. Fetchers understand both formats. Nixpkgs does not standardize on any one format.
467+
468+ You can convert between formats with nix-hash, for example:
469+
470+ ```ShellSession
471+ $ nix-hash --type sha256 --to-base32 HASH
472+ ```
473+
474+4. Extracting hash from local source tarball can be done with `sha256sum`. Use `nix-prefetch-url file:///path/to/tarball` if you want base32 hash.
475+
476+5. Fake hash: set fake hash in package expression, perform build and extract correct hash from error Nix prints.
477+
478+ For package updates it is enough to change one symbol to make hash fake. For new packages, you can use `lib.fakeSha256`, `lib.fakeSha512` or any other fake hash.
479+
480+ This is last resort method when reconstructing source URL is non-trivial and `nix-prefetch-url -A` isn’t applicable (for example, [one of `kodi` dependencies](https://github.com/NixOS/nixpkgs/blob/d2ab091dd308b99e4912b805a5eb088dd536adb9/pkgs/applications/video/kodi/default.nix#L73)). The easiest way then would be replace hash with a fake one and rebuild. Nix build will fail and error message will contain desired hash.
481+
482+::: {.warning}
483+This method has security problems. Check below for details.
484+:::
485+
486+### Obtaining hashes securely {#sec-source-hashes-security}
487+
488+Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of fetching source you can fetch malware, and instead of source hash you get hash of malware. Here are security considerations for this scenario:
489+
490+- `http://` URLs are not secure to prefetch hash from;
491+
492+- hashes from upstream (in method 3) should be obtained via secure protocol;
493+
494+- `https://` URLs are secure in methods 1, 2, 3;
495+
496+- `https://` URLs are not secure in method 5. When obtaining hashes with fake hash method, TLS checks are disabled. So refetch source hash from several different networks to exclude MITM scenario. Alternatively, use fake hash method to make Nix error, but instead of extracting hash from error, extract `https://` URL and prefetch it with method 1.
497+
498+## Patches {#sec-patches}
499+
500+Patches available online should be retrieved using `fetchpatch`.
501+
502+```nix
503+patches = [
504+ (fetchpatch {
505+ name = "fix-check-for-using-shared-freetype-lib.patch";
506+ url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285";
507+ sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr";
508+ })
509+];
510+```
511+
512+Otherwise, you can add a `.patch` file to the `nixpkgs` repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to `nixpkgs` should be added in this way.
513+
514+```nix
515+patches = [ ./0001-changes.patch ];
516+```
517+
518+If you do need to do create this sort of patch file, one way to do so is with git:
519+
520+1. Move to the root directory of the source code you're patching.
521+
522+ ```ShellSession
523+ $ cd the/program/source
524+ ```
525+
526+2. If a git repository is not already present, create one and stage all of the source files.
527+
528+ ```ShellSession
529+ $ git init
530+ $ git add .
531+ ```
532+
533+3. Edit some files to make whatever changes need to be included in the patch.
534+
535+4. Use git to create a diff, and pipe the output to a patch file:
536+
537+ ```ShellSession
538+ $ git diff -a > nixpkgs/pkgs/the/package/0001-changes.patch
539+ ```
540+
541+If a patch is available online but does not cleanly apply, it can be modified in some fixed ways by using additional optional arguments for `fetchpatch`:
542+
543+- `relative`: Similar to using `git-diff`'s `--relative` flag, only keep changes inside the specified directory, making paths relative to it.
544+- `stripLen`: Remove the first `stripLen` components of pathnames in the patch.
545+- `extraPrefix`: Prefix pathnames by this string.
546+- `excludes`: Exclude files matching these patterns (applies after the above arguments).
547+- `includes`: Include only files matching these patterns (applies after the above arguments).
548+- `revert`: Revert the patch.
549+
550+Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
551+
552+## Package tests {#sec-package-tests}
553+
554+Tests are important to ensure quality and make reviews and automatic updates easy.
555+
556+The following types of tests exists:
557+
558+* [NixOS **module tests**](https://nixos.org/manual/nixos/stable/#sec-nixos-tests), which spawn one or more NixOS VMs. They exercise both NixOS modules and the packaged programs used within them. For example, a NixOS module test can start a web server VM running the `nginx` module, and a client VM running `curl` or a graphical `firefox`, and test that they can talk to each other and display the correct content.
559+* Nix **package tests** are a lightweight alternative to NixOS module tests. They should be used to create simple integration tests for packages, but cannot test NixOS services, and some programs with graphical user interfaces may also be difficult to test with them.
560+* The **`checkPhase` of a package**, which should execute the unit tests that are included in the source code of a package.
561+
562+Here in the nixpkgs manual we describe mostly _package tests_; for _module tests_ head over to the corresponding [section in the NixOS manual](https://nixos.org/manual/nixos/stable/#sec-nixos-tests).
563+
564+### Writing inline package tests {#ssec-inline-package-tests-writing}
565+
566+For very simple tests, they can be written inline:
567+
568+```nix
569+{ …, yq-go }:
570+
571+buildGoModule rec {
572+ …
573+
574+ passthru.tests = {
575+ simple = runCommand "${pname}-test" {} ''
576+ echo "test: 1" | ${yq-go}/bin/yq eval -j > $out
577+ [ "$(cat $out | tr -d $'\n ')" = '{"test":1}' ]
578+ '';
579+ };
580+}
581+```
582+
583+### Writing larger package tests {#ssec-package-tests-writing}
584+
585+This is an example using the `phoronix-test-suite` package with the current best practices.
586+
587+Add the tests in `passthru.tests` to the package definition like this:
588+
589+```nix
590+{ stdenv, lib, fetchurl, callPackage }:
591+
592+stdenv.mkDerivation {
593+ …
594+
595+ passthru.tests = {
596+ simple-execution = callPackage ./tests.nix { };
597+ };
598+
599+ meta = { … };
600+}
601+```
602+
603+Create `tests.nix` in the package directory:
604+
605+```nix
606+{ runCommand, phoronix-test-suite }:
607+
608+let
609+ inherit (phoronix-test-suite) pname version;
610+in
611+
612+runCommand "${pname}-tests" { meta.timeout = 60; }
613+ ''
614+ # automatic initial setup to prevent interactive questions
615+ ${phoronix-test-suite}/bin/phoronix-test-suite enterprise-setup >/dev/null
616+ # get version of installed program and compare with package version
617+ if [[ `${phoronix-test-suite}/bin/phoronix-test-suite version` != *"${version}"* ]]; then
618+ echo "Error: program version does not match package version"
619+ exit 1
620+ fi
621+ # run dummy command
622+ ${phoronix-test-suite}/bin/phoronix-test-suite dummy_module.dummy-command >/dev/null
623+ # needed for Nix to register the command as successful
624+ touch $out
625+ ''
626+```
627+
628+### Running package tests {#ssec-package-tests-running}
629+
630+You can run these tests with:
631+
632+```ShellSession
633+$ cd path/to/nixpkgs
634+$ nix-build -A phoronix-test-suite.tests
635+```
636+
637+### Examples of package tests {#ssec-package-tests-examples}
638+
639+Here are examples of package tests:
640+
641+- [Jasmin compile test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/jasmin/test-assemble-hello-world/default.nix)
642+- [Lobster compile test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/compilers/lobster/test-can-run-hello-world.nix)
643+- [Spacy annotation test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/python-modules/spacy/annotation-test/default.nix)
644+- [Libtorch test](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/science/math/libtorch/test/default.nix)
645+- [Multiple tests for nanopb](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/nanopb/default.nix)
646+
647+### Linking NixOS module tests to a package {#ssec-nixos-tests-linking}
648+
649+Like [package tests](#ssec-package-tests-writing) as shown above, [NixOS module tests](https://nixos.org/manual/nixos/stable/#sec-nixos-tests) can also be linked to a package, so that the tests can be easily run when changing the related package.
650+
651+For example, assuming we're packaging `nginx`, we can link its module test via `passthru.tests`:
652+
653+```nix
654+{ stdenv, lib, nixosTests }:
655+
656+stdenv.mkDerivation {
657+ ...
658+
659+ passthru.tests = {
660+ nginx = nixosTests.nginx;
661+ };
662+
663+ ...
664+}
665+```
doc/contributing/contributing-to-documentation.chapter.mdnew file+106
@@ -0,0 +1,106 @@
1+# Contributing to this documentation {#chap-contributing}
2+
3+The sources of the Nixpkgs manual are in the [doc](https://github.com/NixOS/nixpkgs/tree/master/doc) subdirectory of the Nixpkgs repository. The manual is still partially written in DocBook but it is progressively being converted to [Markdown](#sec-contributing-markup).
4+
5+You can quickly check your edits with `make`:
6+
7+```ShellSession
8+$ cd /path/to/nixpkgs/doc
9+$ nix-shell
10+[nix-shell]$ make
11+```
12+
13+If you experience problems, run `make debug` to help understand the docbook errors.
14+
15+After making modifications to the manual, it's important to build it before committing. You can do that as follows:
16+
17+```ShellSession
18+$ cd /path/to/nixpkgs/doc
19+$ nix-shell
20+[nix-shell]$ make clean
21+[nix-shell]$ nix-build .
22+```
23+
24+If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.html`.
25+
26+## Syntax {#sec-contributing-markup}
27+
28+As per [RFC 0072](https://github.com/NixOS/rfcs/pull/72), all new documentation content should be written in [CommonMark](https://commonmark.org/) Markdown dialect.
29+
30+Additionally, the following syntax extensions are currently used:
31+
32+- []{#ssec-contributing-markup-anchors}
33+ Explicitly defined **anchors** on headings, to allow linking to sections. These should be always used, to ensure the anchors can be linked even when the heading text changes, and to prevent conflicts between [automatically assigned identifiers](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/auto_identifiers.md).
34+
35+ It uses the widely compatible [header attributes](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/attributes.md) syntax:
36+
37+ ```markdown
38+ ## Syntax {#sec-contributing-markup}
39+ ```
40+
41+- []{#ssec-contributing-markup-anchors-inline}
42+ **Inline anchors**, which allow linking arbitrary place in the text (e.g. individual list items, sentences…).
43+
44+ They are defined using a hybrid of the link syntax with the attributes syntax known from headings, called [bracketed spans](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/bracketed_spans.md):
45+
46+ ```markdown
47+ - []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
48+ ```
49+
50+- []{#ssec-contributing-markup-automatic-links}
51+ If you **omit a link text** for a link pointing to a section, the text will be substituted automatically. For example, `[](#chap-contributing)` will result in [](#chap-contributing).
52+
53+ This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/using/syntax.html#targets-and-cross-referencing).
54+
55+- []{#ssec-contributing-markup-inline-roles}
56+ If you want to link to a man page, you can use `` {manpage}`nix.conf(5)` ``, which will turn into {manpage}`nix.conf(5)`.
57+
58+ The references will turn into links when a mapping exists in {file}`doc/build-aux/pandoc-filters/link-unix-man-references.lua`.
59+
60+ This syntax is taken from [MyST](https://myst-parser.readthedocs.io/en/latest/syntax/syntax.html#roles-an-in-line-extension-point). Though, the feature originates from [reStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-manpage) with slightly different syntax.
61+
62+- []{#ssec-contributing-markup-admonitions}
63+ **Admonitions**, set off from the text to bring attention to something.
64+
65+ It uses pandoc’s [fenced `div`s syntax](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/fenced_divs.md):
66+
67+ ```markdown
68+ ::: {.warning}
69+ This is a warning
70+ :::
71+ ```
72+
73+ which renders as
74+
75+ > ::: {.warning}
76+ > This is a warning.
77+ > :::
78+
79+ The following are supported:
80+
81+ - [`caution`](https://tdg.docbook.org/tdg/5.0/caution.html)
82+ - [`important`](https://tdg.docbook.org/tdg/5.0/important.html)
83+ - [`note`](https://tdg.docbook.org/tdg/5.0/note.html)
84+ - [`tip`](https://tdg.docbook.org/tdg/5.0/tip.html)
85+ - [`warning`](https://tdg.docbook.org/tdg/5.0/warning.html)
86+
87+- []{#ssec-contributing-markup-definition-lists}
88+ [**Definition lists**](https://github.com/jgm/commonmark-hs/blob/master/commonmark-extensions/test/definition_lists.md), for defining a group of terms:
89+
90+ ```markdown
91+ pear
92+ : green or yellow bulbous fruit
93+
94+ watermelon
95+ : green fruit with red flesh
96+ ```
97+
98+ which renders as
99+
100+ > pear
101+ > : green or yellow bulbous fruit
102+ >
103+ > watermelon
104+ > : green fruit with red flesh
105+
106+For contributing to the legacy parts, please see [DocBook: The Definitive Guide](https://tdg.docbook.org/) or the [DocBook rocks! primer](https://web.archive.org/web/20200816233747/https://docbook.rocks/).
doc/contributing/quick-start.chapter.mdnew file+77
@@ -0,0 +1,77 @@
1+# Quick Start to Adding a Package {#chap-quick-start}
2+
3+To add a package to Nixpkgs:
4+
5+1. Checkout the Nixpkgs source tree:
6+
7+ ```ShellSession
8+ $ git clone https://github.com/NixOS/nixpkgs
9+ $ cd nixpkgs
10+ ```
11+
12+2. Find a good place in the Nixpkgs tree to add the Nix expression for your package. For instance, a library package typically goes into `pkgs/development/libraries/pkgname`, while a web browser goes into `pkgs/applications/networking/browsers/pkgname`. See [](#sec-organisation) for some hints on the tree organisation. Create a directory for your package, e.g.
13+
14+ ```ShellSession
15+ $ mkdir pkgs/development/libraries/libfoo
16+ ```
17+
18+3. In the package directory, create a Nix expression — a piece of code that describes how to build the package. In this case, it should be a _function_ that is called with the package dependencies as arguments, and returns a build of the package in the Nix store. The expression should usually be called `default.nix`.
19+
20+ ```ShellSession
21+ $ emacs pkgs/development/libraries/libfoo/default.nix
22+ $ git add pkgs/development/libraries/libfoo/default.nix
23+ ```
24+
25+ You can have a look at the existing Nix expressions under `pkgs/` to see how it’s done. Here are some good ones:
26+
27+ - GNU Hello: [`pkgs/applications/misc/hello/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/hello/default.nix). Trivial package, which specifies some `meta` attributes which is good practice.
28+
29+ - GNU cpio: [`pkgs/tools/archivers/cpio/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/archivers/cpio/default.nix). Also a simple package. The generic builder in `stdenv` does everything for you. It has no dependencies beyond `stdenv`.
30+
31+ - GNU Multiple Precision arithmetic library (GMP): [`pkgs/development/libraries/gmp/5.1.x.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gmp/5.1.x.nix). Also done by the generic builder, but has a dependency on `m4`.
32+
33+ - Pan, a GTK-based newsreader: [`pkgs/applications/networking/newsreaders/pan/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix). Has an optional dependency on `gtkspell`, which is only built if `spellCheck` is `true`.
34+
35+ - Apache HTTPD: [`pkgs/servers/http/apache-httpd/2.4.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix). A bunch of optional features, variable substitutions in the configure flags, a post-install hook, and miscellaneous hackery.
36+
37+ - Thunderbird: [`pkgs/applications/networking/mailreaders/thunderbird/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/mailreaders/thunderbird/default.nix). Lots of dependencies.
38+
39+ - JDiskReport, a Java utility: [`pkgs/tools/misc/jdiskreport/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix). Nixpkgs doesn’t have a decent `stdenv` for Java yet so this is pretty ad-hoc.
40+
41+ - XML::Simple, a Perl module: [`pkgs/top-level/perl-packages.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) (search for the `XMLSimple` attribute). Most Perl modules are so simple to build that they are defined directly in `perl-packages.nix`; no need to make a separate file for them.
42+
43+ - Adobe Reader: [`pkgs/applications/misc/adobe-reader/default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/default.nix). Shows how binary-only packages can be supported. In particular the [builder](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/builder.sh) uses `patchelf` to set the RUNPATH and ELF interpreter of the executables so that the right libraries are found at runtime.
44+
45+ Some notes:
46+
47+ - All [`meta`](#chap-meta) attributes are optional, but it’s still a good idea to provide at least the `description`, `homepage` and [`license`](#sec-meta-license).
48+
49+ - You can use `nix-prefetch-url url` to get the SHA-256 hash of source distributions. There are similar commands as `nix-prefetch-git` and `nix-prefetch-hg` available in `nix-prefetch-scripts` package.
50+
51+ - A list of schemes for `mirror://` URLs can be found in [`pkgs/build-support/fetchurl/mirrors.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchurl/mirrors.nix).
52+
53+ The exact syntax and semantics of the Nix expression language, including the built-in function, are described in the Nix manual in the [chapter on writing Nix expressions](https://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions).
54+
55+4. Add a call to the function defined in the previous step to [`pkgs/top-level/all-packages.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix) with some descriptive name for the variable, e.g. `libfoo`.
56+
57+ ```ShellSession
58+ $ emacs pkgs/top-level/all-packages.nix
59+ ```
60+
61+ The attributes in that file are sorted by category (like “Development / Libraries”) that more-or-less correspond to the directory structure of Nixpkgs, and then by attribute name.
62+
63+5. To test whether the package builds, run the following command from the root of the nixpkgs source tree:
64+
65+ ```ShellSession
66+ $ nix-build -A libfoo
67+ ```
68+
69+ where `libfoo` should be the variable name defined in the previous step. You may want to add the flag `-K` to keep the temporary build directory in case something fails. If the build succeeds, a symlink `./result` to the package in the Nix store is created.
70+
71+6. If you want to install the package into your profile (optional), do
72+
73+ ```ShellSession
74+ $ nix-env -f . -iA libfoo
75+ ```
76+
77+7. Optionally commit the new package and open a pull request [to nixpkgs](https://github.com/NixOS/nixpkgs/pulls), or use [the Patches category](https://discourse.nixos.org/t/about-the-patches-category/477) on Discourse for sending a patch without a GitHub account.
doc/contributing/reviewing-contributions.chapter.mdnew file+208
@@ -0,0 +1,208 @@
1+# Reviewing contributions {#chap-reviewing-contributions}
2+
3+::: {.warning}
4+The following section is a draft, and the policy for reviewing is still being discussed in issues such as [#11166](https://github.com/NixOS/nixpkgs/issues/11166) and [#20836](https://github.com/NixOS/nixpkgs/issues/20836).
5+:::
6+
7+The Nixpkgs project 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.
8+
9+The high change rate of Nixpkgs makes any pull request that remains open for too long 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 this issue. GitHub provides sort filters that can be used to see the [most recently](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc) and the [least recently](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc) updated pull requests. We highly encourage looking at [this list of ready to merge, unreviewed pull requests](https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone).
10+
11+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 member and their work.
12+
13+GitHub provides reactions as 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 explanation so the submitter has directions to improve their contribution.
14+
15+pull request 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.
16+
17+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 their liking.
18+
19+## Package updates {#reviewing-contributions-package-updates}
20+
21+A package update is the most trivial and common type of pull request. These pull requests mainly consist of updating the version part of the package name and the source hash.
22+
23+It can happen that non-trivial updates include patches or more complex changes.
24+
25+Reviewing process:
26+
27+- Ensure that the package versioning fits the guidelines.
28+- Ensure that the commit text fits the guidelines.
29+- Ensure that the package maintainers are notified.
30+ - [CODEOWNERS](https://help.github.com/articles/about-codeowners) will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
31+- Ensure that the meta field information is correct.
32+ - License can change with version updates, so it should be checked to match the upstream license.
33+ - 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.
34+- Ensure that the code contains no typos.
35+- Building the package locally.
36+ - pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
37+ - 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.
38+
39+ ```ShellSession
40+ $ git fetch origin nixos-unstable
41+ $ git fetch origin pull/PRNUMBER/head
42+ $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD
43+ ```
44+
45+ - The first command fetches the nixos-unstable branch.
46+ - The second command fetches 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.
47+ - The third command rebases the pull request changes to the nixos-unstable branch.
48+ - The [nixpkgs-review](https://github.com/Mic92/nixpkgs-review) tool can be used to review a pull request content in a single command. `PRNUMBER` should be replaced by the number at the end of the pull request title. You can also provide the full github pull request url.
49+
50+ ```ShellSession
51+ $ nix-shell -p nixpkgs-review --run "nixpkgs-review pr PRNUMBER"
52+ ```
53+- Running every binary.
54+
55+Sample template for a package update review is provided below.
56+
57+```markdown
58+##### Reviewed points
59+
60+- [ ] package name fits guidelines
61+- [ ] package version fits guidelines
62+- [ ] package build on ARCHITECTURE
63+- [ ] executables tested on ARCHITECTURE
64+- [ ] all depending packages build
65+
66+##### Possible improvements
67+
68+##### Comments
69+```
70+
71+## New packages {#reviewing-contributions-new-packages}
72+
73+New packages are a common type of pull requests. These pull requests consists in adding a new nix-expression for a package.
74+
75+Review process:
76+
77+- Ensure that the package versioning fits the guidelines.
78+- Ensure that the commit name fits the guidelines.
79+- Ensure that the meta fields contain correct information.
80+ - License must match the upstream license.
81+ - Platforms should be set (or the package will not get binary substitutes).
82+ - Maintainers must be set. This can be the package submitter or a community member that accepts taking up maintainership of the package.
83+- Report detected typos.
84+- Ensure the package source:
85+ - Uses mirror URLs when available.
86+ - Uses the most appropriate functions (e.g. packages from GitHub should use `fetchFromGitHub`).
87+- Building the package locally.
88+- Running every binary.
89+
90+Sample template for a new package review is provided below.
91+
92+```markdown
93+##### Reviewed points
94+
95+- [ ] package path fits guidelines
96+- [ ] package name fits guidelines
97+- [ ] package version fits guidelines
98+- [ ] package build on ARCHITECTURE
99+- [ ] executables tested on ARCHITECTURE
100+- [ ] `meta.description` is set and fits guidelines
101+- [ ] `meta.license` fits upstream license
102+- [ ] `meta.platforms` is set
103+- [ ] `meta.maintainers` is set
104+- [ ] build time only dependencies are declared in `nativeBuildInputs`
105+- [ ] source is fetched using the appropriate function
106+- [ ] the list of `phases` is not overridden
107+- [ ] when a phase (like `installPhase`) is overridden it starts with `runHook preInstall` and ends with `runHook postInstall`.
108+- [ ] patches that are remotely available are fetched with `fetchpatch`
109+
110+##### Possible improvements
111+
112+##### Comments
113+```
114+
115+## Module updates {#reviewing-contributions-module-updates}
116+
117+Module updates are submissions changing modules in some ways. These often contains changes to the options or introduce new options.
118+
119+Reviewing process:
120+
121+- Ensure that the module maintainers are notified.
122+ - [CODEOWNERS](https://help.github.com/articles/about-codeowners/) will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
123+- Ensure that the module tests, if any, are succeeding.
124+- Ensure that the introduced options are correct.
125+ - Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated).
126+ - Description, default and example should be provided.
127+- Ensure that option changes are backward compatible.
128+ - `mkRenamedOptionModuleWith` provides a way to make option changes backward compatible.
129+- Ensure that removed options are declared with `mkRemovedOptionModule`
130+- Ensure that changes that are not backward compatible are mentioned in release notes.
131+- Ensure that documentations affected by the change is updated.
132+
133+Sample template for a module update review is provided below.
134+
135+```markdown
136+##### Reviewed points
137+
138+- [ ] changes are backward compatible
139+- [ ] removed options are declared with `mkRemovedOptionModule`
140+- [ ] changes that are not backward compatible are documented in release notes
141+- [ ] module tests succeed on ARCHITECTURE
142+- [ ] options types are appropriate
143+- [ ] options description is set
144+- [ ] options example is provided
145+- [ ] documentation affected by the changes is updated
146+
147+##### Possible improvements
148+
149+##### Comments
150+```
151+
152+## New modules {#reviewing-contributions-new-modules}
153+
154+New modules submissions introduce a new module to NixOS.
155+
156+Reviewing process:
157+
158+- Ensure that the module tests, if any, are succeeding.
159+- Ensure that the introduced options are correct.
160+ - Type should be appropriate (string related types differs in their merging capabilities, `loaOf` and `string` types are deprecated).
161+ - Description, default and example should be provided.
162+- Ensure that module `meta` field is present
163+ - Maintainers should be declared in `meta.maintainers`.
164+ - Module documentation should be declared with `meta.doc`.
165+- Ensure that the module respect other modules functionality.
166+ - For example, enabling a module should not open firewall ports by default.
167+
168+Sample template for a new module review is provided below.
169+
170+```markdown
171+##### Reviewed points
172+
173+- [ ] module path fits the guidelines
174+- [ ] module tests succeed on ARCHITECTURE
175+- [ ] options have appropriate types
176+- [ ] options have default
177+- [ ] options have example
178+- [ ] options have descriptions
179+- [ ] No unneeded package is added to environment.systemPackages
180+- [ ] meta.maintainers is set
181+- [ ] module documentation is declared in meta.doc
182+
183+##### Possible improvements
184+
185+##### Comments
186+```
187+
188+## Other submissions {#reviewing-contributions-other-submissions}
189+
190+Other type of submissions requires different reviewing steps.
191+
192+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.
193+
194+Container system, boot system and library changes are some examples of the pull requests fitting this category.
195+
196+## Merging pull requests {#reviewing-contributions--merging-pull-requests}
197+
198+It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
199+
200+<!--
201+The following paragraphs about how to deal with unactive contributors is just a proposition and should be modified to what the community agrees to be the right policy.
202+
203+Please note that contributors with commit rights unactive for more than three months will have their commit rights revoked.
204+-->
205+
206+Please see the discussion in [GitHub nixpkgs issue #50105](https://github.com/NixOS/nixpkgs/issues/50105) for information on how to proceed to be granted this level of access.
207+
208+In a case a contributor definitively leaves the Nix community, they should create an issue or post on [Discourse](https://discourse.nixos.org) with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
doc/contributing/submitting-changes.chapter.mdnew file+292
@@ -0,0 +1,292 @@
1+# Submitting changes {#chap-submitting-changes}
2+
3+## Making patches {#submitting-changes-making-patches}
4+
5+- Read [Manual (How to write packages for Nix)](https://nixos.org/nixpkgs/manual/).
6+
7+- Fork [the Nixpkgs repository](https://github.com/nixos/nixpkgs/) on GitHub.
8+
9+- Create a branch for your future fix.
10+
11+ - You can make branch from a commit of your local `nixos-version`. That will help you to avoid additional local compilations. Because you will receive packages from binary cache. For example
12+
13+ ```ShellSession
14+ $ nixos-version --hash
15+ 0998212
16+ $ git checkout 0998212
17+ $ git checkout -b 'fix/pkg-name-update'
18+ ```
19+
20+ - Please avoid working directly on the `master` branch.
21+
22+- Make commits of logical units.
23+
24+- If you removed pkgs or made some major NixOS changes, write about it in the release notes for the next stable release. For example `nixos/doc/manual/release-notes/rl-2003.xml`.
25+
26+- Check for unnecessary whitespace with `git diff --check` before committing.
27+
28+- Format the commit in a following way:
29+
30+ ```
31+ (pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
32+ Additional information.
33+ ```
34+
35+ - Examples:
36+ - `nginx: init at 2.0.1`
37+ - `firefox: 54.0.1 -> 55.0`
38+ - `nixos/hydra: add bazBaz option`
39+ - `nixos/nginx: refactor config generation`
40+
41+- Test your changes. If you work with
42+
43+ - nixpkgs:
44+
45+ - update pkg
46+ - `nix-env -iA pkg-attribute-name -f <path to your local nixpkgs folder>`
47+ - add pkg
48+ - Make sure it’s in `pkgs/top-level/all-packages.nix`
49+ - `nix-env -iA pkg-attribute-name -f <path to your local nixpkgs folder>`
50+ - _If you don’t want to install pkg in you profile_.
51+ - `nix-build -A pkg-attribute-name <path to your local nixpkgs folder>` and check results in the folder `result`. It will appear in the same directory where you did `nix-build`.
52+ - If you installed your package with `nix-env`, you can run `nix-env -e pkg-name` where `pkg-name` is as reported by `nix-env -q` to uninstall it from your system.
53+
54+ - NixOS and its modules:
55+ - You can add new module to your NixOS configuration file (usually it’s `/etc/nixos/configuration.nix`). And do `sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast`.
56+
57+- If you have commits `pkg-name: oh, forgot to insert whitespace`: squash commits in this case. Use `git rebase -i`.
58+
59+- [Rebase](https://git-scm.com/book/en/v2/Git-Branching-Rebasing) your branch against current `master`.
60+
61+## Submitting changes {#submitting-changes-submitting-changes}
62+
63+- Push your changes to your fork of nixpkgs.
64+- Create the pull request
65+- Follow [the contribution guidelines](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#submitting-changes).
66+
67+## Submitting security fixes {#submitting-changes-submitting-security-fixes}
68+
69+Security fixes are submitted in the same way as other changes and thus the same guidelines apply.
70+
71+- If a new version fixing the vulnerability has been released, update the package;
72+- If the security fix comes in the form of a patch and a CVE is available, then add the patch to the Nixpkgs tree, and apply it to the package.
73+ The name of the patch should be the CVE identifier, so e.g. `CVE-2019-13636.patch`; If a patch is fetched the name needs to be set as well, e.g.:
74+
75+ ```nix
76+ (fetchpatch {
77+ name = "CVE-2019-11068.patch";
78+ url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
79+ sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
80+ })
81+ ```
82+
83+If a security fix applies to both master and a stable release then, similar to regular changes, they are preferably delivered via master first and cherry-picked to the release branch.
84+
85+Critical security fixes may by-pass the staging branches and be delivered directly to release branches such as `master` and `release-*`.
86+
87+## Deprecating/removing packages {#submitting-changes-deprecating-packages}
88+
89+There is currently no policy when to remove a package.
90+
91+Before removing a package, one should try to find a new maintainer or fix smaller issues first.
92+
93+### Steps to remove a package from Nixpkgs {#steps-to-remove-a-package-from-nixpkgs}
94+
95+We use jbidwatcher as an example for a discontinued project here.
96+
97+1. Have Nixpkgs checked out locally and up to date.
98+1. Create a new branch for your change, e.g. `git checkout -b jbidwatcher`
99+1. Remove the actual package including its directory, e.g. `git rm -rf pkgs/applications/misc/jbidwatcher`
100+1. Remove the package from the list of all packages (`pkgs/top-level/all-packages.nix`).
101+1. Add an alias for the package name in `pkgs/top-level/aliases.nix` (There is also `pkgs/applications/editors/vim/plugins/aliases.nix`. Package sets typically do not have aliases, so we can't add them there.)
102+
103+ For example in this case:
104+
105+ ```
106+ jbidwatcher = throw "jbidwatcher was discontinued in march 2021"; # added 2021-03-15
107+ ```
108+
109+ The throw message should explain in short why the package was removed for users that still have it installed.
110+
111+1. Test if the changes introduced any issues by running `nix-env -qaP -f . --show-trace`. It should show the list of packages without errors.
112+1. Commit the changes. Explain again why the package was removed. If it was declared discontinued upstream, add a link to the source.
113+
114+ ```ShellSession
115+ $ git add pkgs/applications/misc/jbidwatcher/default.nix pkgs/top-level/all-packages.nix pkgs/top-level/aliases.nix
116+ $ git commit
117+ ```
118+
119+ Example commit message:
120+
121+ ```
122+ jbidwatcher: remove
123+
124+ project was discontinued in march 2021. the program does not work anymore because ebay changed the login.
125+
126+ https://web.archive.org/web/20210315205723/http://www.jbidwatcher.com/
127+ ```
128+
129+1. Push changes to your GitHub fork with `git push`
130+1. Create a pull request against Nixpkgs. Mention the package maintainer.
131+
132+This is how the pull request looks like in this case: [https://github.com/NixOS/nixpkgs/pull/116470](https://github.com/NixOS/nixpkgs/pull/116470)
133+
134+## Pull Request Template {#submitting-changes-pull-request-template}
135+
136+The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
137+
138+When a PR is created, it will be pre-populated with some checkboxes detailed below:
139+
140+### Tested using sandboxing {#submitting-changes-tested-with-sandbox}
141+
142+When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of `fetch*` functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see [sandbox](https://nixos.org/nix/manual/#conf-sandbox) in Nix manual for details.
143+
144+Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for [nixpkgs](https://github.com/NixOS/nixpkgs/) people are asked to test builds with sandboxing enabled (see `Tested using sandboxing` in the pull request template) because in<https://nixos.org/hydra/> sandboxing is also used.
145+
146+Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing **before** building the package:
147+
148+- **Globally enable sandboxing on NixOS**: add the following to `configuration.nix`
149+
150+ ```nix
151+ nix.useSandbox = true;
152+ ```
153+
154+- **Globally enable sandboxing on non-NixOS platforms**: add the following to: `/etc/nix/nix.conf`
155+
156+ ```ini
157+ sandbox = true
158+ ```
159+
160+### Built on platform(s) {#submitting-changes-platform-diversity}
161+
162+Many Nix packages are designed to run on multiple platforms. As such, it’s important to let the maintainer know which platforms your changes have been tested on. It’s not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
163+
164+### Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests) {#submitting-changes-nixos-tests}
165+
166+Packages with automated tests are much more likely to be merged in a timely fashion because it doesn’t require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests can only be run on Linux. For more details on writing and running tests, see the [section in the NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests).
167+
168+### Tested compilation of all pkgs that depend on this change using `nixpkgs-review` {#submitting-changes-tested-compilation}
169+
170+If you are updating a package’s version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The `nixpkgs-review` utility can look for and build all dependencies either based on uncommited changes with the `wip` option or specifying a github pull request number.
171+
172+review changes from pull request number 12345:
173+
174+```ShellSession
175+nix run nixpkgs.nixpkgs-review -c nixpkgs-review pr 12345
176+```
177+
178+review uncommitted changes:
179+
180+```ShellSession
181+nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip
182+```
183+
184+review changes from last commit:
185+
186+```ShellSession
187+nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD
188+```
189+
190+### Tested execution of all binary files (usually in `./result/bin/`) {#submitting-changes-tested-execution}
191+
192+It’s important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in `./result/bin` and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to texlive, you probably would only check the binaries associated with the change you made rather than testing all of them.
193+
194+### Meets Nixpkgs contribution standards {#submitting-changes-contribution-standards}
195+
196+The last checkbox is fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md). The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc\... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
197+
198+## Hotfixing pull requests {#submitting-changes-hotfixing-pull-requests}
199+
200+- Make the appropriate changes in you branch.
201+- Don’t create additional commits, do
202+ - `git rebase -i`
203+ - `git push --force` to your branch.
204+
205+## Commit policy {#submitting-changes-commit-policy}
206+
207+- Commits must be sufficiently tested before being merged, both for the master and staging branches.
208+- Hydra builds for master and staging should not be used as testing platform, it’s a build farm for changes that have been already tested.
209+- When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people’s installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from \@edolstra.
210+
211+```{.graphviz caption="Staging workflow"}
212+digraph {
213+ "small changes" [shape=none]
214+ "mass-rebuilds and other large changes" [shape=none]
215+ "critical security fixes" [shape=none]
216+ "broken staging-next fixes" [shape=none]
217+
218+ "small changes" -> master
219+ "mass-rebuilds and other large changes" -> staging
220+ "critical security fixes" -> master
221+ "broken staging-next fixes" -> "staging-next"
222+
223+ "staging-next" -> master [color="#E85EB0"] [label="stabilization ends"] [fontcolor="#E85EB0"]
224+ "staging" -> "staging-next" [color="#E85EB0"] [label="stabilization starts"] [fontcolor="#E85EB0"]
225+
226+ master -> "staging-next" -> staging [color="#5F5EE8"] [label="every six hours (GitHub Action)"] [fontcolor="#5F5EE8"]
227+}
228+```
229+
230+[This GitHub Action](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/periodic-merge-6h.yml) brings changes from `master` to `staging-next` and from `staging-next` to `staging` every 6 hours.
231+
232+
233+### Master branch {#submitting-changes-master-branch}
234+
235+The `master` branch is the main development branch. It should only see non-breaking commits that do not cause mass rebuilds.
236+
237+### Staging branch {#submitting-changes-staging-branch}
238+
239+The `staging` branch is a development branch where mass-rebuilds go. It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
240+
241+### Staging-next branch {#submitting-changes-staging-next-branch}
242+
243+The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds must go via the `staging` branch. It must only see non-breaking commits that are fixing issues blocking it from being merged into the `master ` branch.
244+
245+If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
246+
247+### Stable release branches {#submitting-changes-stable-release-branches}
248+
249+The same staging workflow applies to stable release branches, but the main branch is called `release-*` instead of `master`.
250+
251+Example branch names: `release-21.11`, `staging-21.11`, `staging-next-21.11`.
252+
253+Most changes added to the stable release branches are cherry-picked (“backported”) from the `master` and staging branches.
254+
255+#### Automatically backporting a Pull Request {#submitting-changes-stable-release-branches-automatic-backports}
256+
257+Assign label `backport <branch>` (e.g. `backport release-21.11`) to the PR and a backport PR is automatically created after the PR is merged.
258+
259+#### Manually backporting changes {#submitting-changes-stable-release-branches-manual-backports}
260+
261+Cherry-pick changes via `git cherry-pick -x <original commit>` so that the original commit id is included in the commit message.
262+
263+Add a reason for the backport when it is not obvious from the original commit message. You can do this by cherry picking with `git cherry-pick -xe <original commit>`, which allows editing the commit message. This is not needed for minor version updates that include security and bug fixes but don't add new features or when the commit fixes an otherwise broken package.
264+
265+Here is an example of a cherry-picked commit message with good reason description:
266+
267+```
268+zfs: Keep trying root import until it works
269+
270+Works around #11003.
271+
272+(cherry picked from commit 98b213a11041af39b39473906b595290e2a4e2f9)
273+
274+Reason: several people cannot boot with ZFS on NVMe
275+```
276+
277+Other examples of reasons are:
278+
279+- Previously the build would fail due to, e.g., `getaddrinfo` not being defined
280+- The previous download links were all broken
281+- Crash when starting on some X11 systems
282+
283+#### Acceptable backport criteria
284+
285+The stable branch does have some changes which cannot be backported. Most notable are breaking changes. The desire is to have stable users be uninterrupted when updating packages.
286+
287+However, many changes are able to be backported, including:
288+- New Packages / Modules
289+- Security / Patch updates
290+- Version updates which include new functionality (but no breaking changes)
291+- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
292+- Security critical applications (E.g. `firefox`)
doc/contributing/vulnerability-roundup.chapter.mdnew file+45
@@ -0,0 +1,45 @@
1+# Vulnerability Roundup {#chap-vulnerability-roundup}
2+
3+## Issues {#vulnerability-roundup-issues}
4+
5+Vulnerable packages in Nixpkgs are managed using issues.
6+Currently opened ones can be found using the following:
7+
8+[github.com/NixOS/nixpkgs/issues?q=is:issue+is:open+"Vulnerability+roundup"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aissue+is%3Aopen+%22Vulnerability+roundup%22)
9+
10+Each issue correspond to a vulnerable version of a package; As a consequence:
11+
12+- One issue can contain several CVEs;
13+- One CVE can be shared across several issues;
14+- A single package can be concerned by several issues.
15+
16+
17+A "Vulnerability roundup" issue usually respects the following format:
18+
19+```txt
20+<link to relevant package search on search.nix.gsc.io>, <link to relevant files in Nixpkgs on GitHub>
21+
22+<list of related CVEs, their CVSS score, and the impacted NixOS version>
23+
24+<list of the scanned Nixpkgs versions>
25+
26+<list of relevant contributors>
27+```
28+
29+Note that there can be an extra comment containing links to previously reported (and still open) issues for the same package.
30+
31+
32+## Triaging and Fixing {#vulnerability-roundup-triaging-and-fixing}
33+
34+**Note**: An issue can be a "false positive" (i.e. automatically opened, but without the package it refers to being actually vulnerable).
35+If you find such a "false positive", comment on the issue an explanation of why it falls into this category, linking as much information as the necessary to help maintainers double check.
36+
37+If you are investigating a "true positive":
38+
39+- Find the earliest patched version or a code patch in the CVE details;
40+- Is the issue already patched (version up-to-date or patch applied manually) in Nixpkgs's `master` branch?
41+ - **No**:
42+ - [Submit a security fix](#submitting-changes-submitting-security-fixes);
43+ - Once the fix is merged into `master`, [submit the change to the vulnerable release branch(es)](https://nixos.org/manual/nixpkgs/stable/#submitting-changes-stable-release-branches);
44+ - **Yes**: [Backport the change to the vulnerable release branch(es)](https://nixos.org/manual/nixpkgs/stable/#submitting-changes-stable-release-branches).
45+- When the patch has made it into all the relevant branches (`master`, and the vulnerable releases), close the relevant issue(s).
doc/cross-compilation.xmldeleted−468
@@ -1,468 +0,0 @@
1−<chapter xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="chap-cross">
4− <title>Cross-compilation</title>
5− <section xml:id="sec-cross-intro">
6− <title>Introduction</title>
7−
8− <para>
9− "Cross-compilation" means compiling a program on one machine for another type
10− of machine. For example, a typical use of cross-compilation is to compile
11− programs for embedded devices. These devices often don't have the computing
12− power and memory to compile their own programs. One might think that
13− cross-compilation is a fairly niche concern. However, there are significant
14− advantages to rigorously distinguishing between build-time and run-time
15− environments! This applies even when one is developing and deploying on the
16− same machine. Nixpkgs is increasingly adopting the opinion that packages
17− should be written with cross-compilation in mind, and nixpkgs should evaluate
18− in a similar way (by minimizing cross-compilation-specific special cases)
19− whether or not one is cross-compiling.
20− </para>
21−
22− <para>
23− This chapter will be organized in three parts. First, it will describe the
24− basics of how to package software in a way that supports cross-compilation.
25− Second, it will describe how to use Nixpkgs when cross-compiling. Third, it
26− will describe the internal infrastructure supporting cross-compilation.
27− </para>
28− </section>
29−<!--============================================================-->
30− <section xml:id="sec-cross-packaging">
31− <title>Packaging in a cross-friendly manner</title>
32−
33− <section xml:id="sec-cross-platform-parameters">
34− <title>Platform parameters</title>
35−
36− <para>
37− Nixpkgs follows the <link
38− xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions
39− of GNU autoconf</link>. We distinguish between 3 types of platforms when
40− building a derivation: <wordasword>build</wordasword>,
41− <wordasword>host</wordasword>, and <wordasword>target</wordasword>. In
42− summary, <wordasword>build</wordasword> is the platform on which a package
43− is being built, <wordasword>host</wordasword> is the platform on which it
44− will run. The third attribute, <wordasword>target</wordasword>, is relevant
45− only for certain specific compilers and build tools.
46− </para>
47−
48− <para>
49− In Nixpkgs, these three platforms are defined as attribute sets under the
50− names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>,
51− and <literal>targetPlatform</literal>. They are always defined as
52− attributes in the standard environment. That means one can access them
53− like:
54−<programlisting>{ stdenv, fooDep, barDep, .. }: ...stdenv.buildPlatform...</programlisting>
55− .
56− </para>
57−
58− <variablelist>
59− <varlistentry>
60− <term>
61− <varname>buildPlatform</varname>
62− </term>
63− <listitem>
64− <para>
65− The "build platform" is the platform on which a package is built. Once
66− someone has a built package, or pre-built binary package, the build
67− platform should not matter and can be ignored.
68− </para>
69− </listitem>
70− </varlistentry>
71− <varlistentry>
72− <term>
73− <varname>hostPlatform</varname>
74− </term>
75− <listitem>
76− <para>
77− The "host platform" is the platform on which a package will be run. This
78− is the simplest platform to understand, but also the one with the worst
79− name.
80− </para>
81− </listitem>
82− </varlistentry>
83− <varlistentry>
84− <term>
85− <varname>targetPlatform</varname>
86− </term>
87− <listitem>
88− <para>
89− The "target platform" attribute is, unlike the other two attributes, not
90− actually fundamental to the process of building software. Instead, it is
91− only relevant for compatibility with building certain specific compilers
92− and build tools. It can be safely ignored for all other packages.
93− </para>
94− <para>
95− The build process of certain compilers is written in such a way that the
96− compiler resulting from a single build can itself only produce binaries
97− for a single platform. The task of specifying this single "target
98− platform" is thus pushed to build time of the compiler. The root cause of
99− this that the compiler (which will be run on the host) and the standard
100− library/runtime (which will be run on the target) are built by a single
101− build process.
102− </para>
103− <para>
104− There is no fundamental need to think about a single target ahead of
105− time like this. If the tool supports modular or pluggable backends, both
106− the need to specify the target at build time and the constraint of
107− having only a single target disappear. An example of such a tool is
108− LLVM.
109− </para>
110− <para>
111− Although the existence of a "target platfom" is arguably a historical
112− mistake, it is a common one: examples of tools that suffer from it are
113− GCC, Binutils, GHC and Autoconf. Nixpkgs tries to avoid sharing in the
114− mistake where possible. Still, because the concept of a target platform
115− is so ingrained, it is best to support it as is.
116− </para>
117− </listitem>
118− </varlistentry>
119− </variablelist>
120−
121− <para>
122− The exact schema these fields follow is a bit ill-defined due to a long and
123− convoluted evolution, but this is slowly being cleaned up. You can see
124− examples of ones used in practice in
125− <literal>lib.systems.examples</literal>; note how they are not all very
126− consistent. For now, here are few fields can count on them containing:
127− </para>
128−
129− <variablelist>
130− <varlistentry>
131− <term>
132− <varname>system</varname>
133− </term>
134− <listitem>
135− <para>
136− This is a two-component shorthand for the platform. Examples of this
137− would be "x86_64-darwin" and "i686-linux"; see
138− <literal>lib.systems.doubles</literal> for more. The first component
139− corresponds to the CPU architecture of the platform and the second to the
140− operating system of the platform (<literal>[cpu]-[os]</literal>). This
141− format has built-in support in Nix, such as the
142− <varname>builtins.currentSystem</varname> impure string.
143− </para>
144− </listitem>
145− </varlistentry>
146− <varlistentry>
147− <term>
148− <varname>config</varname>
149− </term>
150− <listitem>
151− <para>
152− This is a 3- or 4- component shorthand for the platform. Examples of this
153− would be <literal>x86_64-unknown-linux-gnu</literal> and
154− <literal>aarch64-apple-darwin14</literal>. This is a standard format
155− called the "LLVM target triple", as they are pioneered by LLVM. In the
156− 4-part form, this corresponds to
157− <literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly
158− more informative than the "Nix host double", as the previous format could
159− analogously be termed. This needs a better name than
160− <varname>config</varname>!
161− </para>
162− </listitem>
163− </varlistentry>
164− <varlistentry>
165− <term>
166− <varname>parsed</varname>
167− </term>
168− <listitem>
169− <para>
170− This is a Nix representation of a parsed LLVM target triple
171− with white-listed components. This can be specified directly,
172− or actually parsed from the <varname>config</varname>. See
173− <literal>lib.systems.parse</literal> for the exact
174− representation.
175− </para>
176− </listitem>
177− </varlistentry>
178− <varlistentry>
179− <term>
180− <varname>libc</varname>
181− </term>
182− <listitem>
183− <para>
184− This is a string identifying the standard C library used. Valid
185− identifiers include "glibc" for GNU libc, "libSystem" for Darwin's
186− Libsystem, and "uclibc" for µClibc. It should probably be refactored to
187− use the module system, like <varname>parse</varname>.
188− </para>
189− </listitem>
190− </varlistentry>
191− <varlistentry>
192− <term>
193− <varname>is*</varname>
194− </term>
195− <listitem>
196− <para>
197− These predicates are defined in <literal>lib.systems.inspect</literal>,
198− and slapped onto every platform. They are superior to the ones in
199− <varname>stdenv</varname> as they force the user to be explicit about
200− which platform they are inspecting. Please use these instead of those.
201− </para>
202− </listitem>
203− </varlistentry>
204− <varlistentry>
205− <term>
206− <varname>platform</varname>
207− </term>
208− <listitem>
209− <para>
210− This is, quite frankly, a dumping ground of ad-hoc settings (it's an
211− attribute set). See <literal>lib.systems.platforms</literal> for
212− examples—there's hopefully one in there that will work verbatim for
213− each platform that is working. Please help us triage these flags and
214− give them better homes!
215− </para>
216− </listitem>
217− </varlistentry>
218− </variablelist>
219− </section>
220−
221− <section xml:id="sec-cross-specifying-dependencies">
222− <title>Specifying Dependencies</title>
223−
224− <para>
225− In this section we explore the relationship between both runtime and
226− build-time dependencies and the 3 Autoconf platforms.
227− </para>
228−
229− <para>
230− A runtime dependency between 2 packages implies that between them both the
231− host and target platforms match. This is directly implied by the meaning of
232− "host platform" and "runtime dependency": The package dependency exists
233− while both packages are running on a single host platform.
234− </para>
235−
236− <para>
237− A build time dependency, however, implies a shift in platforms between the
238− depending package and the depended-on package. The meaning of a build time
239− dependency is that to build the depending package we need to be able to run
240− the depended-on's package. The depending package's build platform is
241− therefore equal to the depended-on package's host platform. Analogously,
242− the depending package's host platform is equal to the depended-on package's
243− target platform.
244− </para>
245−
246− <para>
247− In this manner, given the 3 platforms for one package, we can determine the
248− three platforms for all its transitive dependencies. This is the most
249− important guiding principle behind cross-compilation with Nixpkgs, and will
250− be called the <wordasword>sliding window principle</wordasword>.
251− </para>
252−
253− <para>
254− Some examples will make this clearer. If a package is being built with a
255− <literal>(build, host, target)</literal> platform triple of <literal>(foo,
256− bar, bar)</literal>, then its build-time dependencies would have a triple of
257− <literal>(foo, foo, bar)</literal>, and <emphasis>those packages'</emphasis>
258− build-time dependencies would have a triple of <literal>(foo, foo,
259− foo)</literal>. In other words, it should take two "rounds" of following
260− build-time dependency edges before one reaches a fixed point where, by the
261− sliding window principle, the platform triple no longer changes. Indeed,
262− this happens with cross-compilation, where only rounds of native
263− dependencies starting with the second necessarily coincide with native
264− packages.
265− </para>
266−
267− <note>
268− <para>
269− The depending package's target platform is unconstrained by the sliding
270− window principle, which makes sense in that one can in principle build
271− cross compilers targeting arbitrary platforms.
272− </para>
273− </note>
274−
275− <para>
276− How does this work in practice? Nixpkgs is now structured so that build-time
277− dependencies are taken from <varname>buildPackages</varname>, whereas
278− run-time dependencies are taken from the top level attribute set. For
279− example, <varname>buildPackages.gcc</varname> should be used at build-time,
280− while <varname>gcc</varname> should be used at run-time. Now, for most of
281− Nixpkgs's history, there was no <varname>buildPackages</varname>, and most
282− packages have not been refactored to use it explicitly. Instead, one can use
283− the six (<emphasis>gasp</emphasis>) attributes used for specifying
284− dependencies as documented in <xref linkend="ssec-stdenv-dependencies"/>. We
285− "splice" together the run-time and build-time package sets with
286− <varname>callPackage</varname>, and then <varname>mkDerivation</varname> for
287− each of four attributes pulls the right derivation out. This splicing can be
288− skipped when not cross-compiling as the package sets are the same, but is a
289− bit slow for cross-compiling. Because of this, a best-of-both-worlds
290− solution is in the works with no splicing or explicit access of
291− <varname>buildPackages</varname> needed. For now, feel free to use either
292− method.
293− </para>
294−
295− <note>
296− <para>
297− There is also a "backlink" <varname>targetPackages</varname>, yielding a
298− package set whose <varname>buildPackages</varname> is the current package
299− set. This is a hack, though, to accommodate compilers with lousy build
300− systems. Please do not use this unless you are absolutely sure you are
301− packaging such a compiler and there is no other way.
302− </para>
303− </note>
304− </section>
305−
306− <section xml:id="sec-cross-cookbook">
307− <title>Cross packaging cookbook</title>
308−
309− <para>
310− Some frequently encountered problems when packaging for cross-compilation
311− should be answered here. Ideally, the information above is exhaustive, so
312− this section cannot provide any new information, but it is ludicrous and
313− cruel to expect everyone to spend effort working through the interaction of
314− many features just to figure out the same answer to the same common problem.
315− Feel free to add to this list!
316− </para>
317−
318− <qandaset>
319− <qandaentry xml:id="cross-qa-build-c-program-in-build-environment">
320− <question>
321− <para>
322− What if my package's build system needs to build a C program to be run
323− under the build environment?
324− </para>
325− </question>
326− <answer>
327− <para>
328−<programlisting>depsBuildBuild = [ buildPackages.stdenv.cc ];</programlisting>
329− Add it to your <function>mkDerivation</function> invocation.
330− </para>
331− </answer>
332− </qandaentry>
333− <qandaentry xml:id="cross-qa-fails-to-find-ar">
334− <question>
335− <para>
336− My package fails to find <command>ar</command>.
337− </para>
338− </question>
339− <answer>
340− <para>
341− Many packages assume that an unprefixed <command>ar</command> is
342− available, but Nix doesn't provide one. It only provides a prefixed one,
343− just as it only does for all the other binutils programs. It may be
344− necessary to patch the package to fix the build system to use a prefixed
345− `ar`.
346− </para>
347− </answer>
348− </qandaentry>
349− <qandaentry xml:id="cross-testsuite-runs-host-code">
350− <question>
351− <para>
352− My package's testsuite needs to run host platform code.
353− </para>
354− </question>
355− <answer>
356− <para>
357−<programlisting>doCheck = stdenv.hostPlatform != stdenv.buildPlatfrom;</programlisting>
358− Add it to your <function>mkDerivation</function> invocation.
359− </para>
360− </answer>
361− </qandaentry>
362− </qandaset>
363− </section>
364− </section>
365−<!--============================================================-->
366− <section xml:id="sec-cross-usage">
367− <title>Cross-building packages</title>
368−
369− <para>
370− Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in
371− which case there is no cross-compiling and everything is built by and for
372− that system, or also with <varname>crossSystem</varname>, in which case
373− packages run on the latter, but all building happens on the former. Both
374− parameters take the same schema as the 3 (build, host, and target) platforms
375− defined in the previous section. As mentioned above,
376− <literal>lib.systems.examples</literal> has some platforms which are used as
377− arguments for these parameters in practice. You can use them
378− programmatically, or on the command line:
379−<programlisting>
380−nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting>
381− </para>
382−
383− <note>
384− <para>
385− Eventually we would like to make these platform examples an unnecessary
386− convenience so that
387−<programlisting>
388−nix-build <nixpkgs> --arg crossSystem '{ config = "<arch>-<os>-<vendor>-<abi>"; }' -A whatever</programlisting>
389− works in the vast majority of cases. The problem today is dependencies on
390− other sorts of configuration which aren't given proper defaults. We rely on
391− the examples to crudely to set those configuration parameters in some
392− vaguely sane manner on the users behalf. Issue
393− <link xlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link>
394− tracks this inconvenience along with its root cause in crufty configuration
395− options.
396− </para>
397− </note>
398−
399− <para>
400− While one is free to pass both parameters in full, there's a lot of logic to
401− fill in missing fields. As discussed in the previous section, only one of
402− <varname>system</varname>, <varname>config</varname>, and
403− <varname>parsed</varname> is needed to infer the other two. Additionally,
404− <varname>libc</varname> will be inferred from <varname>parse</varname>.
405− Finally, <literal>localSystem.system</literal> is also
406− <emphasis>impurely</emphasis> inferred based on the platform evaluation
407− occurs. This means it is often not necessary to pass
408− <varname>localSystem</varname> at all, as in the command-line example in the
409− previous paragraph.
410− </para>
411−
412− <note>
413− <para>
414− Many sources (manual, wiki, etc) probably mention passing
415− <varname>system</varname>, <varname>platform</varname>, along with the
416− optional <varname>crossSystem</varname> to nixpkgs: <literal>import
417− <nixpkgs> { system = ..; platform = ..; crossSystem = ..;
418− }</literal>. Passing those two instead of <varname>localSystem</varname> is
419− still supported for compatibility, but is discouraged. Indeed, much of the
420− inference we do for these parameters is motivated by compatibility as much
421− as convenience.
422− </para>
423− </note>
424−
425− <para>
426− One would think that <varname>localSystem</varname> and
427− <varname>crossSystem</varname> overlap horribly with the three
428− <varname>*Platforms</varname> (<varname>buildPlatform</varname>,
429− <varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see
430− <varname>stage.nix</varname> or the manual). Actually, those identifiers are
431− purposefully not used here to draw a subtle but important distinction: While
432− the granularity of having 3 platforms is necessary to properly *build*
433− packages, it is overkill for specifying the user's *intent* when making a
434− build plan or package set. A simple "build vs deploy" dichotomy is adequate:
435− the sliding window principle described in the previous section shows how to
436− interpolate between the these two "end points" to get the 3 platform triple
437− for each bootstrapping stage. That means for any package a given package set,
438− even those not bound on the top level but only reachable via dependencies or
439− <varname>buildPackages</varname>, the three platforms will be defined as one
440− of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the
441− former replacing the latter as one traverses build-time dependencies. A last
442− simple difference is that <varname>crossSystem</varname> should be null when
443− one doesn't want to cross-compile, while the <varname>*Platform</varname>s
444− are always non-null. <varname>localSystem</varname> is always non-null.
445− </para>
446− </section>
447−<!--============================================================-->
448− <section xml:id="sec-cross-infra">
449− <title>Cross-compilation infrastructure</title>
450−
451− <para>
452− To be written.
453− </para>
454−
455− <note>
456− <para>
457− If one explores Nixpkgs, they will see derivations with names like
458− <literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is a
459− holdover from before we properly distinguished between the host and target
460− platforms—the derivation with "Cross" in the name covered the <literal>build
461− = host != target</literal> case, while the other covered the <literal>host =
462− target</literal>, with build platform the same or not based on whether one
463− was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>.
464− This ugliness will disappear soon.
465− </para>
466− </note>
467− </section>
468−</chapter>
doc/default.nix+16−27
@@ -1,38 +1,24 @@
11{ pkgs ? (import ./.. { }), nixpkgs ? { }}:
22let
33 lib = pkgs.lib;
4− locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
5−in
6−pkgs.stdenv.mkDerivation {
4+ doc-support = import ./doc-support { inherit pkgs nixpkgs; };
5+in pkgs.stdenv.mkDerivation {
76 name = "nixpkgs-manual";
87
9− buildInputs = with pkgs; [ pandoc libxml2 libxslt zip jing xmlformat ];
10−
11− src = ./.;
12−
13− # Hacking on these variables? Make sure to close and open
14− # nix-shell between each test, maybe even:
15− # $ nix-shell --run "make clean all"
16− # otherwise they won't reapply :)
17− HIGHLIGHTJS = pkgs.documentation-highlighter;
18− XSL = "${pkgs.docbook_xsl_ns}/xml/xsl";
19− RNG = "${pkgs.docbook5}/xml/rng/docbook/docbook.rng";
20− XMLFORMAT_CONFIG = ../nixos/doc/xmlformat.conf;
21− xsltFlags = lib.concatStringsSep " " [
22− "--param section.autolabel 1"
23− "--param section.label.includes.component.label 1"
24− "--stringparam html.stylesheet 'style.css overrides.css highlightjs/mono-blue.css'"
25− "--stringparam html.script './highlightjs/highlight.pack.js ./highlightjs/loader.js'"
26− "--param xref.with.number.and.title 1"
27− "--param toc.section.depth 3"
28− "--stringparam admon.style ''"
29− "--stringparam callout.graphics.extension .svg"
8+ nativeBuildInputs = with pkgs; [
9+ pandoc
10+ graphviz
11+ libxml2
12+ libxslt
13+ zip
14+ jing
15+ xmlformat
3016 ];
3117
18+ src = lib.cleanSource ./.;
19+
3220 postPatch = ''
33− rm -rf ./functions/library/locations.xml
34− ln -s ${locationsXml} ./functions/library/locations.xml
35− echo ${lib.version} > .version
21+ ln -s ${doc-support} ./doc-support/result
3622 '';
3723
3824 installPhase = ''
@@ -47,4 +33,7 @@ pkgs.stdenv.mkDerivation {
4733 echo "doc manual $dest manual.html" >> $out/nix-support/hydra-build-products
4834 echo "doc manual $dest nixpkgs-manual.epub" >> $out/nix-support/hydra-build-products
4935 '';
36+
37+ # Environment variables
38+ PANDOC_LUA_FILTERS_DIR = "${pkgs.pandoc-lua-filters}/share/pandoc/filters";
5039}
doc/doc-support/default.nixnew file+45
@@ -0,0 +1,45 @@
1+{ pkgs ? (import ../.. {}), nixpkgs ? { }}:
2+let
3+ locationsXml = import ./lib-function-locations.nix { inherit pkgs nixpkgs; };
4+ functionDocs = import ./lib-function-docs.nix { inherit locationsXml pkgs; };
5+ version = pkgs.lib.version;
6+
7+ epub-xsl = pkgs.writeText "epub.xsl" ''
8+ <?xml version='1.0'?>
9+ <xsl:stylesheet
10+ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
11+ version="1.0">
12+ <xsl:import href="${pkgs.docbook_xsl_ns}/xml/xsl/docbook/epub/docbook.xsl" />
13+ <xsl:import href="${./parameters.xml}"/>
14+ </xsl:stylesheet>
15+ '';
16+
17+ xhtml-xsl = pkgs.writeText "xhtml.xsl" ''
18+ <?xml version='1.0'?>
19+ <xsl:stylesheet
20+ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
21+ version="1.0">
22+ <xsl:import href="${pkgs.docbook_xsl_ns}/xml/xsl/docbook/xhtml/docbook.xsl" />
23+ <xsl:import href="${./parameters.xml}"/>
24+ </xsl:stylesheet>
25+ '';
26+in pkgs.runCommand "doc-support" {}
27+''
28+ mkdir result
29+ (
30+ cd result
31+ ln -s ${locationsXml} ./function-locations.xml
32+ ln -s ${functionDocs} ./function-docs
33+
34+ ln -s ${pkgs.docbook5}/xml/rng/docbook/docbook.rng ./docbook.rng
35+ ln -s ${pkgs.docbook_xsl_ns}/xml/xsl ./xsl
36+ ln -s ${epub-xsl} ./epub.xsl
37+ ln -s ${xhtml-xsl} ./xhtml.xsl
38+
39+ ln -s ${../../nixos/doc/xmlformat.conf} ./xmlformat.conf
40+ ln -s ${pkgs.documentation-highlighter} ./highlightjs
41+
42+ echo -n "${version}" > ./version
43+ )
44+ mv result $out
45+''
doc/doc-support/lib-function-docs.nixnew file+27
@@ -0,0 +1,27 @@
1+# Generates the documentation for library functons via nixdoc. To add
2+# another library function file to this list, the include list in the
3+# file `doc/functions/library.xml` must also be updated.
4+
5+{ pkgs ? import ./.. {}, locationsXml }:
6+
7+with pkgs; stdenv.mkDerivation {
8+ name = "nixpkgs-lib-docs";
9+ src = ./../../lib;
10+
11+ buildInputs = [ nixdoc ];
12+ installPhase = ''
13+ function docgen {
14+ nixdoc -c "$1" -d "$2" -f "../lib/$1.nix" > "$out/$1.xml"
15+ }
16+
17+ mkdir -p $out
18+ ln -s ${locationsXml} $out/locations.xml
19+
20+ docgen strings 'String manipulation functions'
21+ docgen trivial 'Miscellaneous functions'
22+ docgen lists 'List manipulation functions'
23+ docgen debug 'Debugging functions'
24+ docgen options 'NixOS / nixpkgs option handling'
25+ docgen sources 'Source filtering functions'
26+ '';
27+}
doc/lib-function-locations.nix → doc/doc-support/lib-function-locations.nixrenamed+2−2
@@ -14,10 +14,10 @@ let
1414 builtins.map
1515 (subsetname: {
1616 subsetname = subsetname;
17− functions = libDefPos toplib."${subsetname}";
17+ functions = libDefPos toplib.${subsetname};
1818 })
1919 (builtins.filter
20− (name: builtins.isAttrs toplib."${name}")
20+ (name: builtins.isAttrs toplib.${name})
2121 (builtins.attrNames toplib));
2222
2323 nixpkgsLib = pkgs.lib;
doc/doc-support/parameters.xmlnew file+14
@@ -0,0 +1,14 @@
1+<?xml version='1.0'?>
2+<xsl:stylesheet
3+ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
4+ version="1.0">
5+ <xsl:param name="section.autolabel" select="1" />
6+ <xsl:param name="section.label.includes.component.label" select="1" />
7+ <xsl:param name="html.stylesheet" select="'style.css overrides.css highlightjs/mono-blue.css'" />
8+ <xsl:param name="html.script" select="'./highlightjs/highlight.pack.js ./highlightjs/loader.js'" />
9+ <xsl:param name="xref.with.number.and.title" select="1" />
10+ <xsl:param name="use.id.as.filename" select="1" />
11+ <xsl:param name="toc.section.depth" select="0" />
12+ <xsl:param name="admon.style" select="''" />
13+ <xsl:param name="callout.graphics.extension" select="'.svg'" />
14+</xsl:stylesheet>
doc/functions.xml+5−8
@@ -4,14 +4,11 @@
44 xml:id="chap-functions">
55 <title>Functions reference</title>
66 <para>
7− The nixpkgs repository has several utility functions to manipulate Nix
8− expressions.
7+ The nixpkgs repository has several utility functions to manipulate Nix expressions.
98 </para>
109 <xi:include href="functions/library.xml" />
11− <xi:include href="functions/overrides.xml" />
12− <xi:include href="functions/generators.xml" />
13− <xi:include href="functions/debug.xml" />
14− <xi:include href="functions/fhs-environments.xml" />
15− <xi:include href="functions/shell.xml" />
16− <xi:include href="functions/dockertools.xml" />
10+ <xi:include href="functions/generators.section.xml" />
11+ <xi:include href="functions/debug.section.xml" />
12+ <xi:include href="functions/prefer-remote-fetch.section.xml" />
13+ <xi:include href="functions/nix-gitignore.section.xml" />
1714</chapter>
doc/functions/debug.section.mdnew file+5
@@ -0,0 +1,5 @@
1+# Debugging Nix Expressions {#sec-debug}
2+
3+Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions.
4+
5+In the `lib/debug.nix` file you will find a number of functions that help (pretty-)printing values while evaluation is running. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in `lib/debug.nix` for usage information.
doc/functions/debug.xmldeleted−21
@@ -1,21 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-debug">
5− <title>Debugging Nix Expressions</title>
6−
7− <para>
8− Nix is a unityped, dynamic language, this means every value can potentially
9− appear anywhere. Since it is also non-strict, evaluation order and what
10− ultimately is evaluated might surprise you. Therefore it is important to be
11− able to debug nix expressions.
12− </para>
13−
14− <para>
15− In the <literal>lib/debug.nix</literal> file you will find a number of
16− functions that help (pretty-)printing values while evaluation is runnnig. You
17− can even specify how deep these values should be printed recursively, and
18− transform them on the fly. Please consult the docstrings in
19− <literal>lib/debug.nix</literal> for usage information.
20− </para>
21−</section>
doc/functions/dockertools.xmldeleted−564
@@ -1,564 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-pkgs-dockerTools">
5− <title>pkgs.dockerTools</title>
6−
7− <para>
8− <varname>pkgs.dockerTools</varname> is a set of functions for creating and
9− manipulating Docker images according to the
10− <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120">
11− Docker Image Specification v1.2.0 </link>. Docker itself is not used to
12− perform any of the operations done by these functions.
13− </para>
14−
15− <warning>
16− <para>
17− The <varname>dockerTools</varname> API is unstable and may be subject to
18− backwards-incompatible changes in the future.
19− </para>
20− </warning>
21−
22− <section xml:id="ssec-pkgs-dockerTools-buildImage">
23− <title>buildImage</title>
24−
25− <para>
26− This function is analogous to the <command>docker build</command> command,
27− in that can used to build a Docker-compatible repository tarball containing
28− a single image with one or multiple layers. As such, the result is suitable
29− for being loaded in Docker with <command>docker load</command>.
30− </para>
31−
32− <para>
33− The parameters of <varname>buildImage</varname> with relative example values
34− are described below:
35− </para>
36−
37− <example xml:id='ex-dockerTools-buildImage'>
38− <title>Docker build</title>
39−<programlisting>
40−buildImage {
41− name = "redis"; <co xml:id='ex-dockerTools-buildImage-1' />
42− tag = "latest"; <co xml:id='ex-dockerTools-buildImage-2' />
43−
44− fromImage = someBaseImage; <co xml:id='ex-dockerTools-buildImage-3' />
45− fromImageName = null; <co xml:id='ex-dockerTools-buildImage-4' />
46− fromImageTag = "latest"; <co xml:id='ex-dockerTools-buildImage-5' />
47−
48− contents = pkgs.redis; <co xml:id='ex-dockerTools-buildImage-6' />
49− runAsRoot = '' <co xml:id='ex-dockerTools-buildImage-runAsRoot' />
50− #!${stdenv.shell}
51− mkdir -p /data
52− '';
53−
54− config = { <co xml:id='ex-dockerTools-buildImage-8' />
55− Cmd = [ "/bin/redis-server" ];
56− WorkingDir = "/data";
57− Volumes = {
58− "/data" = {};
59− };
60− };
61−}
62−</programlisting>
63− </example>
64−
65− <para>
66− The above example will build a Docker image <literal>redis/latest</literal>
67− from the given base image. Loading and running this image in Docker results
68− in <literal>redis-server</literal> being started automatically.
69− </para>
70−
71− <calloutlist>
72− <callout arearefs='ex-dockerTools-buildImage-1'>
73− <para>
74− <varname>name</varname> specifies the name of the resulting image. This is
75− the only required argument for <varname>buildImage</varname>.
76− </para>
77− </callout>
78− <callout arearefs='ex-dockerTools-buildImage-2'>
79− <para>
80− <varname>tag</varname> specifies the tag of the resulting image. By
81− default it's <literal>null</literal>, which indicates that the nix output
82− hash will be used as tag.
83− </para>
84− </callout>
85− <callout arearefs='ex-dockerTools-buildImage-3'>
86− <para>
87− <varname>fromImage</varname> is the repository tarball containing the base
88− image. It must be a valid Docker image, such as exported by
89− <command>docker save</command>. By default it's <literal>null</literal>,
90− which can be seen as equivalent to <literal>FROM scratch</literal> of a
91− <filename>Dockerfile</filename>.
92− </para>
93− </callout>
94− <callout arearefs='ex-dockerTools-buildImage-4'>
95− <para>
96− <varname>fromImageName</varname> can be used to further specify the base
97− image within the repository, in case it contains multiple images. By
98− default it's <literal>null</literal>, in which case
99− <varname>buildImage</varname> will peek the first image available in the
100− repository.
101− </para>
102− </callout>
103− <callout arearefs='ex-dockerTools-buildImage-5'>
104− <para>
105− <varname>fromImageTag</varname> can be used to further specify the tag of
106− the base image within the repository, in case an image contains multiple
107− tags. By default it's <literal>null</literal>, in which case
108− <varname>buildImage</varname> will peek the first tag available for the
109− base image.
110− </para>
111− </callout>
112− <callout arearefs='ex-dockerTools-buildImage-6'>
113− <para>
114− <varname>contents</varname> is a derivation that will be copied in the new
115− layer of the resulting image. This can be similarly seen as <command>ADD
116− contents/ /</command> in a <filename>Dockerfile</filename>. By default
117− it's <literal>null</literal>.
118− </para>
119− </callout>
120− <callout arearefs='ex-dockerTools-buildImage-runAsRoot'>
121− <para>
122− <varname>runAsRoot</varname> is a bash script that will run as root in an
123− environment that overlays the existing layers of the base image with the
124− new resulting layer, including the previously copied
125− <varname>contents</varname> derivation. This can be similarly seen as
126− <command>RUN ...</command> in a <filename>Dockerfile</filename>.
127− <note>
128− <para>
129− Using this parameter requires the <literal>kvm</literal> device to be
130− available.
131− </para>
132− </note>
133− </para>
134− </callout>
135− <callout arearefs='ex-dockerTools-buildImage-8'>
136− <para>
137− <varname>config</varname> is used to specify the configuration of the
138− containers that will be started off the built image in Docker. The
139− available options are listed in the
140− <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
141− Docker Image Specification v1.2.0 </link>.
142− </para>
143− </callout>
144− </calloutlist>
145−
146− <para>
147− After the new layer has been created, its closure (to which
148− <varname>contents</varname>, <varname>config</varname> and
149− <varname>runAsRoot</varname> contribute) will be copied in the layer itself.
150− Only new dependencies that are not already in the existing layers will be
151− copied.
152− </para>
153−
154− <para>
155− At the end of the process, only one new single layer will be produced and
156− added to the resulting image.
157− </para>
158−
159− <para>
160− The resulting repository will only list the single image
161− <varname>image/tag</varname>. In the case of
162− <xref linkend='ex-dockerTools-buildImage'/> it would be
163− <varname>redis/latest</varname>.
164− </para>
165−
166− <para>
167− It is possible to inspect the arguments with which an image was built using
168− its <varname>buildArgs</varname> attribute.
169− </para>
170−
171− <note>
172− <para>
173− If you see errors similar to <literal>getProtocolByName: does not exist (no
174− such protocol name: tcp)</literal> you may need to add
175− <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
176− </para>
177− </note>
178−
179− <note>
180− <para>
181− If you see errors similar to <literal>Error_Protocol ("certificate has
182− unknown CA",True,UnknownCa)</literal> you may need to add
183− <literal>pkgs.cacert</literal> to <varname>contents</varname>.
184− </para>
185− </note>
186−
187− <example xml:id="example-pkgs-dockerTools-buildImage-creation-date">
188− <title>Impurely Defining a Docker Layer's Creation Date</title>
189− <para>
190− By default <function>buildImage</function> will use a static date of one
191− second past the UNIX Epoch. This allows <function>buildImage</function> to
192− produce binary reproducible images. When listing images with
193− <command>docker list images</command>, the newly created images will be
194− listed like this:
195− </para>
196−<screen><![CDATA[
197−$ docker image list
198−REPOSITORY TAG IMAGE ID CREATED SIZE
199−hello latest 08c791c7846e 48 years ago 25.2MB
200−]]></screen>
201− <para>
202− You can break binary reproducibility but have a sorted, meaningful
203− <literal>CREATED</literal> column by setting <literal>created</literal> to
204− <literal>now</literal>.
205− </para>
206−<programlisting><![CDATA[
207−pkgs.dockerTools.buildImage {
208− name = "hello";
209− tag = "latest";
210− created = "now";
211− contents = pkgs.hello;
212−
213− config.Cmd = [ "/bin/hello" ];
214−}
215−]]></programlisting>
216− <para>
217− and now the Docker CLI will display a reasonable date and sort the images
218− as expected:
219−<screen><![CDATA[
220−$ docker image list
221−REPOSITORY TAG IMAGE ID CREATED SIZE
222−hello latest de2bf4786de6 About a minute ago 25.2MB
223−]]></screen>
224− however, the produced images will not be binary reproducible.
225− </para>
226− </example>
227− </section>
228−
229− <section xml:id="ssec-pkgs-dockerTools-buildLayeredImage">
230− <title>buildLayeredImage</title>
231−
232− <para>
233− Create a Docker image with many of the store paths being on their own layer
234− to improve sharing between images.
235− </para>
236−
237− <variablelist>
238− <varlistentry>
239− <term>
240− <varname>name</varname>
241− </term>
242− <listitem>
243− <para>
244− The name of the resulting image.
245− </para>
246− </listitem>
247− </varlistentry>
248− <varlistentry>
249− <term>
250− <varname>tag</varname> <emphasis>optional</emphasis>
251− </term>
252− <listitem>
253− <para>
254− Tag of the generated image.
255− </para>
256− <para>
257− <emphasis>Default:</emphasis> the output path's hash
258− </para>
259− </listitem>
260− </varlistentry>
261− <varlistentry>
262− <term>
263− <varname>contents</varname> <emphasis>optional</emphasis>
264− </term>
265− <listitem>
266− <para>
267− Top level paths in the container. Either a single derivation, or a list
268− of derivations.
269− </para>
270− <para>
271− <emphasis>Default:</emphasis> <literal>[]</literal>
272− </para>
273− </listitem>
274− </varlistentry>
275− <varlistentry>
276− <term>
277− <varname>config</varname> <emphasis>optional</emphasis>
278− </term>
279− <listitem>
280− <para>
281− Run-time configuration of the container. A full list of the options are
282− available at in the
283− <link xlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions">
284− Docker Image Specification v1.2.0 </link>.
285− </para>
286− <para>
287− <emphasis>Default:</emphasis> <literal>{}</literal>
288− </para>
289− </listitem>
290− </varlistentry>
291− <varlistentry>
292− <term>
293− <varname>created</varname> <emphasis>optional</emphasis>
294− </term>
295− <listitem>
296− <para>
297− Date and time the layers were created. Follows the same
298− <literal>now</literal> exception supported by
299− <literal>buildImage</literal>.
300− </para>
301− <para>
302− <emphasis>Default:</emphasis> <literal>1970-01-01T00:00:01Z</literal>
303− </para>
304− </listitem>
305− </varlistentry>
306− <varlistentry>
307− <term>
308− <varname>maxLayers</varname> <emphasis>optional</emphasis>
309− </term>
310− <listitem>
311− <para>
312− Maximum number of layers to create.
313− </para>
314− <para>
315− <emphasis>Default:</emphasis> <literal>24</literal>
316− </para>
317− </listitem>
318− </varlistentry>
319− </variablelist>
320−
321− <section xml:id="dockerTools-buildLayeredImage-arg-contents">
322− <title>Behavior of <varname>contents</varname> in the final image</title>
323−
324− <para>
325− Each path directly listed in <varname>contents</varname> will have a
326− symlink in the root of the image.
327− </para>
328−
329− <para>
330− For example:
331−<programlisting><![CDATA[
332−pkgs.dockerTools.buildLayeredImage {
333− name = "hello";
334− contents = [ pkgs.hello ];
335−}
336−]]></programlisting>
337− will create symlinks for all the paths in the <literal>hello</literal>
338− package:
339−<screen><![CDATA[
340−/bin/hello -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/bin/hello
341−/share/info/hello.info -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/info/hello.info
342−/share/locale/bg/LC_MESSAGES/hello.mo -> /nix/store/h1zb1padqbbb7jicsvkmrym3r6snphxg-hello-2.10/share/locale/bg/LC_MESSAGES/hello.mo
343−]]></screen>
344− </para>
345− </section>
346−
347− <section xml:id="dockerTools-buildLayeredImage-arg-config">
348− <title>Automatic inclusion of <varname>config</varname> references</title>
349−
350− <para>
351− The closure of <varname>config</varname> is automatically included in the
352− closure of the final image.
353− </para>
354−
355− <para>
356− This allows you to make very simple Docker images with very little code.
357− This container will start up and run <command>hello</command>:
358−<programlisting><![CDATA[
359−pkgs.dockerTools.buildLayeredImage {
360− name = "hello";
361− config.Cmd = [ "${pkgs.hello}/bin/hello" ];
362−}
363−]]></programlisting>
364− </para>
365− </section>
366−
367− <section xml:id="dockerTools-buildLayeredImage-arg-maxLayers">
368− <title>Adjusting <varname>maxLayers</varname></title>
369−
370− <para>
371− Increasing the <varname>maxLayers</varname> increases the number of layers
372− which have a chance to be shared between different images.
373− </para>
374−
375− <para>
376− Modern Docker installations support up to 128 layers, however older
377− versions support as few as 42.
378− </para>
379−
380− <para>
381− If the produced image will not be extended by other Docker builds, it is
382− safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
383− it will be impossible to extend the image further.
384− </para>
385−
386− <para>
387− The first (<literal>maxLayers-2</literal>) most "popular" paths will have
388− their own individual layers, then layer #<literal>maxLayers-1</literal>
389− will contain all the remaining "unpopular" paths, and finally layer
390− #<literal>maxLayers</literal> will contain the Image configuration.
391− </para>
392−
393− <para>
394− Docker's Layers are not inherently ordered, they are content-addressable
395− and are not explicitly layered until they are composed in to an Image.
396− </para>
397− </section>
398− </section>
399−
400− <section xml:id="ssec-pkgs-dockerTools-fetchFromRegistry">
401− <title>pullImage</title>
402−
403− <para>
404− This function is analogous to the <command>docker pull</command> command, in
405− that can be used to pull a Docker image from a Docker registry. By default
406− <link xlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull
407− images.
408− </para>
409−
410− <para>
411− Its parameters are described in the example below:
412− </para>
413−
414− <example xml:id='ex-dockerTools-pullImage'>
415− <title>Docker pull</title>
416−<programlisting>
417−pullImage {
418− imageName = "nixos/nix"; <co xml:id='ex-dockerTools-pullImage-1' />
419− imageDigest = "sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b"; <co xml:id='ex-dockerTools-pullImage-2' />
420− finalImageTag = "1.11"; <co xml:id='ex-dockerTools-pullImage-3' />
421− sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8"; <co xml:id='ex-dockerTools-pullImage-4' />
422− os = "linux"; <co xml:id='ex-dockerTools-pullImage-5' />
423− arch = "x86_64"; <co xml:id='ex-dockerTools-pullImage-6' />
424−}
425−</programlisting>
426− </example>
427−
428− <calloutlist>
429− <callout arearefs='ex-dockerTools-pullImage-1'>
430− <para>
431− <varname>imageName</varname> specifies the name of the image to be
432− downloaded, which can also include the registry namespace (e.g.
433− <literal>nixos</literal>). This argument is required.
434− </para>
435− </callout>
436− <callout arearefs='ex-dockerTools-pullImage-2'>
437− <para>
438− <varname>imageDigest</varname> specifies the digest of the image to be
439− downloaded. Skopeo can be used to get the digest of an image, with its
440− <varname>inspect</varname> subcommand. Since a given
441− <varname>imageName</varname> may transparently refer to a manifest list of
442− images which support multiple architectures and/or operating systems,
443− supply the `--override-os` and `--override-arch` arguments to specify
444− exactly which image you want. By default it will match the OS and
445− architecture of the host the command is run on.
446−<programlisting>
447−$ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'"
448−sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b
449−</programlisting>
450− This argument is required.
451− </para>
452− </callout>
453− <callout arearefs='ex-dockerTools-pullImage-3'>
454− <para>
455− <varname>finalImageTag</varname>, if specified, this is the tag of the
456− image to be created. Note it is never used to fetch the image since we
457− prefer to rely on the immutable digest ID. By default it's
458− <literal>latest</literal>.
459− </para>
460− </callout>
461− <callout arearefs='ex-dockerTools-pullImage-4'>
462− <para>
463− <varname>sha256</varname> is the checksum of the whole fetched image. This
464− argument is required.
465− </para>
466− </callout>
467− <callout arearefs='ex-dockerTools-pullImage-5'>
468− <para>
469− <varname>os</varname>, if specified, is the operating system of the
470− fetched image. By default it's <literal>linux</literal>.
471− </para>
472− </callout>
473− <callout arearefs='ex-dockerTools-pullImage-6'>
474− <para>
475− <varname>arch</varname>, if specified, is the cpu architecture of the
476− fetched image. By default it's <literal>x86_64</literal>.
477− </para>
478− </callout>
479− </calloutlist>
480− </section>
481−
482− <section xml:id="ssec-pkgs-dockerTools-exportImage">
483− <title>exportImage</title>
484−
485− <para>
486− This function is analogous to the <command>docker export</command> command,
487− in that can used to flatten a Docker image that contains multiple layers. It
488− is in fact the result of the merge of all the layers of the image. As such,
489− the result is suitable for being imported in Docker with <command>docker
490− import</command>.
491− </para>
492−
493− <note>
494− <para>
495− Using this function requires the <literal>kvm</literal> device to be
496− available.
497− </para>
498− </note>
499−
500− <para>
501− The parameters of <varname>exportImage</varname> are the following:
502− </para>
503−
504− <example xml:id='ex-dockerTools-exportImage'>
505− <title>Docker export</title>
506−<programlisting>
507−exportImage {
508− fromImage = someLayeredImage;
509− fromImageName = null;
510− fromImageTag = null;
511−
512− name = someLayeredImage.name;
513−}
514− </programlisting>
515− </example>
516−
517− <para>
518− The parameters relative to the base image have the same synopsis as
519− described in <xref linkend='ssec-pkgs-dockerTools-buildImage'/>, except that
520− <varname>fromImage</varname> is the only required argument in this case.
521− </para>
522−
523− <para>
524− The <varname>name</varname> argument is the name of the derivation output,
525− which defaults to <varname>fromImage.name</varname>.
526− </para>
527− </section>
528−
529− <section xml:id="ssec-pkgs-dockerTools-shadowSetup">
530− <title>shadowSetup</title>
531−
532− <para>
533− This constant string is a helper for setting up the base files for managing
534− users and groups, only if such files don't exist already. It is suitable for
535− being used in a <varname>runAsRoot</varname>
536− <xref linkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
537− in the example below:
538− </para>
539−
540− <example xml:id='ex-dockerTools-shadowSetup'>
541− <title>Shadow base files</title>
542−<programlisting>
543−buildImage {
544− name = "shadow-basic";
545−
546− runAsRoot = ''
547− #!${stdenv.shell}
548− ${shadowSetup}
549− groupadd -r redis
550− useradd -r -g redis redis
551− mkdir /data
552− chown redis:redis /data
553− '';
554−}
555−</programlisting>
556− </example>
557−
558− <para>
559− Creating base files like <literal>/etc/passwd</literal> or
560− <literal>/etc/login.defs</literal> are necessary for shadow-utils to
561− manipulate users and groups.
562− </para>
563− </section>
564−</section>
doc/functions/fhs-environments.xmldeleted−142
@@ -1,142 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-fhs-environments">
5− <title>buildFHSUserEnv</title>
6−
7− <para>
8− <function>buildFHSUserEnv</function> provides a way to build and run
9− FHS-compatible lightweight sandboxes. It creates an isolated root with bound
10− <filename>/nix/store</filename>, so its footprint in terms of disk space
11− needed is quite small. This allows one to run software which is hard or
12− unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
13− games distributed as tarballs, software with integrity checking and/or
14− external self-updated binaries. It uses Linux namespaces feature to create
15− temporary lightweight environments which are destroyed after all child
16− processes exit, without root user rights requirement. Accepted arguments are:
17− </para>
18−
19− <variablelist>
20− <varlistentry>
21− <term>
22− <literal>name</literal>
23− </term>
24− <listitem>
25− <para>
26− Environment name.
27− </para>
28− </listitem>
29− </varlistentry>
30− <varlistentry>
31− <term>
32− <literal>targetPkgs</literal>
33− </term>
34− <listitem>
35− <para>
36− Packages to be installed for the main host's architecture (i.e. x86_64 on
37− x86_64 installations). Along with libraries binaries are also installed.
38− </para>
39− </listitem>
40− </varlistentry>
41− <varlistentry>
42− <term>
43− <literal>multiPkgs</literal>
44− </term>
45− <listitem>
46− <para>
47− Packages to be installed for all architectures supported by a host (i.e.
48− i686 and x86_64 on x86_64 installations). Only libraries are installed by
49− default.
50− </para>
51− </listitem>
52− </varlistentry>
53− <varlistentry>
54− <term>
55− <literal>extraBuildCommands</literal>
56− </term>
57− <listitem>
58− <para>
59− Additional commands to be executed for finalizing the directory structure.
60− </para>
61− </listitem>
62− </varlistentry>
63− <varlistentry>
64− <term>
65− <literal>extraBuildCommandsMulti</literal>
66− </term>
67− <listitem>
68− <para>
69− Like <literal>extraBuildCommands</literal>, but executed only on multilib
70− architectures.
71− </para>
72− </listitem>
73− </varlistentry>
74− <varlistentry>
75− <term>
76− <literal>extraOutputsToInstall</literal>
77− </term>
78− <listitem>
79− <para>
80− Additional derivation outputs to be linked for both target and
81− multi-architecture packages.
82− </para>
83− </listitem>
84− </varlistentry>
85− <varlistentry>
86− <term>
87− <literal>extraInstallCommands</literal>
88− </term>
89− <listitem>
90− <para>
91− Additional commands to be executed for finalizing the derivation with
92− runner script.
93− </para>
94− </listitem>
95− </varlistentry>
96− <varlistentry>
97− <term>
98− <literal>runScript</literal>
99− </term>
100− <listitem>
101− <para>
102− A command that would be executed inside the sandbox and passed all the
103− command line arguments. It defaults to <literal>bash</literal>.
104− </para>
105− </listitem>
106− </varlistentry>
107− </variablelist>
108−
109− <para>
110− One can create a simple environment using a <literal>shell.nix</literal> like
111− that:
112− </para>
113−
114−<programlisting><![CDATA[
115−{ pkgs ? import <nixpkgs> {} }:
116−
117−(pkgs.buildFHSUserEnv {
118− name = "simple-x11-env";
119− targetPkgs = pkgs: (with pkgs;
120− [ udev
121− alsaLib
122− ]) ++ (with pkgs.xorg;
123− [ libX11
124− libXcursor
125− libXrandr
126− ]);
127− multiPkgs = pkgs: (with pkgs;
128− [ udev
129− alsaLib
130− ]);
131− runScript = "bash";
132−}).env
133−]]></programlisting>
134−
135− <para>
136− Running <literal>nix-shell</literal> would then drop you into a shell with
137− these libraries and binaries available. You can use this to run closed-source
138− applications which expect FHS structure without hassles: simply change
139− <literal>runScript</literal> to the application path, e.g.
140− <filename>./bin/start.sh</filename> -- relative paths are supported.
141− </para>
142−</section>
doc/functions/generators.section.mdnew file+56
@@ -0,0 +1,56 @@
1+# Generators {#sec-generators}
2+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`
3+
4+All generators follow a similar call interface: `generatorName configFunctions data`, where `configFunctions` is an attrset of user-defined functions that format nested 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 receives the name of a section and sanitizes it. The default `mkSectionName` escapes `[` and `]` with a backslash.
5+
6+Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses `: ` as separator, the strings `"yes"`/`"no"` as boolean values and requires all string values to be quoted:
7+
8+```nix
9+with lib;
10+let
11+ customToINI = generators.toINI {
12+ # specifies how to format a key/value pair
13+ mkKeyValue = generators.mkKeyValueDefault {
14+ # specifies the generated string for a subset of nix values
15+ mkValueString = v:
16+ if v == true then ''"yes"''
17+ else if v == false then ''"no"''
18+ else if isString v then ''"${v}"''
19+ # and delegats all other values to the default generator
20+ else generators.mkValueStringDefault {} v;
21+ } ":";
22+ };
23+
24+# the INI file can now be given as plain old nix values
25+in customToINI {
26+ main = {
27+ pushinfo = true;
28+ autopush = false;
29+ host = "localhost";
30+ port = 42;
31+ };
32+ mergetool = {
33+ merge = "diff3";
34+ };
35+}
36+```
37+
38+This will produce the following INI file as nix string:
39+
40+```INI
41+[main]
42+autopush:"no"
43+host:"localhost"
44+port:42
45+pushinfo:"yes"
46+str\:ange:"very::strange"
47+
48+[mergetool]
49+merge:"diff3"
50+```
51+
52+::: {.note}
53+Nix store paths can be converted to strings by enclosing a derivation attribute like so: `"${drv}"`.
54+:::
55+
56+Detailed documentation for each generator can be found in `lib/generators.nix`.
doc/functions/generators.xmldeleted−89
@@ -1,89 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-generators">
5− <title>Generators</title>
6−
7− <para>
8− Generators are functions that create file formats from nix data structures,
9− e. g. for configuration files. There are generators available for:
10− <literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
11− </para>
12−
13− <para>
14− All generators follow a similar call interface: <code>generatorName
15− configFunctions data</code>, where <literal>configFunctions</literal> is an
16− attrset of user-defined functions that format nested parts of the content.
17− They each have common defaults, so often they do not need to be set manually.
18− An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
19− name)</code> from the <literal>INI</literal> generator. It receives the name
20− of a section and sanitizes it. The default <literal>mkSectionName</literal>
21− escapes <literal>[</literal> and <literal>]</literal> with a backslash.
22− </para>
23−
24− <para>
25− Generators can be fine-tuned to produce exactly the file format required by
26− your application/service. One example is an INI-file format which uses
27− <literal>: </literal> as separator, the strings
28− <literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
29− requires all string values to be quoted:
30− </para>
31−
32−<programlisting>
33−with lib;
34−let
35− customToINI = generators.toINI {
36− # specifies how to format a key/value pair
37− mkKeyValue = generators.mkKeyValueDefault {
38− # specifies the generated string for a subset of nix values
39− mkValueString = v:
40− if v == true then ''"yes"''
41− else if v == false then ''"no"''
42− else if isString v then ''"${v}"''
43− # and delegats all other values to the default generator
44− else generators.mkValueStringDefault {} v;
45− } ":";
46− };
47−
48−# the INI file can now be given as plain old nix values
49−in customToINI {
50− main = {
51− pushinfo = true;
52− autopush = false;
53− host = "localhost";
54− port = 42;
55− };
56− mergetool = {
57− merge = "diff3";
58− };
59−}
60−</programlisting>
61−
62− <para>
63− This will produce the following INI file as nix string:
64− </para>
65−
66−<programlisting>
67−[main]
68−autopush:"no"
69−host:"localhost"
70−port:42
71−pushinfo:"yes"
72−str\:ange:"very::strange"
73−
74−[mergetool]
75−merge:"diff3"
76−</programlisting>
77−
78− <note>
79− <para>
80− Nix store paths can be converted to strings by enclosing a derivation
81− attribute like so: <code>"${drv}"</code>.
82− </para>
83− </note>
84−
85− <para>
86− Detailed documentation for each generator can be found in
87− <literal>lib/generators.nix</literal>.
88− </para>
89−</section>
doc/functions/library.xml+17−2
@@ -5,11 +5,26 @@
55 <title>Nixpkgs Library Functions</title>
66
77 <para>
8− Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or
9− through <code>import <nixpkgs/lib></code>.
8+ Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import <nixpkgs/lib></code>.
109 </para>
1110
1211 <xi:include href="./library/asserts.xml" />
1312
1413 <xi:include href="./library/attrsets.xml" />
14+
15+<!-- These docs are generated via nixdoc. To add another generated
16+ library function file to this list, the file
17+ `lib-function-docs.nix` must also be updated. -->
18+
19+ <xi:include href="./library/generated/strings.xml" />
20+
21+ <xi:include href="./library/generated/trivial.xml" />
22+
23+ <xi:include href="./library/generated/lists.xml" />
24+
25+ <xi:include href="./library/generated/debug.xml" />
26+
27+ <xi:include href="./library/generated/options.xml" />
28+
29+ <xi:include href="./library/generated/sources.xml" />
1530</section>
doc/functions/library/asserts.xml+5−10
@@ -27,8 +27,7 @@
2727 </term>
2828 <listitem>
2929 <para>
30− Condition under which the <varname>msg</varname> should
31− <emphasis>not</emphasis> be printed.
30+ Condition under which the <varname>msg</varname> should <emphasis>not</emphasis> be printed.
3231 </para>
3332 </listitem>
3433 </varlistentry>
@@ -64,9 +63,7 @@ stderr> assert failed
6463 <xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
6564
6665 <para>
67− Specialized <function>asserts.assertMsg</function> for checking if
68− <varname>val</varname> is one of the elements of <varname>xs</varname>.
69− Useful for checking enums.
66+ Specialized <function>asserts.assertMsg</function> for checking if <varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
7067 </para>
7168
7269 <variablelist>
@@ -76,8 +73,7 @@ stderr> assert failed
7673 </term>
7774 <listitem>
7875 <para>
79− The name of the variable the user entered <varname>val</varname> into,
80− for inclusion in the error message.
76+ The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
8177 </para>
8278 </listitem>
8379 </varlistentry>
@@ -87,8 +83,7 @@ stderr> assert failed
8783 </term>
8884 <listitem>
8985 <para>
90− The value of what the user provided, to be compared against the values in
91− <varname>xs</varname>.
86+ The value of what the user provided, to be compared against the values in <varname>xs</varname>.
9287 </para>
9388 </listitem>
9489 </varlistentry>
@@ -108,7 +103,7 @@ stderr> assert failed
108103 <title>Ensuring a user provided a possible value</title>
109104<programlisting><![CDATA[
110105let sslLibrary = "bearssl";
111−in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "bearssl" ];
106+in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "libressl" ];
112107=> false
113108stderr> trace: sslLibrary must be one of "openssl", "libressl", but is: "bearssl"
114109 ]]></programlisting>
doc/functions/library/attrsets.xml+128−108
@@ -7,7 +7,7 @@
77 <section xml:id="function-library-lib.attrsets.attrByPath">
88 <title><function>lib.attrset.attrByPath</function></title>
99
10− <subtitle><literal>attrByPath :: [String] -> Any -> AttrSet</literal>
10+ <subtitle><literal>attrByPath :: [String] -> Any -> AttrSet -> Any</literal>
1111 </subtitle>
1212
1313 <xi:include href="./locations.xml" xpointer="lib.attrsets.attrByPath" />
@@ -23,8 +23,7 @@
2323 </term>
2424 <listitem>
2525 <para>
26− A list of strings representing the path through the nested attribute set
27− <varname>set</varname>.
26+ A list of strings representing the path through the nested attribute set <varname>set</varname>.
2827 </para>
2928 </listitem>
3029 </varlistentry>
@@ -34,8 +33,7 @@
3433 </term>
3534 <listitem>
3635 <para>
37− Default value if <varname>attrPath</varname> does not resolve to an
38− existing value.
36+ Default value if <varname>attrPath</varname> does not resolve to an existing value.
3937 </para>
4038 </listitem>
4139 </varlistentry>
@@ -88,8 +86,7 @@ lib.attrsets.attrByPath [ "a" "b" ] 0 {}
8886 </term>
8987 <listitem>
9088 <para>
91− A list of strings representing the path through the nested attribute set
92− <varname>set</varname>.
89+ A list of strings representing the path through the nested attribute set <varname>set</varname>.
9390 </para>
9491 </listitem>
9592 </varlistentry>
@@ -125,8 +122,7 @@ lib.attrsets.hasAttrByPath
125122 <xi:include href="./locations.xml" xpointer="lib.attrsets.setAttrByPath" />
126123
127124 <para>
128− Create a new attribute set with <varname>value</varname> set at the nested
129− attribute location specified in <varname>attrPath</varname>.
125+ Create a new attribute set with <varname>value</varname> set at the nested attribute location specified in <varname>attrPath</varname>.
130126 </para>
131127
132128 <variablelist>
@@ -146,8 +142,7 @@ lib.attrsets.hasAttrByPath
146142 </term>
147143 <listitem>
148144 <para>
149− The value to set at the location described by
150− <varname>attrPath</varname>.
145+ The value to set at the location described by <varname>attrPath</varname>.
151146 </para>
152147 </listitem>
153148 </varlistentry>
@@ -171,8 +166,7 @@ lib.attrsets.setAttrByPath [ "a" "b" ] 3
171166 <xi:include href="./locations.xml" xpointer="lib.attrsets.getAttrFromPath" />
172167
173168 <para>
174− Like <xref linkend="function-library-lib.attrsets.attrByPath" /> except
175− without a default, and it will throw if the value doesn't exist.
169+ Like <xref linkend="function-library-lib.attrsets.attrByPath" /> except without a default, and it will throw if the value doesn't exist.
176170 </para>
177171
178172 <variablelist>
@@ -182,8 +176,7 @@ lib.attrsets.setAttrByPath [ "a" "b" ] 3
182176 </term>
183177 <listitem>
184178 <para>
185− A list of strings representing the path through the nested attribute set
186− <varname>set</varname>.
179+ A list of strings representing the path through the nested attribute set <varname>set</varname>.
187180 </para>
188181 </listitem>
189182 </varlistentry>
@@ -235,8 +228,7 @@ lib.attrsets.getAttrFromPath [ "x" "y" ] { }
235228 </term>
236229 <listitem>
237230 <para>
238− The list of attributes to fetch from <varname>set</varname>. Each
239− attribute name must exist on the attrbitue set.
231+ The list of attributes to fetch from <varname>set</varname>. Each attribute name must exist on the attrbitue set.
240232 </para>
241233 </listitem>
242234 </varlistentry>
@@ -282,8 +274,7 @@ error: attribute 'd' missing
282274 </para>
283275
284276 <para>
285− Provides a backwards-compatible interface of
286− <function>builtins.attrValues</function> for Nix version older than 1.8.
277+ Provides a backwards-compatible interface of <function>builtins.attrValues</function> for Nix version older than 1.8.
287278 </para>
288279
289280 <variablelist>
@@ -311,20 +302,17 @@ lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
311302 <section xml:id="function-library-lib.attrsets.catAttrs">
312303 <title><function>lib.attrsets.catAttrs</function></title>
313304
314− <subtitle><literal>catAttrs :: String -> AttrSet -> [Any]</literal>
305+ <subtitle><literal>catAttrs :: String -> [AttrSet] -> [Any]</literal>
315306 </subtitle>
316307
317308 <xi:include href="./locations.xml" xpointer="lib.attrsets.catAttrs" />
318309
319310 <para>
320− Collect each attribute named `attr' from the list of attribute sets,
321− <varname>sets</varname>. Sets that don't contain the named attribute are
322− ignored.
311+ Collect each attribute named `attr' from the list of attribute sets, <varname>sets</varname>. Sets that don't contain the named attribute are ignored.
323312 </para>
324313
325314 <para>
326− Provides a backwards-compatible interface of
327− <function>builtins.catAttrs</function> for Nix version older than 1.9.
315+ Provides a backwards-compatible interface of <function>builtins.catAttrs</function> for Nix version older than 1.9.
328316 </para>
329317
330318 <variablelist>
@@ -334,8 +322,7 @@ lib.attrsets.attrValues { a = 1; b = 2; c = 3; }
334322 </term>
335323 <listitem>
336324 <para>
337− Attribute name to select from each attribute set in
338− <varname>sets</varname>.
325+ Attribute name to select from each attribute set in <varname>sets</varname>.
339326 </para>
340327 </listitem>
341328 </varlistentry>
@@ -372,8 +359,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
372359 <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrs" />
373360
374361 <para>
375− Filter an attribute set by removing all attributes for which the given
376− predicate return false.
362+ Filter an attribute set by removing all attributes for which the given predicate return false.
377363 </para>
378364
379365 <variablelist>
@@ -386,8 +372,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
386372 <literal>String -> Any -> Bool</literal>
387373 </para>
388374 <para>
389− Predicate which returns true to include an attribute, or returns false to
390− exclude it.
375+ Predicate which returns true to include an attribute, or returns false to exclude it.
391376 </para>
392377 <variablelist>
393378 <varlistentry>
@@ -412,8 +397,7 @@ catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
412397 </varlistentry>
413398 </variablelist>
414399 <para>
415− Returns <literal>true</literal> to include the attribute,
416− <literal>false</literal> to exclude the attribute.
400+ Returns <literal>true</literal> to include the attribute, <literal>false</literal> to exclude the attribute.
417401 </para>
418402 </listitem>
419403 </varlistentry>
@@ -447,8 +431,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
447431 <xi:include href="./locations.xml" xpointer="lib.attrsets.filterAttrsRecursive" />
448432
449433 <para>
450− Filter an attribute set recursively by removing all attributes for which the
451− given predicate return false.
434+ Filter an attribute set recursively by removing all attributes for which the given predicate return false.
452435 </para>
453436
454437 <variablelist>
@@ -461,8 +444,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
461444 <literal>String -> Any -> Bool</literal>
462445 </para>
463446 <para>
464− Predicate which returns true to include an attribute, or returns false to
465− exclude it.
447+ Predicate which returns true to include an attribute, or returns false to exclude it.
466448 </para>
467449 <variablelist>
468450 <varlistentry>
@@ -487,8 +469,7 @@ filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
487469 </varlistentry>
488470 </variablelist>
489471 <para>
490− Returns <literal>true</literal> to include the attribute,
491− <literal>false</literal> to exclude the attribute.
472+ Returns <literal>true</literal> to include the attribute, <literal>false</literal> to exclude the attribute.
492473 </para>
493474 </listitem>
494475 </varlistentry>
@@ -557,8 +538,7 @@ lib.attrsets.filterAttrsRecursive
557538 <literal>Any -> Any -> Any</literal>
558539 </para>
559540 <para>
560− Given a value <varname>val</varname> and a collector
561− <varname>col</varname>, combine the two.
541+ Given a value <varname>val</varname> and a collector <varname>col</varname>, combine the two.
562542 </para>
563543 <variablelist>
564544 <varlistentry>
@@ -578,8 +558,7 @@ lib.attrsets.filterAttrsRecursive
578558 <listitem>
579559<!-- TODO: make this not bad, use more fold-ey terms -->
580560 <para>
581− The result of previous <function>op</function> calls with other values
582− and <function>nul</function>.
561+ The result of previous <function>op</function> calls with other values and <function>nul</function>.
583562 </para>
584563 </listitem>
585564 </varlistentry>
@@ -632,9 +611,7 @@ lib.attrsets.foldAttrs
632611 <xi:include href="./locations.xml" xpointer="lib.attrsets.collect" />
633612
634613 <para>
635− Recursively collect sets that verify a given predicate named
636− <varname>pred</varname> from the set <varname>attrs</varname>. The recursion
637− stops when <varname>pred</varname> returns <literal>true</literal>.
614+ Recursively collect sets that verify a given predicate named <varname>pred</varname> from the set <varname>attrs</varname>. The recursion stops when <varname>pred</varname> returns <literal>true</literal>.
638615 </para>
639616
640617 <variablelist>
@@ -702,8 +679,7 @@ collect (x: x ? outPath)
702679 <xi:include href="./locations.xml" xpointer="lib.attrsets.nameValuePair" />
703680
704681 <para>
705− Utility function that creates a <literal>{name, value}</literal> pair as
706− expected by <function>builtins.listToAttrs</function>.
682+ Utility function that creates a <literal>{name, value}</literal> pair as expected by <function>builtins.listToAttrs</function>.
707683 </para>
708684
709685 <variablelist>
@@ -747,13 +723,11 @@ nameValuePair "some" 6
747723 <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs" />
748724
749725 <para>
750− Apply a function to each element in an attribute set, creating a new
751− attribute set.
726+ Apply a function to each element in an attribute set, creating a new attribute set.
752727 </para>
753728
754729 <para>
755− Provides a backwards-compatible interface of
756− <function>builtins.mapAttrs</function> for Nix version older than 2.1.
730+ Provides a backwards-compatible interface of <function>builtins.mapAttrs</function> for Nix version older than 2.1.
757731 </para>
758732
759733 <variablelist>
@@ -798,7 +772,7 @@ nameValuePair "some" 6
798772 <title>Modifying each value of an attribute set</title>
799773<programlisting><![CDATA[
800774lib.attrsets.mapAttrs
801− (name: value: name + "-" value)
775+ (name: value: name + "-" + value)
802776 { x = "foo"; y = "bar"; }
803777=> { x = "x-foo"; y = "y-bar"; }
804778]]></programlisting>
@@ -814,9 +788,7 @@ lib.attrsets.mapAttrs
814788 <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrs-prime" />
815789
816790 <para>
817− Like <function>mapAttrs</function>, but allows the name of each attribute to
818− be changed in addition to the value. The applied function should return both
819− the new name and value as a <function>nameValuePair</function>.
791+ Like <function>mapAttrs</function>, but allows the name of each attribute to be changed in addition to the value. The applied function should return both the new name and value as a <function>nameValuePair</function>.
820792 </para>
821793
822794 <variablelist>
@@ -829,10 +801,8 @@ lib.attrsets.mapAttrs
829801 <literal>String -> Any -> { name = String; value = Any }</literal>
830802 </para>
831803 <para>
832− Given an attribute's name and value, return a new
833− <link
834− linkend="function-library-lib.attrsets.nameValuePair">name
835− value pair</link>.
804+ Given an attribute's name and value, return a new <link
805+ linkend="function-library-lib.attrsets.nameValuePair">name value pair</link>.
836806 </para>
837807 <variablelist>
838808 <varlistentry>
@@ -885,14 +855,13 @@ lib.attrsets.mapAttrs' (name: value: lib.attrsets.nameValuePair ("foo_" + name)
885855 <title><function>lib.attrsets.mapAttrsToList</function></title>
886856
887857 <subtitle><literal>mapAttrsToList :: (String -> Any -> Any) ->
888− AttrSet -> Any</literal>
858+ AttrSet -> [Any]</literal>
889859 </subtitle>
890860
891861 <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsToList" />
892862
893863 <para>
894− Call <varname>fn</varname> for each attribute in the given
895− <varname>set</varname> and return the result in a list.
864+ Call <varname>fn</varname> for each attribute in the given <varname>set</varname> and return the result in a list.
896865 </para>
897866
898867 <variablelist>
@@ -962,9 +931,7 @@ lib.attrsets.mapAttrsToList (name: value: "${name}=${value}")
962931 <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsRecursive" />
963932
964933 <para>
965− Like <function>mapAttrs</function>, except that it recursively applies
966− itself to attribute sets. Also, the first argument of the argument function
967− is a <emphasis>list</emphasis> of the names of the containing attributes.
934+ Like <function>mapAttrs</function>, except that it recursively applies itself to attribute sets. Also, the first argument of the argument function is a <emphasis>list</emphasis> of the names of the containing attributes.
968935 </para>
969936
970937 <variablelist>
@@ -989,10 +956,7 @@ lib.attrsets.mapAttrsToList (name: value: "${name}=${value}")
989956 The list of attribute names to this value.
990957 </para>
991958 <para>
992− For example, the <varname>name_path</varname> for the
993− <literal>example</literal> string in the attribute set <literal>{ foo
994− = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
995− ]</literal>.
959+ For example, the <varname>name_path</varname> for the <literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
996960 </para>
997961 </listitem>
998962 </varlistentry>
@@ -1059,11 +1023,7 @@ mapAttrsRecursive
10591023 <xi:include href="./locations.xml" xpointer="lib.attrsets.mapAttrsRecursiveCond" />
10601024
10611025 <para>
1062− Like <function>mapAttrsRecursive</function>, but it takes an additional
1063− predicate function that tells it whether to recursive into an attribute set.
1064− If it returns false, <function>mapAttrsRecursiveCond</function> does not
1065− recurse, but does apply the map function. It is returns true, it does
1066− recurse, and does not apply the map function.
1026+ Like <function>mapAttrsRecursive</function>, but it takes an additional predicate function that tells it whether to recursive into an attribute set. If it returns false, <function>mapAttrsRecursiveCond</function> does not recurse, but does apply the map function. It is returns true, it does recurse, and does not apply the map function.
10671027 </para>
10681028
10691029 <variablelist>
@@ -1076,8 +1036,7 @@ mapAttrsRecursive
10761036 <literal>(AttrSet -> Bool)</literal>
10771037 </para>
10781038 <para>
1079− Determine if <function>mapAttrsRecursive</function> should recurse deeper
1080− in to the attribute set.
1039+ Determine if <function>mapAttrsRecursive</function> should recurse deeper in to the attribute set.
10811040 </para>
10821041 <variablelist>
10831042 <varlistentry>
@@ -1114,10 +1073,7 @@ mapAttrsRecursive
11141073 The list of attribute names to this value.
11151074 </para>
11161075 <para>
1117− For example, the <varname>name_path</varname> for the
1118− <literal>example</literal> string in the attribute set <literal>{ foo
1119− = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
1120− ]</literal>.
1076+ For example, the <varname>name_path</varname> for the <literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
11211077 </para>
11221078 </listitem>
11231079 </varlistentry>
@@ -1181,8 +1137,7 @@ lib.attrsets.mapAttrsRecursiveCond
11811137 <xi:include href="./locations.xml" xpointer="lib.attrsets.genAttrs" />
11821138
11831139 <para>
1184− Generate an attribute set by mapping a function over a list of attribute
1185− names.
1140+ Generate an attribute set by mapping a function over a list of attribute names.
11861141 </para>
11871142
11881143 <variablelist>
@@ -1241,8 +1196,7 @@ lib.attrsets.genAttrs [ "foo" "bar" ] (name: "x_${name}")
12411196 <xi:include href="./locations.xml" xpointer="lib.attrsets.isDerivation" />
12421197
12431198 <para>
1244− Check whether the argument is a derivation. Any set with <code>{ type =
1245− "derivation"; }</code> counts as a derivation.
1199+ Check whether the argument is a derivation. Any set with <code>{ type = "derivation"; }</code> counts as a derivation.
12461200 </para>
12471201
12481202 <variablelist>
@@ -1320,8 +1274,7 @@ lib.attrsets.isDerivation "foobar"
13201274 </term>
13211275 <listitem>
13221276 <para>
1323− Condition under which the <varname>as</varname> attribute set is
1324− returned.
1277+ Condition under which the <varname>as</varname> attribute set is returned.
13251278 </para>
13261279 </listitem>
13271280 </varlistentry>
@@ -1363,8 +1316,7 @@ lib.attrsets.optionalAttrs false { my = "set"; }
13631316 <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrsWithNames" />
13641317
13651318 <para>
1366− Merge sets of attributes and use the function <varname>f</varname> to merge
1367− attribute values where the attribute name is in <varname>names</varname>.
1319+ Merge sets of attributes and use the function <varname>f</varname> to merge attribute values where the attribute name is in <varname>names</varname>.
13681320 </para>
13691321
13701322 <variablelist>
@@ -1451,11 +1403,8 @@ lib.attrsets.zipAttrsWithNames
14511403 <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrsWith" />
14521404
14531405 <para>
1454− Merge sets of attributes and use the function <varname>f</varname> to merge
1455− attribute values. Similar to
1456− <xref
1457− linkend="function-library-lib.attrsets.zipAttrsWithNames" /> where
1458− all key names are passed for <varname>names</varname>.
1406+ Merge sets of attributes and use the function <varname>f</varname> to merge attribute values. Similar to <xref
1407+ linkend="function-library-lib.attrsets.zipAttrsWithNames" /> where all key names are passed for <varname>names</varname>.
14591408 </para>
14601409
14611410 <variablelist>
@@ -1525,15 +1474,13 @@ lib.attrsets.zipAttrsWith
15251474 <section xml:id="function-library-lib.attrsets.zipAttrs">
15261475 <title><function>lib.attrsets.zipAttrs</function></title>
15271476
1528− <subtitle><literal>zipAttrsWith :: [ AttrSet ] -> AttrSet</literal>
1477+ <subtitle><literal>zipAttrs :: [ AttrSet ] -> AttrSet</literal>
15291478 </subtitle>
15301479
15311480 <xi:include href="./locations.xml" xpointer="lib.attrsets.zipAttrs" />
15321481
15331482 <para>
1534− Merge sets of attributes and combine each attribute value in to a list.
1535− Similar to <xref linkend="function-library-lib.attrsets.zipAttrsWith" />
1536− where the merge function returns a list of all values.
1483+ Merge sets of attributes and combine each attribute value in to a list. Similar to <xref linkend="function-library-lib.attrsets.zipAttrsWith" /> where the merge function returns a list of all values.
15371484 </para>
15381485
15391486 <variablelist>
@@ -1573,12 +1520,7 @@ lib.attrsets.zipAttrs
15731520 <xi:include href="./locations.xml" xpointer="lib.attrsets.recursiveUpdateUntil" />
15741521
15751522 <para>
1576− Does the same as the update operator <literal>//</literal> except that
1577− attributes are merged until the given predicate is verified. The predicate
1578− should accept 3 arguments which are the path to reach the attribute, a part
1579− of the first attribute set and a part of the second attribute set. When the
1580− predicate is verified, the value of the first attribute set is replaced by
1581− the value of the second attribute set.
1523+ Does the same as the update operator <literal>//</literal> except that attributes are merged until the given predicate is verified. The predicate should accept 3 arguments which are the path to reach the attribute, a part of the first attribute set and a part of the second attribute set. When the predicate is verified, the value of the first attribute set is replaced by the value of the second attribute set.
15821524 </para>
15831525
15841526 <variablelist>
@@ -1681,10 +1623,7 @@ lib.attrsets.recursiveUpdateUntil (path: l: r: path == ["foo"])
16811623 <xi:include href="./locations.xml" xpointer="lib.attrsets.recursiveUpdate" />
16821624
16831625 <para>
1684− A recursive variant of the update operator <literal>//</literal>. The
1685− recursion stops when one of the attribute values is not an attribute set, in
1686− which case the right hand side value takes precedence over the left hand
1687− side value.
1626+ A recursive variant of the update operator <literal>//</literal>. 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.
16881627 </para>
16891628
16901629 <variablelist>
@@ -1725,6 +1664,87 @@ recursiveUpdate
17251664 boot.loader.grub.enable = true;
17261665 boot.loader.grub.device = "";
17271666}
1667+]]></programlisting>
1668+ </example>
1669+ </section>
1670+
1671+ <section xml:id="function-library-lib.attrsets.recurseIntoAttrs">
1672+ <title><function>lib.attrsets.recurseIntoAttrs</function></title>
1673+
1674+ <subtitle><literal>recurseIntoAttrs :: AttrSet -> AttrSet</literal>
1675+ </subtitle>
1676+
1677+ <xi:include href="./locations.xml" xpointer="lib.attrsets.recurseIntoAttrs" />
1678+
1679+ <para>
1680+ Make various Nix tools consider the contents of the resulting attribute set when looking for what to build, find, etc.
1681+ </para>
1682+
1683+ <para>
1684+ This function only affects a single attribute set; it does not apply itself recursively for nested attribute sets.
1685+ </para>
1686+
1687+ <variablelist>
1688+ <varlistentry>
1689+ <term>
1690+ <varname>attrs</varname>
1691+ </term>
1692+ <listitem>
1693+ <para>
1694+ An attribute set to scan for derivations.
1695+ </para>
1696+ </listitem>
1697+ </varlistentry>
1698+ </variablelist>
1699+
1700+ <example xml:id="function-library-lib.attrsets.recurseIntoAttrs-example">
1701+ <title>Making Nix look inside an attribute set</title>
1702+<programlisting><![CDATA[
1703+{ pkgs ? import <nixpkgs> {} }:
1704+{
1705+ myTools = pkgs.lib.recurseIntoAttrs {
1706+ inherit (pkgs) hello figlet;
1707+ };
1708+}
1709+]]></programlisting>
1710+ </example>
1711+ </section>
1712+
1713+ <section xml:id="function-library-lib.attrsets.cartesianProductOfSets">
1714+ <title><function>lib.attrsets.cartesianProductOfSets</function></title>
1715+
1716+ <subtitle><literal>cartesianProductOfSets :: AttrSet -> [ AttrSet ]</literal>
1717+ </subtitle>
1718+
1719+ <xi:include href="./locations.xml" xpointer="lib.attrsets.cartesianProductOfSets" />
1720+
1721+ <para>
1722+ Return the cartesian product of attribute set value combinations.
1723+ </para>
1724+
1725+ <variablelist>
1726+ <varlistentry>
1727+ <term>
1728+ <varname>set</varname>
1729+ </term>
1730+ <listitem>
1731+ <para>
1732+ An attribute set with attributes that carry lists of values.
1733+ </para>
1734+ </listitem>
1735+ </varlistentry>
1736+ </variablelist>
1737+
1738+ <example xml:id="function-library-lib.attrsets.cartesianProductOfSets-example">
1739+ <title>Creating the cartesian product of a list of attribute values</title>
1740+<programlisting><![CDATA[
1741+cartesianProductOfSets { a = [ 1 2 ]; b = [ 10 20 ]; }
1742+=> [
1743+ { a = 1; b = 10; }
1744+ { a = 1; b = 20; }
1745+ { a = 2; b = 10; }
1746+ { a = 2; b = 20; }
1747+ ]
17281748]]></programlisting>
17291749 </example>
17301750 </section>
doc/functions/nix-gitignore.section.mdnew file+49
@@ -0,0 +1,49 @@
1+# pkgs.nix-gitignore {#sec-pkgs-nix-gitignore}
2+
3+`pkgs.nix-gitignore` is a function that acts similarly to `builtins.filterSource` but also allows filtering with the help of the gitignore format.
4+
5+## Usage {#sec-pkgs-nix-gitignore-usage}
6+
7+`pkgs.nix-gitignore` exports a number of functions, but you\'ll most likely need either `gitignoreSource` or `gitignoreSourcePure`. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
8+
9+```nix
10+{ pkgs ? import <nixpkgs> {} }:
11+
12+ nix-gitignore.gitignoreSource [] ./source
13+ # Simplest version
14+
15+ nix-gitignore.gitignoreSource "supplemental-ignores\n" ./source
16+ # This one reads the ./source/.gitignore and concats the auxiliary ignores
17+
18+ nix-gitignore.gitignoreSourcePure "ignore-this\nignore-that\n" ./source
19+ # Use this string as gitignore, don't read ./source/.gitignore.
20+
21+ nix-gitignore.gitignoreSourcePure ["ignore-this\nignore-that\n", ~/.gitignore] ./source
22+ # It also accepts a list (of strings and paths) that will be concatenated
23+ # once the paths are turned to strings via readFile.
24+```
25+
26+These functions are derived from the `Filter` functions by setting the first filter argument to `(_: _: true)`:
27+
28+```nix
29+gitignoreSourcePure = gitignoreFilterSourcePure (_: _: true);
30+gitignoreSource = gitignoreFilterSource (_: _: true);
31+```
32+
33+Those filter functions accept the same arguments the `builtins.filterSource` function would pass to its filters, thus `fn: gitignoreFilterSourcePure fn ""` should be extensionally equivalent to `filterSource`. The file is blacklisted if it\'s blacklisted by either your filter or the gitignoreFilter.
34+
35+If you want to make your own filter from scratch, you may use
36+
37+```nix
38+gitignoreFilter = ign: root: filterPattern (gitignoreToPatterns ign) root;
39+```
40+
41+## gitignore files in subdirectories {#sec-pkgs-nix-gitignore-usage-recursive}
42+
43+If you wish to use a filter that would search for .gitignore files in subdirectories, just like git does by default, use this function:
44+
45+```nix
46+gitignoreFilterRecursiveSource = filter: patterns: root:
47+# OR
48+gitignoreRecursiveSource = gitignoreFilterSourcePure (_: _: true);
49+```
doc/functions/overrides.xmldeleted−212
@@ -1,212 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-overrides">
5− <title>Overriding</title>
6−
7− <para>
8− Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g.
9− derivation attributes, the results of derivations.
10− </para>
11−
12− <para>
13− These functions are used to make changes to packages, returning only single
14− packages. <link xlink:href="#chap-overlays">Overlays</link>, on the other
15− hand, can be used to combine the overridden packages across the entire
16− package set of Nixpkgs.
17− </para>
18−
19− <section xml:id="sec-pkg-override">
20− <title><pkg>.override</title>
21−
22− <para>
23− The function <varname>override</varname> is usually available for all the
24− derivations in the nixpkgs expression (<varname>pkgs</varname>).
25− </para>
26−
27− <para>
28− It is used to override the arguments passed to a function.
29− </para>
30−
31− <para>
32− Example usages:
33−<programlisting>pkgs.foo.override { arg1 = val1; arg2 = val2; ... }</programlisting>
34−<!-- TODO: move below programlisting to a new section about extending and overlays
35− and reference it
36− -->
37−<programlisting>
38−import pkgs.path { overlays = [ (self: super: {
39− foo = super.foo.override { barSupport = true ; };
40− })]};
41−</programlisting>
42−<programlisting>
43−mypkg = pkgs.callPackage ./mypkg.nix {
44− mydep = pkgs.mydep.override { ... };
45− }
46−</programlisting>
47− </para>
48−
49− <para>
50− In the first example, <varname>pkgs.foo</varname> is the result of a
51− function call with some default arguments, usually a derivation. Using
52− <varname>pkgs.foo.override</varname> will call the same function with the
53− given new arguments.
54− </para>
55− </section>
56−
57− <section xml:id="sec-pkg-overrideAttrs">
58− <title><pkg>.overrideAttrs</title>
59−
60− <para>
61− The function <varname>overrideAttrs</varname> allows overriding the
62− attribute set passed to a <varname>stdenv.mkDerivation</varname> call,
63− producing a new derivation based on the original one. This function is
64− available on all derivations produced by the
65− <varname>stdenv.mkDerivation</varname> function, which is most packages in
66− the nixpkgs expression <varname>pkgs</varname>.
67− </para>
68−
69− <para>
70− Example usage:
71−<programlisting>
72−helloWithDebug = pkgs.hello.overrideAttrs (oldAttrs: rec {
73− separateDebugInfo = true;
74−});
75−</programlisting>
76− </para>
77−
78− <para>
79− In the above example, the <varname>separateDebugInfo</varname> attribute is
80− overridden to be true, thus building debug info for
81− <varname>helloWithDebug</varname>, while all other attributes will be
82− retained from the original <varname>hello</varname> package.
83− </para>
84−
85− <para>
86− The argument <varname>oldAttrs</varname> is conventionally used to refer to
87− the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
88− </para>
89−
90− <note>
91− <para>
92− Note that <varname>separateDebugInfo</varname> is processed only by the
93− <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix
94− derivation. Thus, using <varname>overrideDerivation</varname> will not work
95− in this case, as it overrides only the attributes of the final derivation.
96− It is for this reason that <varname>overrideAttrs</varname> should be
97− preferred in (almost) all cases to <varname>overrideDerivation</varname>,
98− i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input
99− arguments, as well as the fact that it is easier to use (you can use the
100− same attribute names you see in your Nix code, instead of the ones
101− generated (e.g. <varname>buildInputs</varname> vs
102− <varname>nativeBuildInputs</varname>), and it involves less typing).
103− </para>
104− </note>
105− </section>
106−
107− <section xml:id="sec-pkg-overrideDerivation">
108− <title><pkg>.overrideDerivation</title>
109−
110− <warning>
111− <para>
112− You should prefer <varname>overrideAttrs</varname> in almost all cases, see
113− its documentation for the reasons why.
114− <varname>overrideDerivation</varname> is not deprecated and will continue
115− to work, but is less nice to use and does not have as many abilities as
116− <varname>overrideAttrs</varname>.
117− </para>
118− </warning>
119−
120− <warning>
121− <para>
122− Do not use this function in Nixpkgs as it evaluates a Derivation before
123− modifying it, which breaks package abstraction and removes error-checking
124− of function arguments. In addition, this evaluation-per-function
125− application incurs a performance penalty, which can become a problem if
126− many overrides are used. It is only intended for ad-hoc customisation, such
127− as in <filename>~/.config/nixpkgs/config.nix</filename>.
128− </para>
129− </warning>
130−
131− <para>
132− The function <varname>overrideDerivation</varname> creates a new derivation
133− based on an existing one by overriding the original's attributes with the
134− attribute set produced by the specified function. This function is available
135− on all derivations defined using the <varname>makeOverridable</varname>
136− function. Most standard derivation-producing functions, such as
137− <varname>stdenv.mkDerivation</varname>, are defined using this function,
138− which means most packages in the nixpkgs expression,
139− <varname>pkgs</varname>, have this function.
140− </para>
141−
142− <para>
143− Example usage:
144−<programlisting>
145−mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
146− name = "sed-4.2.2-pre";
147− src = fetchurl {
148− url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
149− sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
150− };
151− patches = [];
152−});
153−</programlisting>
154− </para>
155−
156− <para>
157− In the above example, the <varname>name</varname>, <varname>src</varname>,
158− and <varname>patches</varname> of the derivation will be overridden, while
159− all other attributes will be retained from the original derivation.
160− </para>
161−
162− <para>
163− The argument <varname>oldAttrs</varname> is used to refer to the attribute
164− set of the original derivation.
165− </para>
166−
167− <note>
168− <para>
169− A package's attributes are evaluated *before* being modified by the
170− <varname>overrideDerivation</varname> function. For example, the
171− <varname>name</varname> attribute reference in <varname>url =
172− "mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the
173− <varname>overrideDerivation</varname> function modifies the attribute set.
174− This means that overriding the <varname>name</varname> attribute, in this
175− example, *will not* change the value of the <varname>url</varname>
176− attribute. Instead, we need to override both the <varname>name</varname>
177− *and* <varname>url</varname> attributes.
178− </para>
179− </note>
180− </section>
181−
182− <section xml:id="sec-lib-makeOverridable">
183− <title>lib.makeOverridable</title>
184−
185− <para>
186− The function <varname>lib.makeOverridable</varname> is used to make the
187− result of a function easily customizable. This utility only makes sense for
188− functions that accept an argument set and return an attribute set.
189− </para>
190−
191− <para>
192− Example usage:
193−<programlisting>
194−f = { a, b }: { result = a+b; };
195−c = lib.makeOverridable f { a = 1; b = 2; };
196−</programlisting>
197− </para>
198−
199− <para>
200− The variable <varname>c</varname> is the value of the <varname>f</varname>
201− function applied with some default arguments. Hence the value of
202− <varname>c.result</varname> is <literal>3</literal>, in this example.
203− </para>
204−
205− <para>
206− The variable <varname>c</varname> however also has some additional
207− functions, like <link linkend="sec-pkg-override">c.override</link> which can
208− be used to override the default arguments. In this example the value of
209− <varname>(c.override { a = 4; }).result</varname> is 6.
210− </para>
211− </section>
212−</section>
doc/functions/prefer-remote-fetch.section.mdnew file+17
@@ -0,0 +1,17 @@
1+# prefer-remote-fetch overlay {#sec-prefer-remote-fetch}
2+
3+`prefer-remote-fetch` is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
4+
5+```nix
6+self: super:
7+ (super.prefer-remote-fetch self super)
8+```
9+
10+A full configuration example for that sets the overlay up for your own account, could look like this
11+
12+```ShellSession
13+$ mkdir ~/.config/nixpkgs/overlays/
14+$ cat > ~/.config/nixpkgs/overlays/prefer-remote-fetch.nix <<EOF
15+ self: super: super.prefer-remote-fetch self super
16+EOF
17+```
doc/functions/shell.xmldeleted−26
@@ -1,26 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xmlns:xi="http://www.w3.org/2001/XInclude"
4− xml:id="sec-pkgs-mkShell">
5− <title>pkgs.mkShell</title>
6−
7− <para>
8− <function>pkgs.mkShell</function> is a special kind of derivation that is
9− only useful when using it combined with <command>nix-shell</command>. It will
10− in fact fail to instantiate when invoked with <command>nix-build</command>.
11− </para>
12−
13− <section xml:id="sec-pkgs-mkShell-usage">
14− <title>Usage</title>
15−
16−<programlisting><![CDATA[
17−{ pkgs ? import <nixpkgs> {} }:
18−pkgs.mkShell {
19− # this will make all the build inputs from hello and gnutar
20− # available to the shell environment
21− inputsFrom = with pkgs; [ hello gnutar ];
22− buildInputs = [ pkgs.gnumake ];
23−}
24−]]></programlisting>
25− </section>
26−</section>
doc/hooks/index.xmlnew file+10
@@ -0,0 +1,10 @@
1+<chapter xmlns="http://docbook.org/ns/docbook"
2+ xmlns:xlink="http://www.w3.org/1999/xlink"
3+ xmlns:xi="http://www.w3.org/2001/XInclude"
4+ xml:id="chap-hooks">
5+ <title>Hooks reference</title>
6+ <para>
7+ Nixpkgs has several hook packages that augment the stdenv phases.
8+ </para>
9+ <xi:include href="./postgresql-test-hook.section.xml" />
10+</chapter>
doc/hooks/postgresql-test-hook.section.mdnew file+59
@@ -0,0 +1,59 @@
1+
2+# `postgresqlTestHook` {#sec-postgresqlTestHook}
3+
4+This hook starts a PostgreSQL server during the `checkPhase`. Example:
5+
6+```nix
7+{ stdenv, postgresql, postgresqlTestHook }:
8+stdenv.mkDerivation {
9+
10+ # ...
11+
12+ checkInputs = [
13+ postgresql
14+ postgresqlTestHook
15+ ];
16+}
17+```
18+
19+If you use a custom `checkPhase`, remember to add the `runHook` calls:
20+```nix
21+ checkPhase ''
22+ runHook preCheck
23+
24+ # ... your tests
25+
26+ runHook postCheck
27+ ''
28+```
29+
30+## Variables {#sec-postgresqlTestHook-variables}
31+
32+The hook logic will read a number of variables and set them to a default value if unset or empty.
33+
34+Exported variables:
35+
36+ - `PGDATA`: location of server files.
37+ - `PGHOST`: location of UNIX domain socket directory; the default `host` in a connection string.
38+ - `PGUSER`: user to create / log in with, default: `test_user`.
39+ - `PGDATABASE`: database name, default: `test_db`.
40+
41+Bash-only variables:
42+
43+ - `postgresqlTestUserOptions`: SQL options to use when creating the `$PGUSER` role, default: `LOGIN`.
44+ - `postgresqlTestSetupSQL`: SQL commands to run as database administrator after startup, default: statements that create `$PGUSER` and `$PGDATABASE`.
45+ - `postgresqlTestSetupCommands`: bash commands to run after database start, defaults to running `$postgresqlTestSetupSQL` as database administrator.
46+ - `postgresqlEnableTCP`: set to `1` to enable TCP listening. Flaky; not recommended.
47+ - `postgresqlStartCommands`: defaults to `pg_ctl start`.
48+
49+## TCP and the Nix sandbox {#sec-postgresqlTestHook-tcp}
50+
51+`postgresqlEnableTCP` relies on network sandboxing, which is not available on macOS and some custom Nix installations, resulting in flaky tests.
52+For this reason, it is disabled by default.
53+
54+The preferred solution is to make the test suite use a UNIX domain socket connection. This is the default behavior when no `host` connection parameter is provided.
55+Some test suites hardcode a value for `host` though, so a patch may be required. If you can upstream the patch, you can make `host` default to the `PGHOST` environment variable when set. Otherwise, you can patch it locally to omit the `host` connection string parameter altogether.
56+
57+::: {.note}
58+The error `libpq: failed (could not receive data from server: Connection refused` is generally an indication that the test suite is trying to connect through TCP.
59+:::
doc/introduction.chapter.mddeleted−51
@@ -1,51 +0,0 @@
1−---
2−title: Introduction
3−author: Frederik Rietdijk
4−date: 2015-11-25
5−---
6−
7−# Introduction
8−
9−The Nix Packages collection (Nixpkgs) is a set of thousands of packages for the
10−[Nix package manager](http://nixos.org/nix/), released under a
11−[permissive MIT/X11 license](https://github.com/NixOS/nixpkgs/blob/master/COPYING).
12−Packages are available for several platforms, and can be used with the Nix
13−package manager on most GNU/Linux distributions as well as NixOS.
14−
15−This manual primarily describes how to write packages for the Nix Packages collection
16−(Nixpkgs). Thus it’s mainly for packagers and developers who want to add packages to
17−Nixpkgs. If you like to learn more about the Nix package manager and the Nix
18−expression language, then you are kindly referred to the [Nix manual](http://nixos.org/nix/manual/).
19−
20−## Overview of Nixpkgs
21−
22−Nix expressions describe how to build packages from source and are collected in
23−the [nixpkgs repository](https://github.com/NixOS/nixpkgs). Also included in the
24−collection are Nix expressions for
25−[NixOS modules](http://nixos.org/nixos/manual/index.html#sec-writing-modules).
26−With these expressions the Nix package manager can build binary packages.
27−
28−Packages, including the Nix packages collection, are distributed through
29−[channels](http://nixos.org/nix/manual/#sec-channels). The collection is
30−distributed for users of Nix on non-NixOS distributions through the channel
31−`nixpkgs`. Users of NixOS generally use one of the `nixos-*` channels, e.g.
32−`nixos-16.03`, which includes all packages and modules for the stable NixOS
33−16.03. Stable NixOS releases are generally only given
34−security updates. More up to date packages and modules are available via the
35−`nixos-unstable` channel.
36−
37−Both `nixos-unstable` and `nixpkgs` follow the `master` branch of the Nixpkgs
38−repository, although both do lag the `master` branch by generally
39−[a couple of days](http://howoldis.herokuapp.com/). Updates to a channel are
40−distributed as soon as all tests for that channel pass, e.g.
41−[this table](http://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
42−shows the status of tests for the `nixpkgs` channel.
43−
44−The tests are conducted by a cluster called [Hydra](http://nixos.org/hydra/),
45−which also builds binary packages from the Nix expressions in Nixpkgs for
46−`x86_64-linux`, `i686-linux` and `x86_64-darwin`.
47−The binaries are made available via a [binary cache](https://cache.nixos.org).
48−
49−The current Nix expressions of the channels are available in the
50−[`nixpkgs-channels`](https://github.com/NixOS/nixpkgs-channels) repository,
51−which has branches corresponding to the available channels.
doc/languages-frameworks/agda.section.mdnew file+256
@@ -0,0 +1,256 @@
1+# Agda {#agda}
2+
3+## How to use Agda {#how-to-use-agda}
4+
5+Agda is available as the [agda](https://search.nixos.org/packages?channel=unstable&show=agda&from=0&size=30&sort=relevance&query=agda)
6+package.
7+
8+The `agda` package installs an Agda-wrapper, which calls `agda` with `--library-file`
9+set to a generated library-file within the nix store, this means your library-file in
10+`$HOME/.agda/libraries` will be ignored. By default the agda package installs Agda
11+with no libraries, i.e. the generated library-file is empty. To use Agda with libraries,
12+the `agda.withPackages` function can be used. This function either takes:
13+
14+* A list of packages,
15+* or a function which returns a list of packages when given the `agdaPackages` attribute set,
16+* or an attribute set containing a list of packages and a GHC derivation for compilation (see below).
17+* or an attribute set containing a function which returns a list of packages when given the `agdaPackages` attribute set and a GHC derivation for compilation (see below).
18+
19+For example, suppose we wanted a version of Agda which has access to the standard library. This can be obtained with the expressions:
20+
21+```nix
22+agda.withPackages [ agdaPackages.standard-library ]
23+```
24+
25+or
26+
27+```nix
28+agda.withPackages (p: [ p.standard-library ])
29+```
30+
31+or can be called as in the [Compiling Agda](#compiling-agda) section.
32+
33+If you want to use a different version of a library (for instance a development version)
34+override the `src` attribute of the package to point to your local repository
35+
36+```nix
37+agda.withPackages (p: [
38+ (p.standard-library.overrideAttrs (oldAttrs: {
39+ version = "local version";
40+ src = /path/to/local/repo/agda-stdlib;
41+ }))
42+])
43+```
44+
45+You can also reference a GitHub repository
46+
47+```nix
48+agda.withPackages (p: [
49+ (p.standard-library.overrideAttrs (oldAttrs: {
50+ version = "1.5";
51+ src = fetchFromGitHub {
52+ repo = "agda-stdlib";
53+ owner = "agda";
54+ rev = "v1.5";
55+ sha256 = "16fcb7ssj6kj687a042afaa2gq48rc8abihpm14k684ncihb2k4w";
56+ };
57+ }))
58+])
59+```
60+
61+If you want to use a library not added to Nixpkgs, you can add a
62+dependency to a local library by calling `agdaPackages.mkDerivation`.
63+
64+```nix
65+agda.withPackages (p: [
66+ (p.mkDerivation {
67+ pname = "your-agda-lib";
68+ version = "1.0.0";
69+ src = /path/to/your-agda-lib;
70+ })
71+])
72+```
73+
74+Again you can reference GitHub
75+
76+```nix
77+agda.withPackages (p: [
78+ (p.mkDerivation {
79+ pname = "your-agda-lib";
80+ version = "1.0.0";
81+ src = fetchFromGitHub {
82+ repo = "repo";
83+ owner = "owner";
84+ version = "...";
85+ rev = "...";
86+ sha256 = "...";
87+ };
88+ })
89+])
90+```
91+
92+See [Building Agda Packages](#building-agda-packages) for more information on `mkDerivation`.
93+
94+Agda will not by default use these libraries. To tell Agda to use a library we have some options:
95+
96+* Call `agda` with the library flag:
97+ ```ShellSession
98+ $ agda -l standard-library -i . MyFile.agda
99+ ```
100+* Write a `my-library.agda-lib` file for the project you are working on which may look like:
101+ ```
102+ name: my-library
103+ include: .
104+ depend: standard-library
105+ ```
106+* Create the file `~/.agda/defaults` and add any libraries you want to use by default.
107+
108+More information can be found in the [official Agda documentation on library management](https://agda.readthedocs.io/en/v2.6.1/tools/package-system.html).
109+
110+## Compiling Agda {#compiling-agda}
111+
112+Agda modules can be compiled using the GHC backend with the `--compile` flag. A version of `ghc` with `ieee754` is made available to the Agda program via the `--with-compiler` flag.
113+This can be overridden by a different version of `ghc` as follows:
114+
115+```nix
116+agda.withPackages {
117+ pkgs = [ ... ];
118+ ghc = haskell.compiler.ghcHEAD;
119+}
120+```
121+
122+## Writing Agda packages {#writing-agda-packages}
123+
124+To write a nix derivation for an Agda library, first check that the library has a `*.agda-lib` file.
125+
126+A derivation can then be written using `agdaPackages.mkDerivation`. This has similar arguments to `stdenv.mkDerivation` with the following additions:
127+
128+* `everythingFile` can be used to specify the location of the `Everything.agda` file, defaulting to `./Everything.agda`. If this file does not exist then either it should be patched in or the `buildPhase` should be overridden (see below).
129+* `libraryName` should be the name that appears in the `*.agda-lib` file, defaulting to `pname`.
130+* `libraryFile` should be the file name of the `*.agda-lib` file, defaulting to `${libraryName}.agda-lib`.
131+
132+Here is an example `default.nix`
133+
134+```nix
135+{ nixpkgs ? <nixpkgs> }:
136+with (import nixpkgs {});
137+agdaPackages.mkDerivation {
138+ version = "1.0";
139+ pname = "my-agda-lib";
140+ src = ./.;
141+ buildInputs = [
142+ agdaPackages.standard-library
143+ ];
144+}
145+```
146+
147+### Building Agda packages {#building-agda-packages}
148+
149+The default build phase for `agdaPackages.mkDerivation` simply runs `agda` on the `Everything.agda` file.
150+If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.
151+Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.
152+`agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.
153+
154+### Installing Agda packages {#installing-agda-packages}
155+
156+The default install phase copies Agda source files, Agda interface files (`*.agdai`) and `*.agda-lib` files to the output directory.
157+This can be overridden.
158+
159+By default, Agda sources are files ending on `.agda`, or literate Agda files ending on `.lagda`, `.lagda.tex`, `.lagda.org`, `.lagda.md`, `.lagda.rst`. The list of recognised Agda source extensions can be extended by setting the `extraExtensions` config variable.
160+
161+## Maintaining the Agda package set on Nixpkgs {#maintaining-the-agda-package-set-on-nixpkgs}
162+
163+We are aiming at providing all common Agda libraries as packages on `nixpkgs`,
164+and keeping them up to date.
165+Contributions and maintenance help is always appreciated,
166+but the maintenance effort is typically low since the Agda ecosystem is quite small.
167+
168+The `nixpkgs` Agda package set tries to take up a role similar to that of [Stackage](https://www.stackage.org/) in the Haskell world.
169+It is a curated set of libraries that:
170+
171+1. Always work together.
172+2. Are as up-to-date as possible.
173+
174+While the Haskell ecosystem is huge, and Stackage is highly automatised,
175+the Agda package set is small and can (still) be maintained by hand.
176+
177+### Adding Agda packages to Nixpkgs {#adding-agda-packages-to-nixpkgs}
178+
179+To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
180+
181+```nix
182+{ mkDerivation, standard-library, fetchFromGitHub }:
183+```
184+
185+Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you
186+could use a similar set as in your `default.nix` from [Writing Agda Packages](#writing-agda-packages) with
187+`agdaPackages.mkDerivation` replaced with `mkDerivation`.
188+
189+Here is an example skeleton derivation for iowa-stdlib:
190+
191+```nix
192+mkDerivation {
193+ version = "1.5.0";
194+ pname = "iowa-stdlib";
195+
196+ src = ...
197+
198+ libraryFile = "";
199+ libraryName = "IAL-1.3";
200+
201+ buildPhase = ''
202+ patchShebangs find-deps.sh
203+ make
204+ '';
205+}
206+```
207+
208+This library has a file called `.agda-lib`, and so we give an empty string to `libraryFile` as nothing precedes `.agda-lib` in the filename. This file contains `name: IAL-1.3`, and so we let `libraryName = "IAL-1.3"`. This library does not use an `Everything.agda` file and instead has a Makefile, so there is no need to set `everythingFile` and we set a custom `buildPhase`.
209+
210+When writing an Agda package it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://github.com/agda/agda/issues/4613).
211+
212+In the pull request adding this library,
213+you can test whether it builds correctly by writing in a comment:
214+
215+```
216+@ofborg build agdaPackages.iowa-stdlib
217+```
218+
219+### Maintaining Agda packages
220+
221+As mentioned before, the aim is to have a compatible, and up-to-date package set.
222+These two conditions sometimes exclude each other:
223+For example, if we update `agdaPackages.standard-library` because there was an upstream release,
224+this will typically break many reverse dependencies,
225+i.e. downstream Agda libraries that depend on the standard library.
226+In `nixpkgs` we are typically among the first to notice this,
227+since we have build tests in place to check this.
228+
229+In a pull request updating e.g. the standard library, you should write the following comment:
230+
231+```
232+@ofborg build agdaPackages.standard-library.passthru.tests
233+```
234+
235+This will build all reverse dependencies of the standard library,
236+for example `agdaPackages.agda-categories`, or `agdaPackages.generic`.
237+
238+In some cases it is useful to build _all_ Agda packages.
239+This can be done with the following Github comment:
240+
241+```
242+@ofborg build agda.passthru.tests.allPackages
243+```
244+
245+Sometimes, the builds of the reverse dependencies fail because they have not yet been updated and released.
246+You should drop the maintainers a quick issue notifying them of the breakage,
247+citing the build error (which you can get from the ofborg logs).
248+If you are motivated, you might even send a pull request that fixes it.
249+Usually, the maintainers will answer within a week or two with a new release.
250+Bumping the version of that reverse dependency should be a further commit on your PR.
251+
252+In the rare case that a new release is not to be expected within an acceptable time,
253+simply mark the broken package as broken by setting `meta.broken = true;`.
254+This will exclude it from the build test.
255+It can be added later when it is fixed,
256+and does not hinder the advancement of the whole package set in the meantime.
doc/languages-frameworks/android.section.mdnew file+346
@@ -0,0 +1,346 @@
1+# Android {#android}
2+
3+The Android build environment provides three major features and a number of
4+supporting features.
5+
6+## Deploying an Android SDK installation with plugins {#deploying-an-android-sdk-installation-with-plugins}
7+
8+The first use case is deploying the SDK with a desired set of plugins or subsets
9+of an SDK.
10+
11+```nix
12+with import <nixpkgs> {};
13+
14+let
15+ androidComposition = androidenv.composeAndroidPackages {
16+ toolsVersion = "26.1.1";
17+ platformToolsVersion = "30.0.5";
18+ buildToolsVersions = [ "30.0.3" ];
19+ includeEmulator = false;
20+ emulatorVersion = "30.3.4";
21+ platformVersions = [ "28" "29" "30" ];
22+ includeSources = false;
23+ includeSystemImages = false;
24+ systemImageTypes = [ "google_apis_playstore" ];
25+ abiVersions = [ "armeabi-v7a" "arm64-v8a" ];
26+ cmakeVersions = [ "3.10.2" ];
27+ includeNDK = true;
28+ ndkVersions = ["22.0.7026061"];
29+ useGoogleAPIs = false;
30+ useGoogleTVAddOns = false;
31+ includeExtras = [
32+ "extras;google;gcm"
33+ ];
34+ };
35+in
36+androidComposition.androidsdk
37+```
38+
39+The above function invocation states that we want an Android SDK with the above
40+specified plugin versions. By default, most plugins are disabled. Notable
41+exceptions are the tools, platform-tools and build-tools sub packages.
42+
43+The following parameters are supported:
44+
45+* `toolsVersion`, specifies the version of the tools package to use
46+* `platformsToolsVersion` specifies the version of the `platform-tools` plugin
47+* `buildToolsVersions` specifies the versions of the `build-tools` plugins to
48+ use.
49+* `includeEmulator` specifies whether to deploy the emulator package (`false`
50+ by default). When enabled, the version of the emulator to deploy can be
51+ specified by setting the `emulatorVersion` parameter.
52+* `cmakeVersions` specifies which CMake versions should be deployed.
53+* `includeNDK` specifies that the Android NDK bundle should be included.
54+ Defaults to: `false`.
55+* `ndkVersions` specifies the NDK versions that we want to use. These are linked
56+ under the `ndk` directory of the SDK root, and the first is linked under the
57+ `ndk-bundle` directory.
58+* `ndkVersion` is equivalent to specifying one entry in `ndkVersions`, and
59+ `ndkVersions` overrides this parameter if provided.
60+* `includeExtras` is an array of identifier strings referring to arbitrary
61+ add-on packages that should be installed.
62+* `platformVersions` specifies which platform SDK versions should be included.
63+
64+For each platform version that has been specified, we can apply the following
65+options:
66+
67+* `includeSystemImages` specifies whether a system image for each platform SDK
68+ should be included.
69+* `includeSources` specifies whether the sources for each SDK version should be
70+ included.
71+* `useGoogleAPIs` specifies that for each selected platform version the
72+ Google API should be included.
73+* `useGoogleTVAddOns` specifies that for each selected platform version the
74+ Google TV add-on should be included.
75+
76+For each requested system image we can specify the following options:
77+
78+* `systemImageTypes` specifies what kind of system images should be included.
79+ Defaults to: `default`.
80+* `abiVersions` specifies what kind of ABI version of each system image should
81+ be included. Defaults to: `armeabi-v7a`.
82+
83+Most of the function arguments have reasonable default settings.
84+
85+You can specify license names:
86+
87+* `extraLicenses` is a list of license names.
88+ You can get these names from repo.json or `querypackages.sh licenses`. The SDK
89+ license (`android-sdk-license`) is accepted for you if you set accept_license
90+ to true. If you are doing something like working with preview SDKs, you will
91+ want to add `android-sdk-preview-license` or whichever license applies here.
92+
93+Additionally, you can override the repositories that composeAndroidPackages will
94+pull from:
95+
96+* `repoJson` specifies a path to a generated repo.json file. You can generate this
97+ by running `generate.sh`, which in turn will call into `mkrepo.rb`.
98+* `repoXmls` is an attribute set containing paths to repo XML files. If specified,
99+ it takes priority over `repoJson`, and will trigger a local build writing out a
100+ repo.json to the Nix store based on the given repository XMLs.
101+
102+```nix
103+repoXmls = {
104+ packages = [ ./xml/repository2-1.xml ];
105+ images = [
106+ ./xml/android-sys-img2-1.xml
107+ ./xml/android-tv-sys-img2-1.xml
108+ ./xml/android-wear-sys-img2-1.xml
109+ ./xml/android-wear-cn-sys-img2-1.xml
110+ ./xml/google_apis-sys-img2-1.xml
111+ ./xml/google_apis_playstore-sys-img2-1.xml
112+ ];
113+ addons = [ ./xml/addon2-1.xml ];
114+};
115+```
116+
117+When building the above expression with:
118+
119+```bash
120+$ nix-build
121+```
122+
123+The Android SDK gets deployed with all desired plugin versions.
124+
125+We can also deploy subsets of the Android SDK. For example, to only the
126+`platform-tools` package, you can evaluate the following expression:
127+
128+```nix
129+with import <nixpkgs> {};
130+
131+let
132+ androidComposition = androidenv.composeAndroidPackages {
133+ # ...
134+ };
135+in
136+androidComposition.platform-tools
137+```
138+
139+## Using predefined Android package compositions {#using-predefined-android-package-compositions}
140+
141+In addition to composing an Android package set manually, it is also possible
142+to use a predefined composition that contains all basic packages for a specific
143+Android version, such as version 9.0 (API-level 28).
144+
145+The following Nix expression can be used to deploy the entire SDK with all basic
146+plugins:
147+
148+```nix
149+with import <nixpkgs> {};
150+
151+androidenv.androidPkgs_9_0.androidsdk
152+```
153+
154+It is also possible to use one plugin only:
155+
156+```nix
157+with import <nixpkgs> {};
158+
159+androidenv.androidPkgs_9_0.platform-tools
160+```
161+
162+## Building an Android application {#building-an-android-application}
163+
164+In addition to the SDK, it is also possible to build an Ant-based Android
165+project and automatically deploy all the Android plugins that a project
166+requires.
167+
168+
169+```nix
170+with import <nixpkgs> {};
171+
172+androidenv.buildApp {
173+ name = "MyAndroidApp";
174+ src = ./myappsources;
175+ release = true;
176+
177+ # If release is set to true, you need to specify the following parameters
178+ keyStore = ./keystore;
179+ keyAlias = "myfirstapp";
180+ keyStorePassword = "mykeystore";
181+ keyAliasPassword = "myfirstapp";
182+
183+ # Any Android SDK parameters that install all the relevant plugins that a
184+ # build requires
185+ platformVersions = [ "24" ];
186+
187+ # When we include the NDK, then ndk-build is invoked before Ant gets invoked
188+ includeNDK = true;
189+}
190+```
191+
192+Aside from the app-specific build parameters (`name`, `src`, `release` and
193+keystore parameters), the `buildApp {}` function supports all the function
194+parameters that the SDK composition function (the function shown in the
195+previous section) supports.
196+
197+This build function is particularly useful when it is desired to use
198+[Hydra](https://nixos.org/hydra): the Nix-based continuous integration solution
199+to build Android apps. An Android APK gets exposed as a build product and can be
200+installed on any Android device with a web browser by navigating to the build
201+result page.
202+
203+## Spawning emulator instances {#spawning-emulator-instances}
204+
205+For testing purposes, it can also be quite convenient to automatically generate
206+scripts that spawn emulator instances with all desired configuration settings.
207+
208+An emulator spawn script can be configured by invoking the `emulateApp {}`
209+function:
210+
211+```nix
212+with import <nixpkgs> {};
213+
214+androidenv.emulateApp {
215+ name = "emulate-MyAndroidApp";
216+ platformVersion = "28";
217+ abiVersion = "x86"; # armeabi-v7a, mips, x86_64
218+ systemImageType = "google_apis_playstore";
219+}
220+```
221+
222+Additional flags may be applied to the Android SDK's emulator through the runtime environment variable `$NIX_ANDROID_EMULATOR_FLAGS`.
223+
224+It is also possible to specify an APK to deploy inside the emulator
225+and the package and activity names to launch it:
226+
227+```nix
228+with import <nixpkgs> {};
229+
230+androidenv.emulateApp {
231+ name = "emulate-MyAndroidApp";
232+ platformVersion = "24";
233+ abiVersion = "armeabi-v7a"; # mips, x86, x86_64
234+ systemImageType = "default";
235+ useGoogleAPIs = false;
236+ app = ./MyApp.apk;
237+ package = "MyApp";
238+ activity = "MainActivity";
239+}
240+```
241+
242+In addition to prebuilt APKs, you can also bind the APK parameter to a
243+`buildApp {}` function invocation shown in the previous example.
244+
245+## Notes on environment variables in Android projects {#notes-on-environment-variables-in-android-projects}
246+
247+* `ANDROID_SDK_ROOT` should point to the Android SDK. In your Nix expressions, this should be
248+ `${androidComposition.androidsdk}/libexec/android-sdk`. Note that `ANDROID_HOME` is deprecated,
249+ but if you rely on tools that need it, you can export it too.
250+* `ANDROID_NDK_ROOT` should point to the Android NDK, if you're doing NDK development.
251+ In your Nix expressions, this should be `${ANDROID_SDK_ROOT}/ndk-bundle`.
252+
253+If you are running the Android Gradle plugin, you need to export GRADLE_OPTS to override aapt2
254+to point to the aapt2 binary in the Nix store as well, or use a FHS environment so the packaged
255+aapt2 can run. If you don't want to use a FHS environment, something like this should work:
256+
257+```nix
258+let
259+ buildToolsVersion = "30.0.3";
260+
261+ # Use buildToolsVersion when you define androidComposition
262+ androidComposition = <...>;
263+in
264+pkgs.mkShell rec {
265+ ANDROID_SDK_ROOT = "${androidComposition.androidsdk}/libexec/android-sdk";
266+ ANDROID_NDK_ROOT = "${ANDROID_SDK_ROOT}/ndk-bundle";
267+
268+ # Use the same buildToolsVersion here
269+ GRADLE_OPTS = "-Dorg.gradle.project.android.aapt2FromMavenOverride=${ANDROID_SDK_ROOT}/build-tools/${buildToolsVersion}/aapt2";
270+}
271+```
272+
273+If you are using cmake, you need to add it to PATH in a shell hook or FHS env profile.
274+The path is suffixed with a build number, but properly prefixed with the version.
275+So, something like this should suffice:
276+
277+```nix
278+let
279+ cmakeVersion = "3.10.2";
280+
281+ # Use cmakeVersion when you define androidComposition
282+ androidComposition = <...>;
283+in
284+pkgs.mkShell rec {
285+ ANDROID_SDK_ROOT = "${androidComposition.androidsdk}/libexec/android-sdk";
286+ ANDROID_NDK_ROOT = "${ANDROID_SDK_ROOT}/ndk-bundle";
287+
288+ # Use the same cmakeVersion here
289+ shellHook = ''
290+ export PATH="$(echo "$ANDROID_SDK_ROOT/cmake/${cmakeVersion}".*/bin):$PATH"
291+ '';
292+}
293+```
294+
295+Note that running Android Studio with ANDROID_SDK_ROOT set will automatically write a
296+`local.properties` file with `sdk.dir` set to $ANDROID_SDK_ROOT if one does not already
297+exist. If you are using the NDK as well, you may have to add `ndk.dir` to this file.
298+
299+An example shell.nix that does all this for you is provided in examples/shell.nix.
300+This shell.nix includes a shell hook that overwrites local.properties with the correct
301+sdk.dir and ndk.dir values. This will ensure that the SDK and NDK directories will
302+both be correct when you run Android Studio inside nix-shell.
303+
304+## Notes on improving build.gradle compatibility {#notes-on-improving-build.gradle-compatibility}
305+
306+Ensure that your buildToolsVersion and ndkVersion match what is declared in androidenv.
307+If you are using cmake, make sure its declared version is correct too.
308+
309+Otherwise, you may get cryptic errors from aapt2 and the Android Gradle plugin warning
310+that it cannot install the build tools because the SDK directory is not writeable.
311+
312+```gradle
313+android {
314+ buildToolsVersion "30.0.3"
315+ ndkVersion = "22.0.7026061"
316+ externalNativeBuild {
317+ cmake {
318+ version "3.10.2"
319+ }
320+ }
321+}
322+
323+```
324+
325+## Querying the available versions of each plugin {#querying-the-available-versions-of-each-plugin}
326+
327+repo.json provides all the options in one file now.
328+
329+A shell script in the `pkgs/development/mobile/androidenv/` subdirectory can be used to retrieve all
330+possible options:
331+
332+```bash
333+./querypackages.sh packages
334+```
335+
336+The above command-line instruction queries all package versions in repo.json.
337+
338+## Updating the generated expressions {#updating-the-generated-expressions}
339+
340+repo.json is generated from XML files that the Android Studio package manager uses.
341+To update the expressions run the `generate.sh` script that is stored in the
342+`pkgs/development/mobile/androidenv/` subdirectory:
343+
344+```bash
345+./generate.sh
346+```
doc/languages-frameworks/beam.section.mdnew file+373
@@ -0,0 +1,373 @@
1+# BEAM Languages (Erlang, Elixir & LFE) {#sec-beam}
2+
3+## Introduction {#beam-introduction}
4+
5+In this document and related Nix expressions, we use the term, _BEAM_, to describe the environment. BEAM is the name of the Erlang Virtual Machine and, as far as we're concerned, from a packaging perspective, all languages that run on the BEAM are interchangeable. That which varies, like the build system, is transparent to users of any given BEAM package, so we make no distinction.
6+
7+## Available versions and deprecations schedule {#available-versions-and-deprecations-schedule}
8+
9+### Elixir {#elixir}
10+
11+nixpkgs follows the [official elixir deprecation schedule](https://hexdocs.pm/elixir/compatibility-and-deprecations.html) and keeps the last 5 released versions of Elixir available.
12+
13+## Structure {#beam-structure}
14+
15+All BEAM-related expressions are available via the top-level `beam` attribute, which includes:
16+
17+- `interpreters`: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (`beam.interpreters.erlangR22`, etc), Elixir (`beam.interpreters.elixir`) and LFE (Lisp Flavoured Erlang) (`beam.interpreters.lfe`).
18+
19+- `packages`: a set of package builders (Mix and rebar3), each compiled with a specific Erlang/OTP version, e.g. `beam.packages.erlang22`.
20+
21+The default Erlang compiler, defined by `beam.interpreters.erlang`, is aliased as `erlang`. The default BEAM package set is defined by `beam.packages.erlang` and aliased at the top level as `beamPackages`.
22+
23+To create a package builder built with a custom Erlang version, use the lambda, `beam.packagesWith`, which accepts an Erlang/OTP derivation and produces a package builder similar to `beam.packages.erlang`.
24+
25+Many Erlang/OTP distributions available in `beam.interpreters` have versions with ODBC and/or Java enabled or without wx (no observer support). For example, there's `beam.interpreters.erlangR22_odbc_javac`, which corresponds to `beam.interpreters.erlangR22` and `beam.interpreters.erlangR22_nox`, which corresponds to `beam.interpreters.erlangR22`.
26+
27+## Build Tools {#build-tools}
28+
29+### Rebar3 {#build-tools-rebar3}
30+
31+We provide a version of Rebar3, under `rebar3`. We also provide a helper to fetch Rebar3 dependencies from a lockfile under `fetchRebar3Deps`.
32+
33+We also provide a version on Rebar3 with plugins included, under `rebar3WithPlugins`. This package is a function which takes two arguments: `plugins`, a list of nix derivations to include as plugins (loaded only when specified in `rebar.config`), and `globalPlugins`, which should always be loaded by rebar3. Example: `rebar3WithPlugins { globalPlugins = [beamPackages.pc]; }`.
34+
35+When adding a new plugin it is important that the `packageName` attribute is the same as the atom used by rebar3 to refer to the plugin.
36+
37+### Mix & Erlang.mk {#build-tools-other}
38+
39+Erlang.mk works exactly as expected. There is a bootstrap process that needs to be run, which is supported by the `buildErlangMk` derivation.
40+
41+For Elixir applications use `mixRelease` to make a release. See examples for more details.
42+
43+There is also a `buildMix` helper, whose behavior is closer to that of `buildErlangMk` and `buildRebar3`. The primary difference is that mixRelease makes a release, while buildMix only builds the package, making it useful for libraries and other dependencies.
44+
45+## How to Install BEAM Packages {#how-to-install-beam-packages}
46+
47+BEAM builders are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. To install any of those builders into your profile, refer to them by their attribute path `beamPackages.rebar3`:
48+
49+```ShellSession
50+$ nix-env -f "<nixpkgs>" -iA beamPackages.rebar3
51+```
52+
53+## Packaging BEAM Applications {#packaging-beam-applications}
54+
55+### Erlang Applications {#packaging-erlang-applications}
56+
57+#### Rebar3 Packages {#rebar3-packages}
58+
59+The Nix function, `buildRebar3`, defined in `beam.packages.erlang.buildRebar3` and aliased at the top level, can be used to build a derivation that understands how to build a Rebar3 project.
60+
61+If a package needs to compile native code via Rebar3's port compilation mechanism, add `compilePort = true;` to the derivation.
62+
63+#### Erlang.mk Packages {#erlang-mk-packages}
64+
65+Erlang.mk functions similarly to Rebar3, except we use `buildErlangMk` instead of `buildRebar3`.
66+
67+#### Mix Packages {#mix-packages}
68+
69+`mixRelease` is used to make a release in the mix sense. Dependencies will need to be fetched with `fetchMixDeps` and passed to it.
70+
71+#### mixRelease - Elixir Phoenix example {#mix-release-elixir-phoenix-example}
72+
73+there are 3 steps, frontend dependencies (javascript), backend dependencies (elixir) and the final derivation that puts both of those together
74+
75+##### mixRelease - Frontend dependencies (javascript) {#mix-release-javascript-deps}
76+
77+For phoenix projects, inside of nixpkgs you can either use yarn2nix (mkYarnModule) or node2nix. An example with yarn2nix can be found [here](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39). An example with node2nix will follow. To package something outside of nixpkgs, you have alternatives like [npmlock2nix](https://github.com/nix-community/npmlock2nix) or [nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage)
78+
79+##### mixRelease - backend dependencies (mix) {#mix-release-mix-deps}
80+
81+There are 2 ways to package backend dependencies. With mix2nix and with a fixed-output-derivation (FOD).
82+
83+###### mix2nix {#mix2nix}
84+
85+`mix2nix` is a cli tool available in nixpkgs. it will generate a nix expression from a mix.lock file. It is quite standard in the 2nix tool series.
86+
87+Note that currently mix2nix can't handle git dependencies inside the mix.lock file. If you have git dependencies, you can either add them manually (see [example](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/pleroma/default.nix#L20)) or use the FOD method.
88+
89+The advantage of using mix2nix is that nix will know your whole dependency graph. On a dependency update, this won't trigger a full rebuild and download of all the dependencies, where FOD will do so.
90+
91+Practical steps:
92+
93+- run `mix2nix > mix_deps.nix` in the upstream repo.
94+- pass `mixNixDeps = with pkgs; import ./mix_deps.nix { inherit lib beamPackages; };` as an argument to mixRelease.
95+
96+If there are git depencencies.
97+
98+- You'll need to fix the version artificially in mix.exs and regenerate the mix.lock with fixed version (on upstream). This will enable you to run `mix2nix > mix_deps.nix`.
99+- From the mix_deps.nix file, remove the dependencies that had git versions and pass them as an override to the import function.
100+
101+```nix
102+ mixNixDeps = import ./mix.nix {
103+ inherit beamPackages lib;
104+ overrides = (final: prev: {
105+ # mix2nix does not support git dependencies yet,
106+ # so we need to add them manually
107+ prometheus_ex = beamPackages.buildMix rec {
108+ name = "prometheus_ex";
109+ version = "3.0.5";
110+
111+ # Change the argument src with the git src that you actually need
112+ src = fetchFromGitLab {
113+ domain = "git.pleroma.social";
114+ group = "pleroma";
115+ owner = "elixir-libraries";
116+ repo = "prometheus.ex";
117+ rev = "a4e9beb3c1c479d14b352fd9d6dd7b1f6d7deee5";
118+ sha256 = "1v0q4bi7sb253i8q016l7gwlv5562wk5zy3l2sa446csvsacnpjk";
119+ };
120+ # you can re-use the same beamDeps argument as generated
121+ beamDeps = with final; [ prometheus ];
122+ };
123+ });
124+};
125+```
126+
127+You will need to run the build process once to fix the sha256 to correspond to your new git src.
128+
129+###### FOD {#fixed-output-derivation}
130+
131+A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [elixir_ls](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/beam-modules/elixir_ls.nix) for a usage example of FOD.
132+
133+Practical steps
134+
135+- start with the following argument to mixRelease
136+
137+```nix
138+ mixFodDeps = fetchMixDeps {
139+ pname = "mix-deps-${pname}";
140+ inherit src version;
141+ sha256 = lib.fakeSha256;
142+ };
143+```
144+
145+The first build will complain about the sha256 value, you can replace with the suggested value after that.
146+
147+Note that if after you've replaced the value, nix suggests another sha256, then mix is not fetching the dependencies reproducibly. An FOD will not work in that case and you will have to use mix2nix.
148+
149+##### mixRelease - example {#mix-release-example}
150+
151+Here is how your `default.nix` file would look for a phoenix project.
152+
153+```nix
154+with import <nixpkgs> { };
155+
156+let
157+ # beam.interpreters.erlangR23 is available if you need a particular version
158+ packages = beam.packagesWith beam.interpreters.erlang;
159+
160+ pname = "your_project";
161+ version = "0.0.1";
162+
163+ src = builtins.fetchgit {
164+ url = "ssh://git@github.com/your_id/your_repo";
165+ rev = "replace_with_your_commit";
166+ };
167+
168+ # if using mix2nix you can use the mixNixDeps attribute
169+ mixFodDeps = packages.fetchMixDeps {
170+ pname = "mix-deps-${pname}";
171+ inherit src version;
172+ # nix will complain and tell you the right value to replace this with
173+ sha256 = lib.fakeSha256;
174+ # if you have build time environment variables add them here
175+ MY_ENV_VAR="my_value";
176+ };
177+
178+ nodeDependencies = (pkgs.callPackage ./assets/default.nix { }).shell.nodeDependencies;
179+
180+in packages.mixRelease {
181+ inherit src pname version mixFodDeps;
182+ # if you have build time environment variables add them here
183+ MY_ENV_VAR="my_value";
184+
185+ postBuild = ''
186+ ln -sf ${nodeDependencies}/lib/node_modules assets/node_modules
187+ npm run deploy --prefix ./assets
188+
189+ # for external task you need a workaround for the no deps check flag
190+ # https://github.com/phoenixframework/phoenix/issues/2690
191+ mix do deps.loadpaths --no-deps-check, phx.digest
192+ mix phx.digest --no-deps-check
193+ '';
194+}
195+```
196+
197+Setup will require the following steps:
198+
199+- Move your secrets to runtime environment variables. For more information refer to the [runtime.exs docs](https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-runtime-configuration). On a fresh Phoenix build that would mean that both `DATABASE_URL` and `SECRET_KEY` need to be moved to `runtime.exs`.
200+- `cd assets` and `nix-shell -p node2nix --run node2nix --development` will generate a Nix expression containing your frontend dependencies
201+- commit and push those changes
202+- you can now `nix-build .`
203+- To run the release, set the `RELEASE_TMP` environment variable to a directory that your program has write access to. It will be used to store the BEAM settings.
204+
205+#### Example of creating a service for an Elixir - Phoenix project {#example-of-creating-a-service-for-an-elixir---phoenix-project}
206+
207+In order to create a service with your release, you could add a `service.nix`
208+in your project with the following
209+
210+```nix
211+{config, pkgs, lib, ...}:
212+
213+let
214+ release = pkgs.callPackage ./default.nix;
215+ release_name = "app";
216+ working_directory = "/home/app";
217+in
218+{
219+ systemd.services.${release_name} = {
220+ wantedBy = [ "multi-user.target" ];
221+ after = [ "network.target" "postgresql.service" ];
222+ # note that if you are connecting to a postgres instance on a different host
223+ # postgresql.service should not be included in the requires.
224+ requires = [ "network-online.target" "postgresql.service" ];
225+ description = "my app";
226+ environment = {
227+ # RELEASE_TMP is used to write the state of the
228+ # VM configuration when the system is running
229+ # it needs to be a writable directory
230+ RELEASE_TMP = working_directory;
231+ # can be generated in an elixir console with
232+ # Base.encode32(:crypto.strong_rand_bytes(32))
233+ RELEASE_COOKIE = "my_cookie";
234+ MY_VAR = "my_var";
235+ };
236+ serviceConfig = {
237+ Type = "exec";
238+ DynamicUser = true;
239+ WorkingDirectory = working_directory;
240+ # Implied by DynamicUser, but just to emphasize due to RELEASE_TMP
241+ PrivateTmp = true;
242+ ExecStart = ''
243+ ${release}/bin/${release_name} start
244+ '';
245+ ExecStop = ''
246+ ${release}/bin/${release_name} stop
247+ '';
248+ ExecReload = ''
249+ ${release}/bin/${release_name} restart
250+ '';
251+ Restart = "on-failure";
252+ RestartSec = 5;
253+ StartLimitBurst = 3;
254+ StartLimitInterval = 10;
255+ };
256+ # disksup requires bash
257+ path = [ pkgs.bash ];
258+ };
259+
260+ # in case you have migration scripts or you want to use a remote shell
261+ environment.systemPackages = [ release ];
262+}
263+```
264+
265+## How to Develop {#how-to-develop}
266+
267+### Creating a Shell {#creating-a-shell}
268+
269+Usually, we need to create a `shell.nix` file and do our development inside of the environment specified therein. Just install your version of Erlang and any other interpreters, and then use your normal build tools. As an example with Elixir:
270+
271+```nix
272+{ pkgs ? import <nixpkgs> {} }:
273+
274+with pkgs;
275+let
276+ elixir = beam.packages.erlangR24.elixir_1_12;
277+in
278+mkShell {
279+ buildInputs = [ elixir ];
280+}
281+```
282+
283+### Using an overlay
284+
285+If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `sha256`) and then use this overlay in your development environment:
286+
287+#### `shell.nix`
288+
289+```nix
290+let
291+ elixir_1_13_1_overlay = (self: super: {
292+ elixir_1_13 = super.elixir_1_13.override {
293+ version = "1.13.1";
294+ sha256 = "0z0b1w2vvw4vsnb99779c2jgn9bgslg7b1pmd9vlbv02nza9qj5p";
295+ };
296+ });
297+ pkgs = import <nixpkgs> { overlays = [ elixir_1_13_1_overlay ]; };
298+in
299+with pkgs;
300+mkShell {
301+ buildInputs = [
302+ elixir_1_13
303+ ];
304+}
305+```
306+
307+#### Elixir - Phoenix project {#elixir---phoenix-project}
308+
309+Here is an example `shell.nix`.
310+
311+```nix
312+with import <nixpkgs> { };
313+
314+let
315+ # define packages to install
316+ basePackages = [
317+ git
318+ # replace with beam.packages.erlang.elixir_1_13 if you need
319+ beam.packages.erlang.elixir
320+ nodejs
321+ postgresql_14
322+ # only used for frontend dependencies
323+ # you are free to use yarn2nix as well
324+ nodePackages.node2nix
325+ # formatting js file
326+ nodePackages.prettier
327+ ];
328+
329+ inputs = basePackages ++ lib.optionals stdenv.isLinux [ inotify-tools ]
330+ ++ lib.optionals stdenv.isDarwin
331+ (with darwin.apple_sdk.frameworks; [ CoreFoundation CoreServices ]);
332+
333+ # define shell startup command
334+ hooks = ''
335+ # this allows mix to work on the local directory
336+ mkdir -p .nix-mix .nix-hex
337+ export MIX_HOME=$PWD/.nix-mix
338+ export HEX_HOME=$PWD/.nix-mix
339+ # make hex from Nixpkgs available
340+ # `mix local.hex` will install hex into MIX_HOME and should take precedence
341+ export MIX_PATH="${beam.packages.erlang.hex}/lib/erlang/lib/hex/ebin"
342+ export PATH=$MIX_HOME/bin:$HEX_HOME/bin:$PATH
343+ export LANG=C.UTF-8
344+ # keep your shell history in iex
345+ export ERL_AFLAGS="-kernel shell_history enabled"
346+
347+ # postges related
348+ # keep all your db data in a folder inside the project
349+ export PGDATA="$PWD/db"
350+
351+ # phoenix related env vars
352+ export POOL_SIZE=15
353+ export DB_URL="postgresql://postgres:postgres@localhost:5432/db"
354+ export PORT=4000
355+ export MIX_ENV=dev
356+ # add your project env vars here, word readable in the nix store.
357+ export ENV_VAR="your_env_var"
358+ '';
359+
360+in mkShell {
361+ buildInputs = inputs;
362+ shellHook = hooks;
363+}
364+```
365+
366+Initializing the project will require the following steps:
367+
368+- create the db directory `initdb ./db` (inside your mix project folder)
369+- create the postgres user `createuser postgres -ds`
370+- create the db `createdb db`
371+- start the postgres instance `pg_ctl -l "$PGDATA/server.log" start`
372+- add the `/db` folder to your `.gitignore`
373+- you can start your phoenix server and get a shell with `iex -S mix phx.server`
doc/languages-frameworks/beam.xmldeleted−528
@@ -1,528 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-beam">
4− <title>BEAM Languages (Erlang, Elixir & LFE)</title>
5−
6− <section xml:id="beam-introduction">
7− <title>Introduction</title>
8−
9− <para>
10− In this document and related Nix expressions, we use the term,
11− <emphasis>BEAM</emphasis>, to describe the environment. BEAM is the name of
12− the Erlang Virtual Machine and, as far as we're concerned, from a packaging
13− perspective, all languages that run on the BEAM are interchangeable. That
14− which varies, like the build system, is transparent to users of any given
15− BEAM package, so we make no distinction.
16− </para>
17− </section>
18−
19− <section xml:id="beam-structure">
20− <title>Structure</title>
21−
22− <para>
23− All BEAM-related expressions are available via the top-level
24− <literal>beam</literal> attribute, which includes:
25− </para>
26−
27− <itemizedlist>
28− <listitem>
29− <para>
30− <literal>interpreters</literal>: a set of compilers running on the BEAM,
31− including multiple Erlang/OTP versions
32− (<literal>beam.interpreters.erlangR19</literal>, etc), Elixir
33− (<literal>beam.interpreters.elixir</literal>) and LFE
34− (<literal>beam.interpreters.lfe</literal>).
35− </para>
36− </listitem>
37− <listitem>
38− <para>
39− <literal>packages</literal>: a set of package sets, each compiled with a
40− specific Erlang/OTP version, e.g.
41− <literal>beam.packages.erlangR19</literal>.
42− </para>
43− </listitem>
44− </itemizedlist>
45−
46− <para>
47− The default Erlang compiler, defined by
48− <literal>beam.interpreters.erlang</literal>, is aliased as
49− <literal>erlang</literal>. The default BEAM package set is defined by
50− <literal>beam.packages.erlang</literal> and aliased at the top level as
51− <literal>beamPackages</literal>.
52− </para>
53−
54− <para>
55− To create a package set built with a custom Erlang version, use the lambda,
56− <literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation
57− and produces a package set similar to
58− <literal>beam.packages.erlang</literal>.
59− </para>
60−
61− <para>
62− Many Erlang/OTP distributions available in
63− <literal>beam.interpreters</literal> have versions with ODBC and/or Java
64− enabled. For example, there's
65− <literal>beam.interpreters.erlangR19_odbc_javac</literal>, which corresponds
66− to <literal>beam.interpreters.erlangR19</literal>.
67− </para>
68−
69− <para xml:id="erlang-call-package">
70− We also provide the lambda,
71− <literal>beam.packages.erlang.callPackage</literal>, which simplifies
72− writing BEAM package definitions by injecting all packages from
73− <literal>beam.packages.erlang</literal> into the top-level context.
74− </para>
75− </section>
76−
77− <section xml:id="build-tools">
78− <title>Build Tools</title>
79−
80− <section xml:id="build-tools-rebar3">
81− <title>Rebar3</title>
82−
83− <para>
84− By default, Rebar3 wants to manage its own dependencies. This is perfectly
85− acceptable in the normal, non-Nix setup, but in the Nix world, it is not.
86− To rectify this, we provide two versions of Rebar3:
87− <itemizedlist>
88− <listitem>
89− <para>
90− <literal>rebar3</literal>: patched to remove the ability to download
91− anything. When not running it via <literal>nix-shell</literal> or
92− <literal>nix-build</literal>, it's probably not going to work as
93− desired.
94− </para>
95− </listitem>
96− <listitem>
97− <para>
98− <literal>rebar3-open</literal>: the normal, unmodified Rebar3. It should
99− work exactly as would any other version of Rebar3. Any Erlang package
100− should rely on <literal>rebar3</literal> instead. See
101− <xref
102− linkend="rebar3-packages"/>.
103− </para>
104− </listitem>
105− </itemizedlist>
106− </para>
107− </section>
108−
109− <section xml:id="build-tools-other">
110− <title>Mix & Erlang.mk</title>
111−
112− <para>
113− Both Mix and Erlang.mk work exactly as expected. There is a bootstrap
114− process that needs to be run for both, however, which is supported by the
115− <literal>buildMix</literal> and <literal>buildErlangMk</literal>
116− derivations, respectively.
117− </para>
118− </section>
119− </section>
120−
121− <section xml:id="how-to-install-beam-packages">
122− <title>How to Install BEAM Packages</title>
123−
124− <para>
125− BEAM packages are not registered at the top level, simply because they are
126− not relevant to the vast majority of Nix users. They are installable using
127− the <literal>beam.packages.erlang</literal> attribute set (aliased as
128− <literal>beamPackages</literal>), which points to packages built by the
129− default Erlang/OTP version in Nixpkgs, as defined by
130− <literal>beam.interpreters.erlang</literal>. To list the available packages
131− in <literal>beamPackages</literal>, use the following command:
132− </para>
133−
134−<programlisting>
135−$ nix-env -f "<nixpkgs>" -qaP -A beamPackages
136−beamPackages.esqlite esqlite-0.2.1
137−beamPackages.goldrush goldrush-0.1.7
138−beamPackages.ibrowse ibrowse-4.2.2
139−beamPackages.jiffy jiffy-0.14.5
140−beamPackages.lager lager-3.0.2
141−beamPackages.meck meck-0.8.3
142−beamPackages.rebar3-pc pc-1.1.0
143− </programlisting>
144−
145− <para>
146− To install any of those packages into your profile, refer to them by their
147− attribute path (first column):
148− </para>
149−
150−<programlisting>
151−$ nix-env -f "<nixpkgs>" -iA beamPackages.ibrowse
152− </programlisting>
153−
154− <para>
155− The attribute path of any BEAM package corresponds to the name of that
156− particular package in <link xlink:href="https://hex.pm">Hex</link> or its
157− OTP Application/Release name.
158− </para>
159− </section>
160−
161− <section xml:id="packaging-beam-applications">
162− <title>Packaging BEAM Applications</title>
163−
164− <section xml:id="packaging-erlang-applications">
165− <title>Erlang Applications</title>
166−
167− <section xml:id="rebar3-packages">
168− <title>Rebar3 Packages</title>
169−
170− <para>
171− The Nix function, <literal>buildRebar3</literal>, defined in
172− <literal>beam.packages.erlang.buildRebar3</literal> and aliased at the top
173− level, can be used to build a derivation that understands how to build a
174− Rebar3 project. For example, we can build
175− <link
176− xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>
177− as follows:
178− </para>
179−
180−<programlisting>
181− { stdenv, fetchFromGitHub, buildRebar3, ibrowse, jsx, erlware_commons }:
182−
183− buildRebar3 rec {
184− name = "hex2nix";
185− version = "0.0.1";
186−
187− src = fetchFromGitHub {
188− owner = "ericbmerritt";
189− repo = "hex2nix";
190− rev = "${version}";
191− sha256 = "1w7xjidz1l5yjmhlplfx7kphmnpvqm67w99hd2m7kdixwdxq0zqg";
192− };
193−
194− beamDeps = [ ibrowse jsx erlware_commons ];
195− }
196− </programlisting>
197−
198− <para>
199− Such derivations are callable with
200− <literal>beam.packages.erlang.callPackage</literal> (see
201− <xref
202− linkend="erlang-call-package"/>). To call this package using
203− the normal <literal>callPackage</literal>, refer to dependency packages
204− via <literal>beamPackages</literal>, e.g.
205− <literal>beamPackages.ibrowse</literal>.
206− </para>
207−
208− <para>
209− Notably, <literal>buildRebar3</literal> includes
210− <literal>beamDeps</literal>, while <literal>stdenv.mkDerivation</literal>
211− does not. BEAM dependencies added there will be correctly handled by the
212− system.
213− </para>
214−
215− <para>
216− If a package needs to compile native code via Rebar3's port compilation
217− mechanism, add <literal>compilePort = true;</literal> to the derivation.
218− </para>
219− </section>
220−
221− <section xml:id="erlang-mk-packages">
222− <title>Erlang.mk Packages</title>
223−
224− <para>
225− Erlang.mk functions similarly to Rebar3, except we use
226− <literal>buildErlangMk</literal> instead of
227− <literal>buildRebar3</literal>.
228− </para>
229−
230−<programlisting>
231− { buildErlangMk, fetchHex, cowlib, ranch }:
232−
233− buildErlangMk {
234− name = "cowboy";
235− version = "1.0.4";
236−
237− src = fetchHex {
238− pkg = "cowboy";
239− version = "1.0.4";
240− sha256 = "6a0edee96885fae3a8dd0ac1f333538a42e807db638a9453064ccfdaa6b9fdac";
241− };
242−
243− beamDeps = [ cowlib ranch ];
244−
245− meta = {
246− description = ''
247− Small, fast, modular HTTP server written in Erlang
248− '';
249− license = stdenv.lib.licenses.isc;
250− homepage = https://github.com/ninenines/cowboy;
251− };
252− }
253− </programlisting>
254− </section>
255−
256− <section xml:id="mix-packages">
257− <title>Mix Packages</title>
258−
259− <para>
260− Mix functions similarly to Rebar3, except we use
261− <literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
262− </para>
263−
264−<programlisting>
265− { buildMix, fetchHex, plug, absinthe }:
266−
267− buildMix {
268− name = "absinthe_plug";
269− version = "1.0.0";
270−
271− src = fetchHex {
272− pkg = "absinthe_plug";
273− version = "1.0.0";
274− sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
275− };
276−
277− beamDeps = [ plug absinthe ];
278−
279− meta = {
280− description = ''
281− A plug for Absinthe, an experimental GraphQL toolkit
282− '';
283− license = stdenv.lib.licenses.bsd3;
284− homepage = https://github.com/CargoSense/absinthe_plug;
285− };
286− }
287− </programlisting>
288−
289− <para>
290− Alternatively, we can use <literal>buildHex</literal> as a shortcut:
291− </para>
292−
293−<programlisting>
294− { buildHex, buildMix, plug, absinthe }:
295−
296− buildHex {
297− name = "absinthe_plug";
298− version = "1.0.0";
299−
300− sha256 = "08459823fe1fd4f0325a8bf0c937a4520583a5a26d73b193040ab30a1dfc0b33";
301−
302− builder = buildMix;
303−
304− beamDeps = [ plug absinthe ];
305−
306− meta = {
307− description = ''
308− A plug for Absinthe, an experimental GraphQL toolkit
309− '';
310− license = stdenv.lib.licenses.bsd3;
311− homepage = https://github.com/CargoSense/absinthe_plug;
312− };
313− }
314− </programlisting>
315− </section>
316− </section>
317− </section>
318−
319− <section xml:id="how-to-develop">
320− <title>How to Develop</title>
321−
322− <section xml:id="accessing-an-environment">
323− <title>Accessing an Environment</title>
324−
325− <para>
326− Often, we simply want to access a valid environment that contains a
327− specific package and its dependencies. We can accomplish that with the
328− <literal>env</literal> attribute of a derivation. For example, let's say we
329− want to access an Erlang REPL with <literal>ibrowse</literal> loaded up. We
330− could do the following:
331− </para>
332−
333−<programlisting>
334− $ nix-shell -A beamPackages.ibrowse.env --run "erl"
335− Erlang/OTP 18 [erts-7.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
336−
337− Eshell V7.0 (abort with ^G)
338− 1> m(ibrowse).
339− Module: ibrowse
340− MD5: 3b3e0137d0cbb28070146978a3392945
341− Compiled: January 10 2016, 23:34
342− Object file: /nix/store/g1rlf65rdgjs4abbyj4grp37ry7ywivj-ibrowse-4.2.2/lib/erlang/lib/ibrowse-4.2.2/ebin/ibrowse.beam
343− Compiler options: [{outdir,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/ebin"},
344− debug_info,debug_info,nowarn_shadow_vars,
345− warn_unused_import,warn_unused_vars,warnings_as_errors,
346− {i,"/tmp/nix-build-ibrowse-4.2.2.drv-0/hex-source-ibrowse-4.2.2/_build/default/lib/ibrowse/include"}]
347− Exports:
348− add_config/1 send_req_direct/7
349− all_trace_off/0 set_dest/3
350− code_change/3 set_max_attempts/3
351− get_config_value/1 set_max_pipeline_size/3
352− get_config_value/2 set_max_sessions/3
353− get_metrics/0 show_dest_status/0
354− get_metrics/2 show_dest_status/1
355− handle_call/3 show_dest_status/2
356− handle_cast/2 spawn_link_worker_process/1
357− handle_info/2 spawn_link_worker_process/2
358− init/1 spawn_worker_process/1
359− module_info/0 spawn_worker_process/2
360− module_info/1 start/0
361− rescan_config/0 start_link/0
362− rescan_config/1 stop/0
363− send_req/3 stop_worker_process/1
364− send_req/4 stream_close/1
365− send_req/5 stream_next/1
366− send_req/6 terminate/2
367− send_req_direct/4 trace_off/0
368− send_req_direct/5 trace_off/2
369− send_req_direct/6 trace_on/0
370− trace_on/2
371− ok
372− 2>
373− </programlisting>
374−
375− <para>
376− Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key
377− to this functionality.
378− </para>
379− </section>
380−
381− <section xml:id="creating-a-shell">
382− <title>Creating a Shell</title>
383−
384− <para>
385− Getting access to an environment often isn't enough to do real development.
386− Usually, we need to create a <literal>shell.nix</literal> file and do our
387− development inside of the environment specified therein. This file looks a
388− lot like the packaging described above, except that <literal>src</literal>
389− points to the project root and we call the package directly.
390− </para>
391−
392−<programlisting>
393−{ pkgs ? import "<nixpkgs"> {} }:
394−
395−with pkgs;
396−
397−let
398−
399− f = { buildRebar3, ibrowse, jsx, erlware_commons }:
400− buildRebar3 {
401− name = "hex2nix";
402− version = "0.1.0";
403− src = ./.;
404− beamDeps = [ ibrowse jsx erlware_commons ];
405− };
406− drv = beamPackages.callPackage f {};
407−
408−in
409−
410− drv
411− </programlisting>
412−
413− <section xml:id="building-in-a-shell">
414− <title>Building in a Shell (for Mix Projects)</title>
415−
416− <para>
417− We can leverage the support of the derivation, irrespective of the build
418− derivation, by calling the commands themselves.
419− </para>
420−
421−<programlisting>
422−# =============================================================================
423−# Variables
424−# =============================================================================
425−
426−NIX_TEMPLATES := "$(CURDIR)/nix-templates"
427−
428−TARGET := "$(PREFIX)"
429−
430−PROJECT_NAME := thorndyke
431−
432−NIXPKGS=../nixpkgs
433−NIX_PATH=nixpkgs=$(NIXPKGS)
434−NIX_SHELL=nix-shell -I "$(NIX_PATH)" --pure
435−# =============================================================================
436−# Rules
437−# =============================================================================
438−.PHONY= all test clean repl shell build test analyze configure install \
439− test-nix-install publish plt analyze
440−
441−all: build
442−
443−guard-%:
444− @ if [ "${${*}}" == "" ]; then \
445− echo "Environment variable $* not set"; \
446− exit 1; \
447− fi
448−
449−clean:
450− rm -rf _build
451− rm -rf .cache
452−
453−repl:
454− $(NIX_SHELL) --run "iex -pa './_build/prod/lib/*/ebin'"
455−
456−shell:
457− $(NIX_SHELL)
458−
459−configure:
460− $(NIX_SHELL) --command 'eval "$$configurePhase"'
461−
462−build: configure
463− $(NIX_SHELL) --command 'eval "$$buildPhase"'
464−
465−install:
466− $(NIX_SHELL) --command 'eval "$$installPhase"'
467−
468−test:
469− $(NIX_SHELL) --command 'mix test --no-start --no-deps-check'
470−
471−plt:
472− $(NIX_SHELL) --run "mix dialyzer.plt --no-deps-check"
473−
474−analyze: build plt
475− $(NIX_SHELL) --run "mix dialyzer --no-compile"
476−
477− </programlisting>
478−
479− <para>
480− Using a <literal>shell.nix</literal> as described (see
481− <xref
482− linkend="creating-a-shell"/>) should just work. Aside from
483− <literal>test</literal>, <literal>plt</literal>, and
484− <literal>analyze</literal>, the Make targets work just fine for all of the
485− build derivations.
486− </para>
487− </section>
488− </section>
489− </section>
490−
491− <section xml:id="generating-packages-from-hex-with-hex2nix">
492− <title>Generating Packages from Hex with <literal>hex2nix</literal></title>
493−
494− <para>
495− Updating the <link xlink:href="https://hex.pm">Hex</link> package set
496− requires
497− <link
498− xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>.
499− Given the path to the Erlang modules (usually
500− <literal>pkgs/development/erlang-modules</literal>), it will dump a file
501− called <literal>hex-packages.nix</literal>, containing all the packages that
502− use a recognized build system in
503− <link
504− xlink:href="https://hex.pm">Hex</link>. It can't be determined,
505− however, whether every package is buildable.
506− </para>
507−
508− <para>
509− To make life easier for our users, try to build every
510− <link
511− xlink:href="https://hex.pm">Hex</link> package and remove those
512− that fail. To do that, simply run the following command in the root of your
513− <literal>nixpkgs</literal> repository:
514− </para>
515−
516−<programlisting>
517−$ nix-build -A beamPackages
518− </programlisting>
519−
520− <para>
521− That will attempt to build every package in <literal>beamPackages</literal>.
522− Then manually remove those that fail. Hopefully, someone will improve
523− <link
524− xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>
525− in the future to automate the process.
526− </para>
527− </section>
528−</section>
doc/languages-frameworks/bower.section.mdnew file+158
@@ -0,0 +1,158 @@
1+# Bower {#sec-bower}
2+
3+[Bower](https://bower.io) is a package manager for web site front-end components. Bower packages (comprising of build artefacts and sometimes sources) are stored in `git` repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the `bower.json` file within each package.
4+
5+The end result of running Bower is a `bower_components` directory which can be included in the web app's build process.
6+
7+Bower can be run interactively, by installing `nodePackages.bower`. More interestingly, the Bower components can be declared in a Nix derivation, with the help of `nodePackages.bower2nix`.
8+
9+## bower2nix usage {#ssec-bower2nix-usage}
10+
11+Suppose you have a `bower.json` with the following contents:
12+
13+### Example bower.json {#ex-bowerJson}
14+
15+```json
16+ "name": "my-web-app",
17+ "dependencies": {
18+ "angular": "~1.5.0",
19+ "bootstrap": "~3.3.6"
20+ }
21+```
22+
23+Running `bower2nix` will produce something like the following output:
24+
25+```nix
26+{ fetchbower, buildEnv }:
27+buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
28+ (fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
29+ (fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
30+ (fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
31+];
32+```
33+
34+Using the `bower2nix` command line arguments, the output can be redirected to a file. A name like `bower-packages.nix` would be fine.
35+
36+The resulting derivation is a union of all the downloaded Bower packages (and their dependencies). To use it, they still need to be linked together by Bower, which is where `buildBowerComponents` is useful.
37+
38+## buildBowerComponents function {#ssec-build-bower-components}
39+
40+The function is implemented in [pkgs/development/bower-modules/generic/default.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix).
41+
42+### Example buildBowerComponents {#ex-buildBowerComponents}
43+
44+```{=docbook}
45+<programlisting language="nix">
46+bowerComponents = buildBowerComponents {
47+ name = "my-web-app";
48+ generated = ./bower-packages.nix; <co xml:id="ex-buildBowerComponents-1" />
49+ src = myWebApp; <co xml:id="ex-buildBowerComponents-2" />
50+};
51+</programlisting>
52+```
53+
54+In ["buildBowerComponents" example](#ex-buildBowerComponents) the following arguments are of special significance to the function:
55+
56+```{=docbook}
57+<calloutlist>
58+ <callout arearefs="ex-buildBowerComponents-1">
59+ <para>
60+ <varname>generated</varname> specifies the file which was created by <command>bower2nix</command>.
61+ </para>
62+ </callout>
63+ <callout arearefs="ex-buildBowerComponents-2">
64+ <para>
65+ <varname>src</varname> is your project's sources. It needs to contain a <filename>bower.json</filename> file.
66+ </para>
67+ </callout>
68+</calloutlist>
69+```
70+
71+`buildBowerComponents` will run Bower to link together the output of `bower2nix`, resulting in a `bower_components` directory which can be used.
72+
73+Here is an example of a web frontend build process using `gulp`. You might use `grunt`, or anything else.
74+
75+### Example build script (gulpfile.js) {#ex-bowerGulpFile}
76+
77+```javascript
78+var gulp = require('gulp');
79+
80+gulp.task('default', [], function () {
81+ gulp.start('build');
82+});
83+
84+gulp.task('build', [], function () {
85+ console.log("Just a dummy gulp build");
86+ gulp
87+ .src(["./bower_components/**/*"])
88+ .pipe(gulp.dest("./gulpdist/"));
89+});
90+```
91+
92+### Example Full example — default.nix {#ex-buildBowerComponentsDefaultNix}
93+
94+```{=docbook}
95+<programlisting language="nix">
96+{ myWebApp ? { outPath = ./.; name = "myWebApp"; }
97+, pkgs ? import <nixpkgs> {}
98+}:
99+
100+pkgs.stdenv.mkDerivation {
101+ name = "my-web-app-frontend";
102+ src = myWebApp;
103+
104+ buildInputs = [ pkgs.nodePackages.gulp ];
105+
106+ bowerComponents = pkgs.buildBowerComponents { <co xml:id="ex-buildBowerComponentsDefault-1" />
107+ name = "my-web-app";
108+ generated = ./bower-packages.nix;
109+ src = myWebApp;
110+ };
111+
112+ buildPhase = ''
113+ cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . <co xml:id="ex-buildBowerComponentsDefault-2" />
114+ export HOME=$PWD <co xml:id="ex-buildBowerComponentsDefault-3" />
115+ ${pkgs.nodePackages.gulp}/bin/gulp build <co xml:id="ex-buildBowerComponentsDefault-4" />
116+ '';
117+
118+ installPhase = "mv gulpdist $out";
119+}
120+</programlisting>
121+```
122+
123+A few notes about [Full example — `default.nix`](#ex-buildBowerComponentsDefaultNix):
124+
125+```{=docbook}
126+<calloutlist>
127+ <callout arearefs="ex-buildBowerComponentsDefault-1">
128+ <para>
129+ The result of <varname>buildBowerComponents</varname> is an input to the frontend build.
130+ </para>
131+ </callout>
132+ <callout arearefs="ex-buildBowerComponentsDefault-2">
133+ <para>
134+ Whether to symlink or copy the <filename>bower_components</filename> directory depends on the build tool in use. In this case a copy is used to avoid <command>gulp</command> silliness with permissions.
135+ </para>
136+ </callout>
137+ <callout arearefs="ex-buildBowerComponentsDefault-3">
138+ <para>
139+ <command>gulp</command> requires <varname>HOME</varname> to refer to a writeable directory.
140+ </para>
141+ </callout>
142+ <callout arearefs="ex-buildBowerComponentsDefault-4">
143+ <para>
144+ The actual build command. Other tools could be used.
145+ </para>
146+ </callout>
147+</calloutlist>
148+```
149+
150+## Troubleshooting {#ssec-bower2nix-troubleshooting}
151+
152+### ENOCACHE errors from buildBowerComponents {#enocache-errors-from-buildbowercomponents}
153+
154+This means that Bower was looking for a package version which doesn't exist in the generated `bower-packages.nix`.
155+
156+If `bower.json` has been updated, then run `bower2nix` again.
157+
158+It could also be a bug in `bower2nix` or `fetchbower`. If possible, try reformulating the version specification in `bower.json`.
doc/languages-frameworks/bower.xmldeleted−229
@@ -1,229 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-bower">
4− <title>Bower</title>
5−
6− <para>
7− <link xlink:href="http://bower.io">Bower</link> is a package manager for web
8− site front-end components. Bower packages (comprising of build artefacts and
9− sometimes sources) are stored in <command>git</command> repositories,
10− typically on Github. The package registry is run by the Bower team with
11− package metadata coming from the <filename>bower.json</filename> file within
12− each package.
13− </para>
14−
15− <para>
16− The end result of running Bower is a <filename>bower_components</filename>
17− directory which can be included in the web app's build process.
18− </para>
19−
20− <para>
21− Bower can be run interactively, by installing
22− <varname>nodePackages.bower</varname>. More interestingly, the Bower
23− components can be declared in a Nix derivation, with the help of
24− <varname>nodePackages.bower2nix</varname>.
25− </para>
26−
27− <section xml:id="ssec-bower2nix-usage">
28− <title><command>bower2nix</command> usage</title>
29−
30− <para>
31− Suppose you have a <filename>bower.json</filename> with the following
32− contents:
33− <example xml:id="ex-bowerJson">
34− <title><filename>bower.json</filename></title>
35−<programlisting language="json">
36−<![CDATA[{
37− "name": "my-web-app",
38− "dependencies": {
39− "angular": "~1.5.0",
40− "bootstrap": "~3.3.6"
41− }
42−}]]>
43−</programlisting>
44− </example>
45− </para>
46−
47− <para>
48− Running <command>bower2nix</command> will produce something like the
49− following output:
50−<programlisting language="nix">
51−<![CDATA[{ fetchbower, buildEnv }:
52−buildEnv { name = "bower-env"; ignoreCollisions = true; paths = [
53− (fetchbower "angular" "1.5.3" "~1.5.0" "1749xb0firxdra4rzadm4q9x90v6pzkbd7xmcyjk6qfza09ykk9y")
54− (fetchbower "bootstrap" "3.3.6" "~3.3.6" "1vvqlpbfcy0k5pncfjaiskj3y6scwifxygfqnw393sjfxiviwmbv")
55− (fetchbower "jquery" "2.2.2" "1.9.1 - 2" "10sp5h98sqwk90y4k6hbdviwqzvzwqf47r3r51pakch5ii2y7js1")
56−]; }]]>
57−</programlisting>
58− </para>
59−
60− <para>
61− Using the <command>bower2nix</command> command line arguments, the output
62− can be redirected to a file. A name like
63− <filename>bower-packages.nix</filename> would be fine.
64− </para>
65−
66− <para>
67− The resulting derivation is a union of all the downloaded Bower packages
68− (and their dependencies). To use it, they still need to be linked together
69− by Bower, which is where <varname>buildBowerComponents</varname> is useful.
70− </para>
71− </section>
72−
73− <section xml:id="ssec-build-bower-components">
74− <title><varname>buildBowerComponents</varname> function</title>
75−
76− <para>
77− The function is implemented in
78− <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix">
79− <filename>pkgs/development/bower-modules/generic/default.nix</filename></link>.
80− Example usage:
81− <example xml:id="ex-buildBowerComponents">
82− <title>buildBowerComponents</title>
83−<programlisting language="nix">
84−bowerComponents = buildBowerComponents {
85− name = "my-web-app";
86− generated = ./bower-packages.nix; <co xml:id="ex-buildBowerComponents-1" />
87− src = myWebApp; <co xml:id="ex-buildBowerComponents-2" />
88−};
89−</programlisting>
90− </example>
91− </para>
92−
93− <para>
94− In <xref linkend="ex-buildBowerComponents" />, the following arguments are
95− of special significance to the function:
96− <calloutlist>
97− <callout arearefs="ex-buildBowerComponents-1">
98− <para>
99− <varname>generated</varname> specifies the file which was created by
100− <command>bower2nix</command>.
101− </para>
102− </callout>
103− <callout arearefs="ex-buildBowerComponents-2">
104− <para>
105− <varname>src</varname> is your project's sources. It needs to contain a
106− <filename>bower.json</filename> file.
107− </para>
108− </callout>
109− </calloutlist>
110− </para>
111−
112− <para>
113− <varname>buildBowerComponents</varname> will run Bower to link together the
114− output of <command>bower2nix</command>, resulting in a
115− <filename>bower_components</filename> directory which can be used.
116− </para>
117−
118− <para>
119− Here is an example of a web frontend build process using
120− <command>gulp</command>. You might use <command>grunt</command>, or anything
121− else.
122− </para>
123−
124− <example xml:id="ex-bowerGulpFile">
125− <title>Example build script (<filename>gulpfile.js</filename>)</title>
126−<programlisting language="javascript">
127−<![CDATA[var gulp = require('gulp');
128−
129−gulp.task('default', [], function () {
130− gulp.start('build');
131−});
132−
133−gulp.task('build', [], function () {
134− console.log("Just a dummy gulp build");
135− gulp
136− .src(["./bower_components/**/*"])
137− .pipe(gulp.dest("./gulpdist/"));
138−});]]>
139−</programlisting>
140− </example>
141−
142− <example xml:id="ex-buildBowerComponentsDefaultNix">
143− <title>Full example — <filename>default.nix</filename></title>
144−<programlisting language="nix">
145−{ myWebApp ? { outPath = ./.; name = "myWebApp"; }
146−, pkgs ? import <nixpkgs> {}
147−}:
148−
149−pkgs.stdenv.mkDerivation {
150− name = "my-web-app-frontend";
151− src = myWebApp;
152−
153− buildInputs = [ pkgs.nodePackages.gulp ];
154−
155− bowerComponents = pkgs.buildBowerComponents { <co xml:id="ex-buildBowerComponentsDefault-1" />
156− name = "my-web-app";
157− generated = ./bower-packages.nix;
158− src = myWebApp;
159− };
160−
161− buildPhase = ''
162− cp --reflink=auto --no-preserve=mode -R $bowerComponents/bower_components . <co xml:id="ex-buildBowerComponentsDefault-2" />
163− export HOME=$PWD <co xml:id="ex-buildBowerComponentsDefault-3" />
164− ${pkgs.nodePackages.gulp}/bin/gulp build <co xml:id="ex-buildBowerComponentsDefault-4" />
165− '';
166−
167− installPhase = "mv gulpdist $out";
168−}
169−</programlisting>
170− </example>
171−
172− <para>
173− A few notes about <xref linkend="ex-buildBowerComponentsDefaultNix" />:
174− <calloutlist>
175− <callout arearefs="ex-buildBowerComponentsDefault-1">
176− <para>
177− The result of <varname>buildBowerComponents</varname> is an input to the
178− frontend build.
179− </para>
180− </callout>
181− <callout arearefs="ex-buildBowerComponentsDefault-2">
182− <para>
183− Whether to symlink or copy the <filename>bower_components</filename>
184− directory depends on the build tool in use. In this case a copy is used
185− to avoid <command>gulp</command> silliness with permissions.
186− </para>
187− </callout>
188− <callout arearefs="ex-buildBowerComponentsDefault-3">
189− <para>
190− <command>gulp</command> requires <varname>HOME</varname> to refer to a
191− writeable directory.
192− </para>
193− </callout>
194− <callout arearefs="ex-buildBowerComponentsDefault-4">
195− <para>
196− The actual build command. Other tools could be used.
197− </para>
198− </callout>
199− </calloutlist>
200− </para>
201− </section>
202−
203− <section xml:id="ssec-bower2nix-troubleshooting">
204− <title>Troubleshooting</title>
205−
206− <variablelist>
207− <varlistentry>
208− <term>
209− <literal>ENOCACHE</literal> errors from <varname>buildBowerComponents</varname>
210− </term>
211− <listitem>
212− <para>
213− This means that Bower was looking for a package version which doesn't
214− exist in the generated <filename>bower-packages.nix</filename>.
215− </para>
216− <para>
217− If <filename>bower.json</filename> has been updated, then run
218− <command>bower2nix</command> again.
219− </para>
220− <para>
221− It could also be a bug in <command>bower2nix</command> or
222− <command>fetchbower</command>. If possible, try reformulating the version
223− specification in <filename>bower.json</filename>.
224− </para>
225− </listitem>
226− </varlistentry>
227− </variablelist>
228− </section>
229−</section>
doc/languages-frameworks/chicken.section.mdnew file+49
@@ -0,0 +1,49 @@
1+# CHICKEN {#sec-chicken}
2+
3+[CHICKEN](https://call-cc.org/) is a
4+[R⁵RS](https://schemers.org/Documents/Standards/R5RS/HTML/)-compliant Scheme
5+compiler. It includes an interactive mode and a custom package format, "eggs".
6+
7+## Using Eggs
8+
9+Eggs described in nixpkgs are available inside the
10+`chickenPackages.chickenEggs` attrset. Including an egg as a build input is
11+done in the typical Nix fashion. For example, to include support for [SRFI
12+189](https://srfi.schemers.org/srfi-189/srfi-189.html) in a derivation, one
13+might write:
14+
15+```nix
16+ buildInputs = [
17+ chicken
18+ chickenPackages.chickenEggs.srfi-189
19+ ];
20+```
21+
22+Both `chicken` and its eggs have a setup hook which configures the environment
23+variables `CHICKEN_INCLUDE_PATH` and `CHICKEN_REPOSITORY_PATH`.
24+
25+## Updating Eggs
26+
27+nixpkgs only knows about a subset of all published eggs. It uses
28+[egg2nix](https://github.com/the-kenny/egg2nix) to generate a
29+package set from a list of eggs to include.
30+
31+The package set is regenerated by running the following shell commands:
32+
33+```
34+$ nix-shell -p chickenPackages.egg2nix
35+$ cd pkgs/development/compilers/chicken/5/
36+$ egg2nix eggs.scm > eggs.nix
37+```
38+
39+## Adding Eggs
40+
41+When we run `egg2nix`, we obtain one collection of eggs with
42+mutually-compatible versions. This means that when we add new eggs, we may
43+need to update existing eggs. To keep those separate, follow the procedure for
44+updating eggs before including more eggs.
45+
46+To include more eggs, edit `pkgs/development/compilers/chicken/5/eggs.scm`.
47+The first section of this file lists eggs which are required by `egg2nix`
48+itself; all other eggs go into the second section. After editing, follow the
49+procedure for updating eggs.
doc/languages-frameworks/coq.section.mdnew file+83
@@ -0,0 +1,83 @@
1+# Coq and coq packages {#sec-language-coq}
2+
3+## Coq derivation: `coq` {#coq-derivation-coq}
4+
5+The Coq derivation is overridable through the `coq.override overrides`, where overrides is an attribute set which contains the arguments to override. We recommend overriding either of the following
6+
7+* `version` (optional, defaults to the latest version of Coq selected for nixpkgs, see `pkgs/top-level/coq-packages` to witness this choice), which follows the conventions explained in the `coqPackages` section below,
8+* `customOCamlPackage` (optional, defaults to `null`, which lets Coq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_10` which is the default for Coq 8.11 for example).
9+* `coq-version` (optional, defaults to the short version e.g. "8.10"), is a version number of the form "x.y" that indicates which Coq's version build behavior to mimic when using a source which is not a release. E.g. `coq.override { version = "d370a9d1328a4e1cdb9d02ee032f605a9d94ec7a"; coq-version = "8.10"; }`.
10+
11+## Coq packages attribute sets: `coqPackages` {#coq-packages-attribute-sets-coqpackages}
12+
13+The recommended way of defining a derivation for a Coq library, is to use the `coqPackages.mkCoqDerivation` function, which is essentially a specialization of `mkDerivation` taking into account most of the specifics of Coq libraries. The following attributes are supported:
14+
15+* `pname` (required) is the name of the package,
16+* `version` (optional, defaults to `null`), is the version to fetch and build,
17+ this attribute is interpreted in several ways depending on its type and pattern:
18+ * if it is a known released version string, i.e. from the `release` attribute below, the according release is picked, and the `version` attribute of the resulting derivation is set to this release string,
19+ * if it is a majorMinor `"x.y"` prefix of a known released version (as defined above), then the latest `"x.y.z"` known released version is selected (for the ordering given by `versionAtLeast`),
20+ * if it is a path or a string representing an absolute path (i.e. starting with `"/"`), the provided path is selected as a source, and the `version` attribute of the resulting derivation is set to `"dev"`,
21+ * if it is a string of the form `owner:branch` then it tries to download the `branch` of owner `owner` for a project of the same name using the same vcs, and the `version` attribute of the resulting derivation is set to `"dev"`, additionally if the owner is not provided (i.e. if the `owner:` prefix is missing), it defaults to the original owner of the package (see below),
22+ * if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
23+* `defaultVersion` (optional). Coq libraries may be compatible with some specific versions of Coq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `coq` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `coqPackages` attribute set.
24+* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `sha256` attribute (you may put the empty string `""` in order to automatically insert a fake sha256, this will trigger an error which will allow you to find the correct sha256), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
25+* `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `sha256` and returns an attribute set with a `version` and `src`.
26+* `repo` (optional, defaults to the value of `pname`),
27+* `owner` (optional, defaults to `"coq-community"`).
28+* `domain` (optional, defaults to `"github.com"`), domains including the strings `"github"` or `"gitlab"` in their names are automatically supported, otherwise, one must change the `fetcher` argument to support them (cf `pkgs/development/coq-modules/heq/default.nix` for an example),
29+* `releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
30+* `displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
31+* `namePrefix` (optional, defaults to `[ "coq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
32+* `extraNativeBuildInputs` (optional), by default `nativeBuildInputs` just contains `coq`, this allows to add more native build inputs, `nativeBuildInputs` are executables and `buildInputs` are libraries and dependencies,
33+* `extraBuildInputs` (optional), this allows to add more build inputs,
34+* `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `coq.ocamlPackages` attribute can be used in `extraBuildInputs` to depend on the same package set Coq was built against.
35+* `useDune2ifVersion` (optional, default to `(x: false)` uses Dune2 to build the package if the provided predicate evaluates to true on the version, e.g. `useDune2if = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
36+* `useDune2` (optional, defaults to `false`) uses Dune2 to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.
37+* `opam-name` (optional, defaults to concatenating with a dash separator the components of `namePrefix` and `pname`), name of the Dune package to build.
38+* `enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it.
39+* `extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variable `COQMF_COQLIB` so as to install in the proper subdirectory. Indeed Coq libraries should be installed in `$(out)/lib/coq/${coq.coq-version}/user-contrib/`. Such directories are automatically added to the `$COQPATH` environment variable by the hook defined in the Coq derivation.
40+* `setCOQBIN` (optional, defaults to `true`), by default, the environment variable `$COQBIN` is set to the current Coq's binary, but one can disable this behavior by setting it to `false`,
41+* `useMelquiondRemake` (optional, default to `null`) is an attribute set, which, if given, overloads the `preConfigurePhases`, `configureFlags`, `buildPhase`, and `installPhase` attributes of the derivation for a specific use in libraries using `remake` as set up by Guillaume Melquiond for `flocq`, `gappalib`, `interval`, and `coquelicot` (see the corresponding derivation for concrete examples of use of this option). For backward compatibility, the attribute `useMelquiondRemake.logpath` must be set to the logical root of the library (otherwise, one can pass `useMelquiondRemake = {}` to activate this without backward compatibility).
42+* `dropAttrs`, `keepAttrs`, `dropDerivationAttrs` are all optional and allow to tune which attribute is added or removed from the final call to `mkDerivation`.
43+
44+It also takes other standard `mkDerivation` attributes, they are added as such, except for `meta` which extends an automatically computed `meta` (where the `platform` is the same as `coq` and the homepage is automatically computed).
45+
46+Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes some `mathcomp` derivations as `extraBuildInputs`.
47+
48+```nix
49+{ lib, mkCoqDerivation, version ? null
50+, coq, mathcomp, mathcomp-finmap, mathcomp-bigenough }:
51+with lib; mkCoqDerivation {
52+ /* namePrefix leads to e.g. `name = coq8.11-mathcomp1.11-multinomials-1.5.2` */
53+ namePrefix = [ "coq" "mathcomp" ];
54+ pname = "multinomials";
55+ owner = "math-comp";
56+ inherit version;
57+ defaultVersion = with versions; switch [ coq.version mathcomp.version ] [
58+ { cases = [ (range "8.7" "8.12") "1.11.0" ]; out = "1.5.2"; }
59+ { cases = [ (range "8.7" "8.11") (range "1.8" "1.10") ]; out = "1.5.0"; }
60+ { cases = [ (range "8.7" "8.10") (range "1.8" "1.10") ]; out = "1.4"; }
61+ { cases = [ "8.6" (range "1.6" "1.7") ]; out = "1.1"; }
62+ ] null;
63+ release = {
64+ "1.5.2".sha256 = "15aspf3jfykp1xgsxf8knqkxv8aav2p39c2fyirw7pwsfbsv2c4s";
65+ "1.5.1".sha256 = "13nlfm2wqripaq671gakz5mn4r0xwm0646araxv0nh455p9ndjs3";
66+ "1.5.0".sha256 = "064rvc0x5g7y1a0nip6ic91vzmq52alf6in2bc2dmss6dmzv90hw";
67+ "1.5.0".rev = "1.5";
68+ "1.4".sha256 = "0vnkirs8iqsv8s59yx1fvg1nkwnzydl42z3scya1xp1b48qkgn0p";
69+ "1.3".sha256 = "0l3vi5n094nx3qmy66hsv867fnqm196r8v605kpk24gl0aa57wh4";
70+ "1.2".sha256 = "1mh1w339dslgv4f810xr1b8v2w7rpx6fgk9pz96q0fyq49fw2xcq";
71+ "1.1".sha256 = "1q8alsm89wkc0lhcvxlyn0pd8rbl2nnxg81zyrabpz610qqjqc3s";
72+ "1.0".sha256 = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
73+ };
74+
75+ propagatedBuildInputs =
76+ [ mathcomp.ssreflect mathcomp.algebra mathcomp-finmap mathcomp-bigenough ];
77+
78+ meta = {
79+ description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
80+ license = licenses.cecill-c;
81+ };
82+}
83+```
doc/languages-frameworks/coq.xmldeleted−64
@@ -1,64 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-coq">
4− <title>Coq</title>
5−
6− <para>
7− Coq libraries should be installed in
8− <literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such
9− directories are automatically added to the <literal>$COQPATH</literal>
10− environment variable by the hook defined in the Coq derivation.
11− </para>
12−
13− <para>
14− Some extensions (plugins) might require OCaml and sometimes other OCaml
15− packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
16− depend on the same package set Coq was built against.
17− </para>
18−
19− <para>
20− Coq libraries may be compatible with some specific versions of Coq only. The
21− <literal>compatibleCoqVersions</literal> attribute is used to precisely
22− select those versions of Coq that are compatible with this derivation.
23− </para>
24−
25− <para>
26− Here is a simple package example. It is a pure Coq library, thus it depends
27− on Coq. It builds on the Mathematical Components library, thus it also takes
28− <literal>mathcomp</literal> as <literal>buildInputs</literal>. Its
29− <literal>Makefile</literal> has been generated using
30− <literal>coq_makefile</literal> so we only have to set the
31− <literal>$COQLIB</literal> variable at install time.
32− </para>
33−
34−<programlisting>
35−{ stdenv, fetchFromGitHub, coq, mathcomp }:
36−
37−stdenv.mkDerivation rec {
38− name = "coq${coq.coq-version}-multinomials-${version}";
39− version = "1.0";
40− src = fetchFromGitHub {
41− owner = "math-comp";
42− repo = "multinomials";
43− rev = version;
44− sha256 = "1qmbxp1h81cy3imh627pznmng0kvv37k4hrwi2faa101s6bcx55m";
45− };
46−
47− buildInputs = [ coq ];
48− propagatedBuildInputs = [ mathcomp ];
49−
50− installFlags = "COQLIB=$(out)/lib/coq/${coq.coq-version}/";
51−
52− meta = {
53− description = "A Coq/SSReflect Library for Monoidal Rings and Multinomials";
54− inherit (src.meta) homepage;
55− license = stdenv.lib.licenses.cecill-b;
56− inherit (coq.meta) platforms;
57− };
58−
59− passthru = {
60− compatibleCoqVersions = v: builtins.elem v [ "8.5" "8.6" "8.7" ];
61− };
62−}
63−</programlisting>
64−</section>
doc/languages-frameworks/crystal.section.mdnew file+73
@@ -0,0 +1,73 @@
1+# Crystal {#crystal}
2+
3+## Building a Crystal package {#building-a-crystal-package}
4+
5+This section uses [Mint](https://github.com/mint-lang/mint) as an example for how to build a Crystal package.
6+
7+If the Crystal project has any dependencies, the first step is to get a `shards.nix` file encoding those. Get a copy of the project and go to its root directory such that its `shard.lock` file is in the current directory. Executable projects should usually commit the `shard.lock` file, but sometimes that's not the case, which means you need to generate it yourself. With an existing `shard.lock` file, `crystal2nix` can be run.
8+```bash
9+$ git clone https://github.com/mint-lang/mint
10+$ cd mint
11+$ git checkout 0.5.0
12+$ if [ ! -f shard.lock ]; then nix-shell -p shards --run "shards lock"; fi
13+$ nix-shell -p crystal2nix --run crystal2nix
14+```
15+
16+This should have generated a `shards.nix` file.
17+
18+Next create a Nix file for your derivation and use `pkgs.crystal.buildCrystalPackage` as follows:
19+
20+```nix
21+with import <nixpkgs> {};
22+crystal.buildCrystalPackage rec {
23+ pname = "mint";
24+ version = "0.5.0";
25+
26+ src = fetchFromGitHub {
27+ owner = "mint-lang";
28+ repo = "mint";
29+ rev = version;
30+ sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
31+ };
32+
33+ # Insert the path to your shards.nix file here
34+ shardsFile = ./shards.nix;
35+
36+ ...
37+}
38+```
39+
40+This won't build anything yet, because we haven't told it what files build. We can specify a mapping from binary names to source files with the `crystalBinaries` attribute. The project's compilation instructions should show this. For Mint, the binary is called "mint", which is compiled from the source file `src/mint.cr`, so we'll specify this as follows:
41+
42+```nix
43+ crystalBinaries.mint.src = "src/mint.cr";
44+
45+ # ...
46+```
47+
48+Additionally you can override the default `crystal build` options (which are currently `--release --progress --no-debug --verbose`) with
49+
50+```nix
51+ crystalBinaries.mint.options = [ "--release" "--verbose" ];
52+```
53+
54+Depending on the project, you might need additional steps to get it to compile successfully. In Mint's case, we need to link against openssl, so in the end the Nix file looks as follows:
55+
56+```nix
57+with import <nixpkgs> {};
58+crystal.buildCrystalPackage rec {
59+ version = "0.5.0";
60+ pname = "mint";
61+ src = fetchFromGitHub {
62+ owner = "mint-lang";
63+ repo = "mint";
64+ rev = version;
65+ sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
66+ };
67+
68+ shardsFile = ./shards.nix;
69+ crystalBinaries.mint.src = "src/mint.cr";
70+
71+ buildInputs = [ openssl ];
72+}
73+```
doc/languages-frameworks/cuda.section.mdnew file+34
@@ -0,0 +1,34 @@
1+# CUDA {#cuda}
2+
3+CUDA-only packages are stored in the `cudaPackages` packages set. This set
4+includes the `cudatoolkit`, portions of the toolkit in separate derivations,
5+`cudnn`, `cutensor` and `nccl`.
6+
7+A package set is available for each CUDA version, so for example
8+`cudaPackages_11_6`. Within each set is a matching version of the above listed
9+packages. Additionally, other versions of the packages that are packaged and
10+compatible are available as well. For example, there can be a
11+`cudaPackages.cudnn_8_3_2` package.
12+
13+To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional
14+```nix
15+cudaSupport ? false
16+cudaPackages ? {}
17+```
18+
19+When using `callPackage`, you can choose to pass in a different variant, e.g.
20+when a different version of the toolkit suffices
21+```nix
22+mypkg = callPackage { cudaPackages = cudaPackages_11_5; }
23+```
24+
25+If another version of say `cudnn` or `cutensor` is needed, you can override the
26+package set to make it the default. This guarantees you get a consistent package
27+set.
28+```nix
29+mypkg = let
30+ cudaPackages = cudaPackages_11_5.overrideScope' (final: prev {
31+ cudnn = prev.cudnn_8_3_2;
32+ }});
33+in callPackage { inherit cudaPackages; };
34+```
doc/languages-frameworks/dhall.section.mdnew file+463
@@ -0,0 +1,463 @@
1+# Dhall {#sec-language-dhall}
2+
3+The Nixpkgs support for Dhall assumes some familiarity with Dhall's language
4+support for importing Dhall expressions, which is documented here:
5+
6+* [`dhall-lang.org` - Installing packages](https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages)
7+
8+## Remote imports {#ssec-dhall-remote-imports}
9+
10+Nixpkgs bypasses Dhall's support for remote imports using Dhall's
11+semantic integrity checks. Specifically, any Dhall import can be protected by
12+an integrity check like:
13+
14+```dhall
15+https://prelude.dhall-lang.org/v20.1.0/package.dhall
16+ sha256:26b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
17+```
18+
19+… and if the import is cached then the interpreter will load the import from
20+cache instead of fetching the URL.
21+
22+Nixpkgs uses this trick to add all of a Dhall expression's dependencies into the
23+cache so that the Dhall interpreter never needs to resolve any remote URLs. In
24+fact, Nixpkgs uses a Dhall interpreter with remote imports disabled when
25+packaging Dhall expressions to enforce that the interpreter never resolves a
26+remote import. This means that Nixpkgs only supports building Dhall expressions
27+if all of their remote imports are protected by semantic integrity checks.
28+
29+Instead of remote imports, Nixpkgs uses Nix to fetch remote Dhall code. For
30+example, the Prelude Dhall package uses `pkgs.fetchFromGitHub` to fetch the
31+`dhall-lang` repository containing the Prelude. Relying exclusively on Nix
32+to fetch Dhall code ensures that Dhall packages built using Nix remain pure and
33+also behave well when built within a sandbox.
34+
35+## Packaging a Dhall expression from scratch {#ssec-dhall-packaging-expression}
36+
37+We can illustrate how Nixpkgs integrates Dhall by beginning from the following
38+trivial Dhall expression with one dependency (the Prelude):
39+
40+```dhall
41+-- ./true.dhall
42+
43+let Prelude = https://prelude.dhall-lang.org/v20.1.0/package.dhall
44+
45+in Prelude.Bool.not False
46+```
47+
48+As written, this expression cannot be built using Nixpkgs because the
49+expression does not protect the Prelude import with a semantic integrity
50+check, so the first step is to freeze the expression using `dhall freeze`,
51+like this:
52+
53+```ShellSession
54+$ dhall freeze --inplace ./true.dhall
55+```
56+
57+… which gives us:
58+
59+```dhall
60+-- ./true.dhall
61+
62+let Prelude =
63+ https://prelude.dhall-lang.org/v20.1.0/package.dhall
64+ sha256:26b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
65+
66+in Prelude.Bool.not False
67+```
68+
69+To package that expression, we create a `./true.nix` file containing the
70+following specification for the Dhall package:
71+
72+```nix
73+# ./true.nix
74+
75+{ buildDhallPackage, Prelude }:
76+
77+buildDhallPackage {
78+ name = "true";
79+ code = ./true.dhall;
80+ dependencies = [ Prelude ];
81+ source = true;
82+}
83+```
84+
85+… and we complete the build by incorporating that Dhall package into the
86+`pkgs.dhallPackages` hierarchy using an overlay, like this:
87+
88+```nix
89+# ./example.nix
90+
91+let
92+ nixpkgs = builtins.fetchTarball {
93+ url = "https://github.com/NixOS/nixpkgs/archive/94b2848559b12a8ed1fe433084686b2a81123c99.tar.gz";
94+ sha256 = "1pbl4c2dsaz2lximgd31m96jwbps6apn3anx8cvvhk1gl9rkg107";
95+ };
96+
97+ dhallOverlay = self: super: {
98+ true = self.callPackage ./true.nix { };
99+ };
100+
101+ overlay = self: super: {
102+ dhallPackages = super.dhallPackages.override (old: {
103+ overrides =
104+ self.lib.composeExtensions (old.overrides or (_: _: {})) dhallOverlay;
105+ });
106+ };
107+
108+ pkgs = import nixpkgs { config = {}; overlays = [ overlay ]; };
109+
110+in
111+ pkgs
112+```
113+
114+… which we can then build using this command:
115+
116+```ShellSession
117+$ nix build --file ./example.nix dhallPackages.true
118+```
119+
120+## Contents of a Dhall package {#ssec-dhall-package-contents}
121+
122+The above package produces the following directory tree:
123+
124+```ShellSession
125+$ tree -a ./result
126+result
127+├── .cache
128+│ └── dhall
129+│ └── 122027abdeddfe8503496adeb623466caa47da5f63abd2bc6fa19f6cfcb73ecfed70
130+├── binary.dhall
131+└── source.dhall
132+```
133+
134+… where:
135+
136+* `source.dhall` contains the result of interpreting our Dhall package:
137+
138+ ```ShellSession
139+ $ cat ./result/source.dhall
140+ True
141+ ```
142+
143+* The `.cache` subdirectory contains one binary cache product encoding the
144+ same result as `source.dhall`:
145+
146+ ```ShellSession
147+ $ dhall decode < ./result/.cache/dhall/122027abdeddfe8503496adeb623466caa47da5f63abd2bc6fa19f6cfcb73ecfed70
148+ True
149+ ```
150+
151+* `binary.dhall` contains a Dhall expression which handles fetching and decoding
152+ the same cache product:
153+
154+ ```ShellSession
155+ $ cat ./result/binary.dhall
156+ missing sha256:27abdeddfe8503496adeb623466caa47da5f63abd2bc6fa19f6cfcb73ecfed70
157+ $ cp -r ./result/.cache .cache
158+
159+ $ chmod -R u+w .cache
160+
161+ $ XDG_CACHE_HOME=.cache dhall --file ./result/binary.dhall
162+ True
163+ ```
164+
165+The `source.dhall` file is only present for packages that specify
166+`source = true;`. By default, Dhall packages omit the `source.dhall` in order
167+to conserve disk space when they are used exclusively as dependencies. For
168+example, if we build the Prelude package it will only contain the binary
169+encoding of the expression:
170+
171+```ShellSession
172+$ nix build --file ./example.nix dhallPackages.Prelude
173+
174+$ tree -a result
175+result
176+├── .cache
177+│ └── dhall
178+│ └── 122026b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
179+└── binary.dhall
180+
181+2 directories, 2 files
182+```
183+
184+Typically, you only specify `source = true;` for the top-level Dhall expression
185+of interest (such as our example `true.nix` Dhall package). However, if you
186+wish to specify `source = true` for all Dhall packages, then you can amend the
187+Dhall overlay like this:
188+
189+```nix
190+ dhallOverrides = self: super: {
191+ # Enable source for all Dhall packages
192+ buildDhallPackage =
193+ args: super.buildDhallPackage (args // { source = true; });
194+
195+ true = self.callPackage ./true.nix { };
196+ };
197+```
198+
199+… and now the Prelude will contain the fully decoded result of interpreting
200+the Prelude:
201+
202+```ShellSession
203+$ nix build --file ./example.nix dhallPackages.Prelude
204+
205+$ tree -a result
206+result
207+├── .cache
208+│ └── dhall
209+│ └── 122026b0ef498663d269e4dc6a82b0ee289ec565d683ef4c00d0ebdd25333a5a3c98
210+├── binary.dhall
211+└── source.dhall
212+
213+$ cat ./result/source.dhall
214+{ Bool =
215+ { and =
216+ \(_ : List Bool) ->
217+ List/fold Bool _ Bool (\(_ : Bool) -> \(_ : Bool) -> _@1 && _) True
218+ , build = \(_ : Type -> _ -> _@1 -> _@2) -> _ Bool True False
219+ , even =
220+ \(_ : List Bool) ->
221+ List/fold Bool _ Bool (\(_ : Bool) -> \(_ : Bool) -> _@1 == _) True
222+ , fold =
223+ \(_ : Bool) ->
224+…
225+```
226+
227+## Packaging functions {#ssec-dhall-packaging-functions}
228+
229+We already saw an example of using `buildDhallPackage` to create a Dhall
230+package from a single file, but most Dhall packages consist of more than one
231+file and there are two derived utilities that you may find more useful when
232+packaging multiple files:
233+
234+* `buildDhallDirectoryPackage` - build a Dhall package from a local directory
235+
236+* `buildDhallGitHubPackage` - build a Dhall package from a GitHub repository
237+
238+The `buildDhallPackage` is the lowest-level function and accepts the following
239+arguments:
240+
241+* `name`: The name of the derivation
242+
243+* `dependencies`: Dhall dependencies to build and cache ahead of time
244+
245+* `code`: The top-level expression to build for this package
246+
247+ Note that the `code` field accepts an arbitrary Dhall expression. You're
248+ not limited to just a file.
249+
250+* `source`: Set to `true` to include the decoded result as `source.dhall` in the
251+ build product, at the expense of requiring more disk space
252+
253+* `documentationRoot`: Set to the root directory of the package if you want
254+ `dhall-docs` to generate documentation underneath the `docs` subdirectory of
255+ the build product
256+
257+The `buildDhallDirectoryPackage` is a higher-level function implemented in terms
258+of `buildDhallPackage` that accepts the following arguments:
259+
260+* `name`: Same as `buildDhallPackage`
261+
262+* `dependencies`: Same as `buildDhallPackage`
263+
264+* `source`: Same as `buildDhallPackage`
265+
266+* `src`: The directory containing Dhall code that you want to turn into a Dhall
267+ package
268+
269+* `file`: The top-level file (`package.dhall` by default) that is the entrypoint
270+ to the rest of the package
271+
272+* `document`: Set to `true` to generate documentation for the package
273+
274+The `buildDhallGitHubPackage` is another higher-level function implemented in
275+terms of `buildDhallPackage` that accepts the following arguments:
276+
277+* `name`: Same as `buildDhallPackage`
278+
279+* `dependencies`: Same as `buildDhallPackage`
280+
281+* `source`: Same as `buildDhallPackage`
282+
283+* `owner`: The owner of the repository
284+
285+* `repo`: The repository name
286+
287+* `rev`: The desired revision (or branch, or tag)
288+
289+* `directory`: The subdirectory of the Git repository to package (if a
290+ directory other than the root of the repository)
291+
292+* `file`: The top-level file (`${directory}/package.dhall` by default) that is
293+ the entrypoint to the rest of the package
294+
295+* `document`: Set to `true` to generate documentation for the package
296+
297+Additionally, `buildDhallGitHubPackage` accepts the same arguments as
298+`fetchFromGitHub`, such as `sha256` or `fetchSubmodules`.
299+
300+## `dhall-to-nixpkgs` {#ssec-dhall-dhall-to-nixpkgs}
301+
302+You can use the `dhall-to-nixpkgs` command-line utility to automate
303+packaging Dhall code. For example:
304+
305+```ShellSession
306+$ nix-env --install --attr haskellPackages.dhall-nixpkgs
307+
308+$ nix-env --install --attr nix-prefetch-git # Used by dhall-to-nixpkgs
309+
310+$ dhall-to-nixpkgs github https://github.com/Gabriel439/dhall-semver.git
311+{ buildDhallGitHubPackage, Prelude }:
312+ buildDhallGitHubPackage {
313+ name = "dhall-semver";
314+ githubBase = "github.com";
315+ owner = "Gabriel439";
316+ repo = "dhall-semver";
317+ rev = "2d44ae605302ce5dc6c657a1216887fbb96392a4";
318+ fetchSubmodules = false;
319+ sha256 = "0y8shvp8srzbjjpmnsvz9c12ciihnx1szs0yzyi9ashmrjvd0jcz";
320+ directory = "";
321+ file = "package.dhall";
322+ source = false;
323+ document = false;
324+ dependencies = [ (Prelude.overridePackage { file = "package.dhall"; }) ];
325+ }
326+```
327+
328+The utility takes care of automatically detecting remote imports and converting
329+them to package dependencies. You can also use the utility on local
330+Dhall directories, too:
331+
332+```ShellSession
333+$ dhall-to-nixpkgs directory ~/proj/dhall-semver
334+{ buildDhallDirectoryPackage, Prelude }:
335+ buildDhallDirectoryPackage {
336+ name = "proj";
337+ src = ~/proj/dhall-semver;
338+ file = "package.dhall";
339+ source = false;
340+ document = false;
341+ dependencies = [ (Prelude.overridePackage { file = "package.dhall"; }) ];
342+ }
343+```
344+
345+### Remote imports as fixed-output derivations {#ssec-dhall-remote-imports-as-fod}
346+
347+`dhall-to-nixpkgs` has the ability to fetch and build remote imports as
348+fixed-output derivations by using their Dhall integrity check. This is
349+sometimes easier than manually packaging all remote imports.
350+
351+This can be used like the following:
352+
353+```ShellSession
354+$ dhall-to-nixpkgs directory --fixed-output-derivations ~/proj/dhall-semver
355+{ buildDhallDirectoryPackage, buildDhallUrl }:
356+ buildDhallDirectoryPackage {
357+ name = "proj";
358+ src = ~/proj/dhall-semver;
359+ file = "package.dhall";
360+ source = false;
361+ document = false;
362+ dependencies = [
363+ (buildDhallUrl {
364+ url = "https://prelude.dhall-lang.org/v17.0.0/package.dhall";
365+ hash = "sha256-ENs8kZwl6QRoM9+Jeo/+JwHcOQ+giT2VjDQwUkvlpD4=";
366+ dhallHash = "sha256:10db3c919c25e9046833df897a8ffe2701dc390fa0893d958c3430524be5a43e";
367+ })
368+ ];
369+ }
370+```
371+
372+Here, `dhall-semver`'s `Prelude` dependency is fetched and built with the
373+`buildDhallUrl` helper function, instead of being passed in as a function
374+argument.
375+
376+## Overriding dependency versions {#ssec-dhall-overriding-dependency-versions}
377+
378+Suppose that we change our `true.dhall` example expression to depend on an older
379+version of the Prelude (19.0.0):
380+
381+```dhall
382+-- ./true.dhall
383+
384+let Prelude =
385+ https://prelude.dhall-lang.org/v19.0.0/package.dhall
386+ sha256:eb693342eb769f782174157eba9b5924cf8ac6793897fc36a31ccbd6f56dafe2
387+
388+in Prelude.Bool.not False
389+```
390+
391+If we try to rebuild that expression the build will fail:
392+
393+```ShellSession
394+$ nix build --file ./example.nix dhallPackages.true
395+builder for '/nix/store/0f1hla7ff1wiaqyk1r2ky4wnhnw114fi-true.drv' failed with exit code 1; last 10 log lines:
396+
397+ Dhall was compiled without the 'with-http' flag.
398+
399+ The requested URL was: https://prelude.dhall-lang.org/v19.0.0/package.dhall
400+
401+
402+ 4│ https://prelude.dhall-lang.org/v19.0.0/package.dhall
403+ 5│ sha256:eb693342eb769f782174157eba9b5924cf8ac6793897fc36a31ccbd6f56dafe2
404+
405+ /nix/store/rsab4y99h14912h4zplqx2iizr5n4rc2-true.dhall:4:7
406+[1 built (1 failed), 0.0 MiB DL]
407+error: build of '/nix/store/0f1hla7ff1wiaqyk1r2ky4wnhnw114fi-true.drv' failed
408+```
409+
410+… because the default Prelude selected by Nixpkgs revision
411+`94b2848559b12a8ed1fe433084686b2a81123c99is` is version 20.1.0, which doesn't
412+have the same integrity check as version 19.0.0. This means that version
413+19.0.0 is not cached and the interpreter is not allowed to fall back to
414+importing the URL.
415+
416+However, we can override the default Prelude version by using `dhall-to-nixpkgs`
417+to create a Dhall package for our desired Prelude:
418+
419+```ShellSession
420+$ dhall-to-nixpkgs github https://github.com/dhall-lang/dhall-lang.git \
421+ --name Prelude \
422+ --directory Prelude \
423+ --rev v19.0.0 \
424+ > Prelude.nix
425+```
426+
427+… and then referencing that package in our Dhall overlay, by either overriding
428+the Prelude globally for all packages, like this:
429+
430+```nix
431+ dhallOverrides = self: super: {
432+ true = self.callPackage ./true.nix { };
433+
434+ Prelude = self.callPackage ./Prelude.nix { };
435+ };
436+```
437+
438+… or selectively overriding the Prelude dependency for just the `true` package,
439+like this:
440+
441+```nix
442+ dhallOverrides = self: super: {
443+ true = self.callPackage ./true.nix {
444+ Prelude = self.callPackage ./Prelude.nix { };
445+ };
446+ };
447+```
448+
449+## Overrides {#ssec-dhall-overrides}
450+
451+You can override any of the arguments to `buildDhallGitHubPackage` or
452+`buildDhallDirectoryPackage` using the `overridePackage` attribute of a package.
453+For example, suppose we wanted to selectively enable `source = true` just for the Prelude. We can do that like this:
454+
455+```nix
456+ dhallOverrides = self: super: {
457+ Prelude = super.Prelude.overridePackage { source = true; };
458+
459+ …
460+ };
461+```
462+
463+[semantic-integrity-checks]: https://docs.dhall-lang.org/tutorials/Language-Tour.html#installing-packages
doc/languages-frameworks/dotnet.section.mdnew file+132
@@ -0,0 +1,132 @@
1+# Dotnet {#dotnet}
2+
3+## Local Development Workflow {#local-development-workflow}
4+
5+For local development, it's recommended to use nix-shell to create a dotnet environment:
6+
7+```nix
8+# shell.nix
9+with import <nixpkgs> {};
10+
11+mkShell {
12+ name = "dotnet-env";
13+ packages = [
14+ dotnet-sdk_3
15+ ];
16+}
17+```
18+
19+### Using many sdks in a workflow {#using-many-sdks-in-a-workflow}
20+
21+It's very likely that more than one sdk will be needed on a given project. Dotnet provides several different frameworks (E.g dotnetcore, aspnetcore, etc.) as well as many versions for a given framework. Normally, dotnet is able to fetch a framework and install it relative to the executable. However, this would mean writing to the nix store in nixpkgs, which is read-only. To support the many-sdk use case, one can compose an environment using `dotnetCorePackages.combinePackages`:
22+
23+```nix
24+with import <nixpkgs> {};
25+
26+mkShell {
27+ name = "dotnet-env";
28+ packages = [
29+ (with dotnetCorePackages; combinePackages [
30+ sdk_3_1
31+ sdk_5_0
32+ ])
33+ ];
34+}
35+```
36+
37+This will produce a dotnet installation that has the dotnet 3.1, 3.0, and 2.1 sdk. The first sdk listed will have it's cli utility present in the resulting environment. Example info output:
38+
39+```ShellSession
40+$ dotnet --info
41+.NET Core SDK (reflecting any global.json):
42+ Version: 3.1.101
43+ Commit: b377529961
44+
45+...
46+
47+.NET Core SDKs installed:
48+ 2.1.803 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
49+ 3.0.102 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
50+ 3.1.101 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/sdk]
51+
52+.NET Core runtimes installed:
53+ Microsoft.AspNetCore.All 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.All]
54+ Microsoft.AspNetCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
55+ Microsoft.AspNetCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
56+ Microsoft.AspNetCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
57+ Microsoft.NETCore.App 2.1.15 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
58+ Microsoft.NETCore.App 3.0.2 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
59+ Microsoft.NETCore.App 3.1.1 [/nix/store/iiv98i2jdi226dgh4jzkkj2ww7f8jgpd-dotnet-core-combined/shared/Microsoft.NETCore.App]
60+```
61+
62+## dotnet-sdk vs dotnetCorePackages.sdk {#dotnet-sdk-vs-dotnetcorepackages.sdk}
63+
64+The `dotnetCorePackages.sdk_X_Y` is preferred over the old dotnet-sdk as both major and minor version are very important for a dotnet environment. If a given minor version isn't present (or was changed), then this will likely break your ability to build a project.
65+
66+## dotnetCorePackages.sdk vs dotnetCorePackages.runtime vs dotnetCorePackages.aspnetcore {#dotnetcorepackages.sdk-vs-dotnetcorepackages.runtime-vs-dotnetcorepackages.aspnetcore}
67+
68+The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given version. The `runtime` and `aspnetcore` packages are meant to serve as minimal runtimes to deploy alongside already built applications.
69+
70+## Packaging a Dotnet Application {#packaging-a-dotnet-application}
71+
72+To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions:
73+
74+* `projectFile` has to be used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well.
75+* `nugetDeps` has to be used to specify the NuGet dependency file. Unfortunately, these cannot be deterministically fetched without a lockfile. A script to fetch these is available as `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs.
76+* `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`.
77+* `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well.
78+ For example, your project has a local dependency:
79+ ```xml
80+ <ProjectReference Include="../foo/bar.fsproj" />
81+ ```
82+ To enable discovery through `projectReferences` you would need to add:
83+ ```xml
84+ <ProjectReference Include="../foo/bar.fsproj" />
85+ <PackageReference Include="bar" Version="*" Condition=" '$(ContinuousIntegrationBuild)'=='true' "/>
86+ ```
87+* `executables` is used to specify which executables get wrapped to `$out/bin`, relative to `$out/lib/$pname`. If this is unset, all executables generated will get installed. If you do not want to install any, set this to `[]`. This gets done in the `preFixup` phase.
88+* `runtimeDeps` is used to wrap libraries into `LD_LIBRARY_PATH`. This is how dotnet usually handles runtime dependencies.
89+* `buildType` is used to change the type of build. Possible values are `Release`, `Debug`, etc. By default, this is set to `Release`.
90+* `dotnet-sdk` is useful in cases where you need to change what dotnet SDK is being used.
91+* `dotnet-runtime` is useful in cases where you need to change what dotnet runtime is being used. This can be either a regular dotnet runtime, or an aspnetcore.
92+* `dotnet-test-sdk` is useful in cases where unit tests expect a different dotnet SDK. By default, this is set to the `dotnet-sdk` attribute.
93+* `testProjectFile` is useful in cases where the regular project file does not contain the unit tests. It gets restored and build, but not installed. You may need to regenerate your nuget lockfile after setting this.
94+* `disabledTests` is used to disable running specific unit tests. This gets passed as: `dotnet test --filter "FullyQualifiedName!={}"`, to ensure compatibility with all unit test frameworks.
95+* `dotnetRestoreFlags` can be used to pass flags to `dotnet restore`.
96+* `dotnetBuildFlags` can be used to pass flags to `dotnet build`.
97+* `dotnetTestFlags` can be used to pass flags to `dotnet test`. Used only if `doCheck` is set to `true`.
98+* `dotnetInstallFlags` can be used to pass flags to `dotnet install`.
99+* `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`.
100+* `dotnetFlags` can be used to pass flags to all of the above phases.
101+
102+When packaging a new application, you need to fetch it's dependencies. You can set `nugetDeps` to an empty string to make the derivation temporarily evaluate, and then run `nix-build -A package.passthru.fetch-deps` to generate it's dependency fetching script. After running the script, you should have the location of the generated lockfile printed to the console. This can be copied to a stable directory. Note that if either `projectFile` or `nugetDeps` are unset, this script cannot be generated!
103+
104+Here is an example `default.nix`, using some of the previously discussed arguments:
105+```nix
106+{ lib, buildDotnetModule, dotnetCorePackages, ffmpeg }:
107+
108+let
109+ referencedProject = import ../../bar { ... };
110+in buildDotnetModule rec {
111+ pname = "someDotnetApplication";
112+ version = "0.1";
113+
114+ src = ./.;
115+
116+ projectFile = "src/project.sln";
117+ nugetDeps = ./deps.nix; # File generated with `nix-build -A package.passthru.fetch-deps`.
118+
119+ projectReferences = [ referencedProject ]; # `referencedProject` must contain `nupkg` in the folder structure.
120+
121+ dotnet-sdk = dotnetCorePackages.sdk_3_1;
122+ dotnet-runtime = dotnetCorePackages.net_5_0;
123+ dotnetFlags = [ "--runtime linux-x64" ];
124+
125+ executables = [ "foo" ]; # This wraps "$out/lib/$pname/foo" to `$out/bin/foo`.
126+ executables = []; # Don't install any executables.
127+
128+ packNupkg = true; # This packs the project as "foo-0.1.nupkg" at `$out/share`.
129+
130+ runtimeDeps = [ ffmpeg ]; # This will wrap ffmpeg's library path into `LD_LIBRARY_PATH`.
131+}
132+```
doc/languages-frameworks/emscripten.section.md+20−23
@@ -1,4 +1,4 @@
1−# User's Guide to Emscripten in Nixpkgs
1+# Emscripten {#emscripten}
22
33[Emscripten](https://github.com/kripken/emscripten): An LLVM-to-JavaScript Compiler
44
@@ -15,28 +15,26 @@ Modes of use of `emscripten`:
1515
1616 If you want to work with `emcc`, `emconfigure` and `emmake` as you are used to from Ubuntu and similar distributions you can use these commands:
1717
18− * `nix-env -i emscripten`
18+ * `nix-env -f "<nixpkgs>" -iA emscripten`
1919 * `nix-shell -p emscripten`
2020
2121* **Declarative usage**:
2222
23− This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`.
24− * build and install all packages:
25− * `nix-env -iA emscriptenPackages`
26−
27− * dev-shell for zlib implementation hacking:
28− * `nix-shell -A emscriptenPackages.zlib`
23+ This mode is far more power full since this makes use of `nix` for dependency management of emscripten libraries and targets by using the `mkDerivation` which is implemented by `pkgs.emscriptenStdenv` and `pkgs.buildEmscriptenPackage`. The source for the packages is in `pkgs/top-level/emscripten-packages.nix` and the abstraction behind it in `pkgs/development/em-modules/generic/default.nix`. From the root of the nixpkgs repository:
24+ * build and install all packages:
25+ * `nix-env -iA emscriptenPackages`
2926
27+ * dev-shell for zlib implementation hacking:
28+ * `nix-shell -A emscriptenPackages.zlib`
3029
31−## Imperative usage
30+## Imperative usage {#imperative-usage}
3231
3332A few things to note:
3433
3534* `export EMCC_DEBUG=2` is nice for debugging
3635* `~/.emscripten`, the build artifact cache sometimes creates issues and needs to be removed from time to time
3736
38−
39−## Declarative usage
37+## Declarative usage {#declarative-usage}
4038
4139Let's see two different examples from `pkgs/top-level/emscripten-packages.nix`:
4240
@@ -50,7 +48,7 @@ A special requirement of the `pkgs.buildEmscriptenPackage` is the `doCheck = tru
5048* Use `export EMCC_DEBUG=2` from within a emscriptenPackage's `phase` to get more detailed debug output what is going wrong.
5149* ~/.emscripten cache is requiring us to set `HOME=$TMPDIR` in individual phases. This makes compilation slower but also makes it more deterministic.
5250
53−### Usage 1: pkgs.zlib.override
51+### Usage 1: pkgs.zlib.override {#usage-1-pkgs.zlib.override}
5452
5553This example uses `zlib` from nixpkgs but instead of compiling **C** to **ELF** it compiles **C** to **JS** since we were using `pkgs.zlib.override` and changed stdenv to `pkgs.emscriptenStdenv`. A few adaptions and hacks were set in place to make it working. One advantage is that when `pkgs.zlib` is updated, it will automatically update this package as well. However, this can also be the downside...
5654
@@ -60,7 +58,7 @@ See the `zlib` example:
6058 stdenv = pkgs.emscriptenStdenv;
6159 }).overrideDerivation
6260 (old: rec {
63− buildInputs = old.buildInputs ++ [ pkgconfig ];
61+ buildInputs = old.buildInputs ++ [ pkg-config ];
6462 # we need to reset this setting!
6563 NIX_CFLAGS_COMPILE="";
6664 configurePhase = ''
@@ -90,7 +88,7 @@ See the `zlib` example:
9088 libz.so.${old.version} -I . -o example.js
9189
9290 echo "Using node to execute the test"
93− ${pkgs.nodejs}/bin/node ./example.js
91+ ${pkgs.nodejs}/bin/node ./example.js
9492
9593 set +x
9694 if [ $? -ne 0 ]; then
@@ -102,7 +100,7 @@ See the `zlib` example:
102100 echo "================= /testing zlib using node ================="
103101 '';
104102
105− postPatch = pkgs.stdenv.lib.optionalString pkgs.stdenv.isDarwin ''
103+ postPatch = pkgs.lib.optionalString pkgs.stdenv.isDarwin ''
106104 substituteInPlace configure \
107105 --replace '/usr/bin/libtool' 'ar' \
108106 --replace 'AR="libtool"' 'AR="ar"' \
@@ -110,15 +108,15 @@ See the `zlib` example:
110108 '';
111109 });
112110
113−### Usage 2: pkgs.buildEmscriptenPackage
111+### Usage 2: pkgs.buildEmscriptenPackage {#usage-2-pkgs.buildemscriptenpackage}
114112
115−This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
113+This `xmlmirror` example features a emscriptenPackage which is defined completely from this context and no `pkgs.zlib.override` is used.
116114
117115 xmlmirror = pkgs.buildEmscriptenPackage rec {
118116 name = "xmlmirror";
119117
120− buildInputs = [ pkgconfig autoconf automake libtool gnumake libxml2 nodejs openjdk json_c ];
121− nativeBuildInputs = [ pkgconfig zlib ];
118+ buildInputs = [ pkg-config autoconf automake libtool gnumake libxml2 nodejs openjdk json_c ];
119+ nativeBuildInputs = [ pkg-config zlib ];
122120
123121 src = pkgs.fetchgit {
124122 url = "https://gitlab.com/odfplugfest/xmlmirror.git";
@@ -163,9 +161,9 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
163161 checkPhase = ''
164162
165163 '';
166− };
164+ };
167165
168−### Declarative debugging
166+### Declarative debugging {#declarative-debugging}
169167
170168Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from there you can go trough the individual steps. This makes it easy to build a good `unit test` or list the files of the project.
171169
@@ -177,9 +175,8 @@ Use `nix-shell -I nixpkgs=/some/dir/nixpkgs -A emscriptenPackages.libz` and from
1771756. `buildPhase`
1781767. ... happy hacking...
179177
180−## Summary
178+## Summary {#summary}
181179
182180Using this toolchain makes it easy to leverage `nix` from NixOS, MacOSX or even Windows (WSL+ubuntu+nix). This toolchain is reproducible, behaves like the rest of the packages from nixpkgs and contains a set of well working examples to learn and adapt from.
183181
184182If in trouble, ask the maintainers.
185−
doc/languages-frameworks/gnome.section.mdnew file+218
@@ -0,0 +1,218 @@
1+# GNOME {#sec-language-gnome}
2+
3+## Packaging GNOME applications {#ssec-gnome-packaging}
4+
5+Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. [Wrapping](#fun-wrapProgram) the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
6+
7+### Settings {#ssec-gnome-settings}
8+
9+[GSettings](https://developer.gnome.org/gio/stable/GSettings.html) API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for `glib-2.0/schemas/gschemas.compiled` files inside the directories of `XDG_DATA_DIRS`.
10+
11+On Linux, GSettings API is implemented using [dconf](https://wiki.gnome.org/Projects/dconf) backend. You will need to add `dconf` [GIO module](#ssec-gnome-gio-modules) to `GIO_EXTRA_MODULES` variable, otherwise the `memory` backend will be used and the saved settings will not be persistent.
12+
13+Last you will need the dconf database D-Bus service itself. You can enable it using `programs.dconf.enable`.
14+
15+Some applications will also require `gsettings-desktop-schemas` for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for `org.gnome.desktop` and `org.gnome.system` to see if the schemas are needed.
16+
17+### GIO modules {#ssec-gnome-gio-modules}
18+
19+GLib’s [GIO](https://developer.gnome.org/gio/stable/ch01.html) library supports several [extension points](https://developer.gnome.org/gio/stable/extending-gio.html). Notably, they allow:
20+
21+* implementing settings backends (already [mentioned](#ssec-gnome-settings))
22+* adding TLS support
23+* proxy settings
24+* virtual file systems
25+
26+The modules are typically installed to `lib/gio/modules/` directory of a package and you need to add them to `GIO_EXTRA_MODULES` if you need any of those features.
27+
28+In particular, we recommend:
29+
30+* adding `dconf.lib` for any software on Linux that reads [GSettings](#ssec-gnome-settings) (even transitivily through e.g. GTK’s file manager)
31+* adding `glib-networking` for any software that accesses network using GIO or libsoup – glib-networking contains a module that implements TLS support and loads system-wide proxy settings
32+
33+To allow software to use various virtual file systems, `gvfs` package can be also added. But that is usually an optional feature so we typically use `gvfs` from the system (e.g. installed globally using NixOS module).
34+
35+### GdkPixbuf loaders {#ssec-gnome-gdk-pixbuf-loaders}
36+
37+GTK applications typically use [GdkPixbuf](https://developer.gnome.org/gdk-pixbuf/stable/) to load images. But `gdk-pixbuf` package only supports basic bitmap formats like JPEG, PNG or TIFF, requiring to use third-party loader modules for other formats. This is especially painful since GTK itself includes SVG icons, which cannot be rendered without a loader provided by `librsvg`.
38+
39+Unlike other libraries mentioned in this section, GdkPixbuf only supports a single value in its controlling environment variable `GDK_PIXBUF_MODULE_FILE`. It is supposed to point to a cache file containing information about the available loaders. Each loader package will contain a `lib/gdk-pixbuf-2.0/2.10.0/loaders.cache` file describing the default loaders in `gdk-pixbuf` package plus the loader contained in the package itself. If you want to use multiple third-party loaders, you will need to create your own cache file manually. Fortunately, this is pretty rare as [not many loaders exist](https://gitlab.gnome.org/federico/gdk-pixbuf-survey/blob/master/src/modules.md).
40+
41+`gdk-pixbuf` contains [a setup hook](#ssec-gnome-hooks-gdk-pixbuf) that sets `GDK_PIXBUF_MODULE_FILE` from dependencies but as mentioned in further section, it is pretty limited. Loaders should propagate this setup hook.
42+
43+### Icons {#ssec-gnome-icons}
44+
45+When an application uses icons, an icon theme should be available in `XDG_DATA_DIRS` during runtime. The package for the default, icon-less [hicolor-icon-theme](https://www.freedesktop.org/wiki/Software/icon-theme/) (should be propagated by every icon theme) contains [a setup hook](#ssec-gnome-hooks-hicolor-icon-theme) that will pick up icon themes from `buildInputs` and add their datadirs to `XDG_ICON_DIRS` environment variable (this is Nixpkgs specific, not actually a XDG standard variable). Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
46+
47+In the rare case you need to use icons from dependencies (e.g. when an app forces an icon theme), you can use the following to pick them up:
48+
49+```nix
50+ buildInputs = [
51+ pantheon.elementary-icon-theme
52+ ];
53+ preFixup = ''
54+ gappsWrapperArgs+=(
55+ # The icon theme is hardcoded.
56+ --prefix XDG_DATA_DIRS : "$XDG_ICON_DIRS"
57+ )
58+ '';
59+```
60+
61+To avoid costly file system access when locating icons, GTK, [as well as Qt](https://woboq.com/blog/qicon-reads-gtk-icon-cache-in-qt57.html), can rely on `icon-theme.cache` files from the themes' top-level directories. These files are generated using `gtk-update-icon-cache`, which is expected to be run whenever an icon is added or removed to an icon theme (typically an application icon into `hicolor` theme) and some programs do indeed run this after icon installation. However, since packages are installed into their own prefix by Nix, this would lead to conflicts. For that reason, `gtk3` provides a [setup hook](#ssec-gnome-hooks-gtk-drop-icon-theme-cache) that will clean the file from installation. Since most applications only ship their own icon that will be loaded on start-up, it should not affect them too much. On the other hand, icon themes are much larger and more widely used so we need to cache them. Because we recommend installing icon themes globally, we will generate the cache files from all packages in a profile using a NixOS module. You can enable the cache generation using `gtk.iconCache.enable` option if your desktop environment does not already do that.
62+
63+### Packaging icon themes {#ssec-icon-theme-packaging}
64+
65+Icon themes may inherit from other icon themes. The inheritance is specified using the `Inherits` key in the `index.theme` file distributed with the icon theme. According to the [icon theme specification](https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html), icons not provided by the theme are looked for in its parent icon themes. Therefore the parent themes should be installed as dependencies for a more complete experience regarding the icon sets used.
66+
67+The package `hicolor-icon-theme` provides a setup hook which makes symbolic links for the parent themes into the directory `share/icons` of the current theme directory in the nix store, making sure they can be found at runtime. For that to work the packages providing parent icon themes should be listed as propagated build dependencies, together with `hicolor-icon-theme`.
68+
69+Also make sure that `icon-theme.cache` is installed for each theme provided by the package, and set `dontDropIconThemeCache` to `true` so that the cache file is not removed by the `gtk3` setup hook.
70+
71+### GTK Themes {#ssec-gnome-themes}
72+
73+Previously, a GTK theme needed to be in `XDG_DATA_DIRS`. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for [elementary HIG](https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines)) might require a special theme like `pantheon.elementary-gtk-theme`.
74+
75+### GObject introspection typelibs {#ssec-gnome-typelibs}
76+
77+[GObject introspection](https://wiki.gnome.org/Projects/GObjectIntrospection) allows applications to use C libraries in other languages easily. It does this through `typelib` files searched in `GI_TYPELIB_PATH`.
78+
79+### Various plug-ins {#ssec-gnome-plugins}
80+
81+If your application uses [GStreamer](https://gstreamer.freedesktop.org/) or [Grilo](https://wiki.gnome.org/Projects/Grilo), you should set `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH`, respectively.
82+
83+## Onto `wrapGAppsHook` {#ssec-gnome-hooks}
84+
85+Given the requirements above, the package expression would become messy quickly:
86+
87+```nix
88+preFixup = ''
89+ for f in $(find $out/bin/ $out/libexec/ -type f -executable); do
90+ wrapProgram "$f" \
91+ --prefix GIO_EXTRA_MODULES : "${getLib dconf}/lib/gio/modules" \
92+ --prefix XDG_DATA_DIRS : "$out/share" \
93+ --prefix XDG_DATA_DIRS : "$out/share/gsettings-schemas/${name}" \
94+ --prefix XDG_DATA_DIRS : "${gsettings-desktop-schemas}/share/gsettings-schemas/${gsettings-desktop-schemas.name}" \
95+ --prefix XDG_DATA_DIRS : "${hicolor-icon-theme}/share" \
96+ --prefix GI_TYPELIB_PATH : "${lib.makeSearchPath "lib/girepository-1.0" [ pango json-glib ]}"
97+ done
98+'';
99+```
100+
101+Fortunately, there is [`wrapGAppsHook`]{#ssec-gnome-hooks-wrapgappshook}. It works in conjunction with other setup hooks that populate environment variables, and it will then wrap all executables in `bin` and `libexec` directories using said variables.
102+
103+For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure. There is also [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4}, which replaces GTK 3 with GTK 4. And in case you are packaging a program without a graphical interface, you might want to use [`wrapGAppsNoGuiHook`]{#ssec-gnome-hooks-wrapgappsnoguihook}, which runs the same script as `wrapGAppsHook` but does not bring `gtk3` and `librsvg` into the closure.
104+
105+- `wrapGAppsHook` itself will add the package’s `share` directory to `XDG_DATA_DIRS`.
106+
107+- []{#ssec-gnome-hooks-glib} `glib` setup hook will populate `GSETTINGS_SCHEMAS_PATH` and then `wrapGAppsHook` will prepend it to `XDG_DATA_DIRS`.
108+
109+- []{#ssec-gnome-hooks-gdk-pixbuf} `gdk-pixbuf` setup hook will populate `GDK_PIXBUF_MODULE_FILE` with the path to biggest `loaders.cache` file from the dependencies containing [GdkPixbuf loaders](#ssec-gnome-gdk-pixbuf-loaders). This works fine when there are only two packages containing loaders (`gdk-pixbuf` and e.g. `librsvg`) – it will choose the second one, reasonably expecting that it will be bigger since it describes extra loader in addition to the default ones. But when there are more than two loader packages, this logic will break. One possible solution would be constructing a custom cache file for each package containing a program like `services/x11/gdk-pixbuf.nix` NixOS module does. `wrapGAppsHook` copies the `GDK_PIXBUF_MODULE_FILE` environment variable into the produced wrapper.
110+
111+- []{#ssec-gnome-hooks-gtk-drop-icon-theme-cache} One of `gtk3`’s setup hooks will remove `icon-theme.cache` files from package’s icon theme directories to avoid conflicts. Icon theme packages should prevent this with `dontDropIconThemeCache = true;`.
112+
113+- []{#ssec-gnome-hooks-dconf} `dconf.lib` is a dependency of `wrapGAppsHook`, which then also adds it to the `GIO_EXTRA_MODULES` variable.
114+
115+- []{#ssec-gnome-hooks-hicolor-icon-theme} `hicolor-icon-theme`’s setup hook will add icon themes to `XDG_ICON_DIRS`.
116+
117+- []{#ssec-gnome-hooks-gobject-introspection} `gobject-introspection` setup hook populates `GI_TYPELIB_PATH` variable with `lib/girepository-1.0` directories of dependencies, which is then added to wrapper by `wrapGAppsHook`. It also adds `share` directories of dependencies to `XDG_DATA_DIRS`, which is intended to promote GIR files but it also [pollutes the closures](https://github.com/NixOS/nixpkgs/issues/32790) of packages using `wrapGAppsHook`.
118+
119+ ::: {.warning}
120+ The setup hook [currently](https://github.com/NixOS/nixpkgs/issues/56943) does not work in expressions with `strictDeps` enabled, like Python packages. In those cases, you will need to disable it with `strictDeps = false;`.
121+ :::
122+
123+- []{#ssec-gnome-hooks-gst-grl-plugins} Setup hooks of `gst_all_1.gstreamer` and `grilo` will populate the `GST_PLUGIN_SYSTEM_PATH_1_0` and `GRL_PLUGIN_PATH` variables, respectively, which will then be added to the wrapper by `wrapGAppsHook`.
124+
125+You can also pass additional arguments to `makeWrapper` using `gappsWrapperArgs` in `preFixup` hook:
126+
127+```nix
128+preFixup = ''
129+ gappsWrapperArgs+=(
130+ # Thumbnailers
131+ --prefix XDG_DATA_DIRS : "${gdk-pixbuf}/share"
132+ --prefix XDG_DATA_DIRS : "${librsvg}/share"
133+ --prefix XDG_DATA_DIRS : "${shared-mime-info}/share"
134+ )
135+'';
136+```
137+
138+## Updating GNOME packages {#ssec-gnome-updating}
139+
140+Most GNOME package offer [`updateScript`](#var-passthru-updateScript), it is therefore possible to update to latest source tarball by running `nix-shell maintainers/scripts/update.nix --argstr package gnome.nautilus` or even en masse with `nix-shell maintainers/scripts/update.nix --argstr path gnome`. Read the package’s `NEWS` file to see what changed.
141+
142+## Frequently encountered issues {#ssec-gnome-common-issues}
143+
144+#### `GLib-GIO-ERROR **: 06:04:50.903: No GSettings schemas are installed on the system` {#ssec-gnome-common-issues-no-schemas}
145+
146+There are no schemas available in `XDG_DATA_DIRS`. Temporarily add a random package containing schemas like `gsettings-desktop-schemas` to `buildInputs`. [`glib`](#ssec-gnome-hooks-glib) and [`wrapGAppsHook`](#ssec-gnome-hooks-wrapgappshook) setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the [next error](#ssec-gnome-common-issues-missing-schema). Or you can try looking through the source code for the actual schemas used.
147+
148+#### `GLib-GIO-ERROR **: 06:04:50.903: Settings schema ‘org.gnome.foo’ is not installed` {#ssec-gnome-common-issues-missing-schema}
149+
150+Package is missing some GSettings schemas. You can find out the package containing the schema with `nix-locate org.gnome.foo.gschema.xml` and let the hooks handle the wrapping as [above](#ssec-gnome-common-issues-no-schemas).
151+
152+#### When using `wrapGAppsHook` with special derivers you can end up with double wrapped binaries. {#ssec-gnome-common-issues-double-wrapped}
153+
154+This is because derivers like `python.pkgs.buildPythonApplication` or `qt5.mkDerivation` have setup-hooks automatically added that produce wrappers with makeWrapper. The simplest way to workaround that is to disable the `wrapGAppsHook` automatic wrapping with `dontWrapGApps = true;` and pass the arguments it intended to pass to makeWrapper to another.
155+
156+In the case of a Python application it could look like:
157+
158+```nix
159+python3.pkgs.buildPythonApplication {
160+ pname = "gnome-music";
161+ version = "3.32.2";
162+
163+ nativeBuildInputs = [
164+ wrapGAppsHook
165+ gobject-introspection
166+ ...
167+ ];
168+
169+ dontWrapGApps = true;
170+
171+ # Arguments to be passed to `makeWrapper`, only used by buildPython*
172+ preFixup = ''
173+ makeWrapperArgs+=("''${gappsWrapperArgs[@]}")
174+ '';
175+}
176+```
177+
178+And for a QT app like:
179+
180+```nix
181+mkDerivation {
182+ pname = "calibre";
183+ version = "3.47.0";
184+
185+ nativeBuildInputs = [
186+ wrapGAppsHook
187+ qmake
188+ ...
189+ ];
190+
191+ dontWrapGApps = true;
192+
193+ # Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
194+ preFixup = ''
195+ qtWrapperArgs+=("''${gappsWrapperArgs[@]}")
196+ '';
197+}
198+```
199+
200+#### I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension. {#ssec-gnome-common-issues-unwrappable-package}
201+
202+You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
203+
204+- []{#ssec-gnome-common-issues-unwrappable-package-gnome-shell-ext} [Replacing a `GI_TYPELIB_PATH` in GNOME Shell extension](https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24) – we are using `substituteAll` to include the path to a typelib into a patch.
205+
206+- []{#ssec-gnome-common-issues-unwrappable-package-gsettings} The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
207+
208+ * `glib.getSchemaPath` Takes a nix package attribute as an argument.
209+
210+ * `glib.makeSchemaPath` Takes a package output like `$out` and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
211+
212+ []{#ssec-gnome-common-issues-unwrappable-package-gsettings-vala} [Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)](https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86) – here, `substituteAll` cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a [Nix bug](https://github.com/NixOS/nix/issues/1846).
213+
214+ []{#ssec-gnome-common-issues-unwrappable-package-gsettings-c} [Hard-coding GSettings schema path in C library](https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34) – nothing special other than using [Coccinelle patch](https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467) to generate the patch itself.
215+
216+#### I need to wrap a binary outside `bin` and `libexec` directories. {#ssec-gnome-common-issues-weird-location}
217+
218+You can manually trigger the wrapping with `wrapGApp` in `preFixup` phase. It takes a path to a program as a first argument; the remaining arguments are passed directly to [`wrapProgram`](#fun-wrapProgram) function.
doc/languages-frameworks/go.section.mdnew file+149
@@ -0,0 +1,149 @@
1+# Go {#sec-language-go}
2+
3+## Go modules {#ssec-language-go}
4+
5+The function `buildGoModule` builds Go programs managed with Go modules. It builds a [Go Modules](https://github.com/golang/go/wiki/Modules) through a two phase build:
6+
7+- An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
8+- A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
9+
10+### Example for `buildGoModule` {#ex-buildGoModule}
11+
12+In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
13+
14+- `vendorSha256`: is the hash of the output of the intermediate fetcher derivation. `vendorSha256` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorSha256 = null;`
15+- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorSha256` checksums.
16+
17+```nix
18+pet = buildGoModule rec {
19+ pname = "pet";
20+ version = "0.3.4";
21+
22+ src = fetchFromGitHub {
23+ owner = "knqyf263";
24+ repo = "pet";
25+ rev = "v${version}";
26+ sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
27+ };
28+
29+ vendorSha256 = "1879j77k96684wi554rkjxydrj8g3hpp0kvxz03sd8dmwr3lh83j";
30+
31+ meta = with lib; {
32+ description = "Simple command-line snippet manager, written in Go";
33+ homepage = "https://github.com/knqyf263/pet";
34+ license = licenses.mit;
35+ maintainers = with maintainers; [ kalbasit ];
36+ };
37+}
38+```
39+
40+## `buildGoPackage` (legacy) {#ssec-go-legacy}
41+
42+The function `buildGoPackage` builds legacy Go programs, not supporting Go modules.
43+
44+### Example for `buildGoPackage` {#example-for-buildgopackage}
45+
46+In the following is an example expression using buildGoPackage, the following arguments are of special significance to the function:
47+
48+- `goPackagePath` specifies the package's canonical Go import path.
49+- `goDeps` is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate `deps.nix` file for readability. The dependency data structure is described below.
50+
51+```nix
52+deis = buildGoPackage rec {
53+ pname = "deis";
54+ version = "1.13.0";
55+
56+ goPackagePath = "github.com/deis/deis";
57+
58+ src = fetchFromGitHub {
59+ owner = "deis";
60+ repo = "deis";
61+ rev = "v${version}";
62+ sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
63+ };
64+
65+ goDeps = ./deps.nix;
66+}
67+```
68+
69+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`:
70+
71+```nix
72+# deps.nix
73+[ # goDeps is a list of Go dependencies.
74+ {
75+ # goPackagePath specifies Go package import path.
76+ goPackagePath = "gopkg.in/yaml.v2";
77+ fetch = {
78+ # `fetch type` that needs to be used to get package source.
79+ # If `git` is used there should be `url`, `rev` and `sha256` defined next to it.
80+ type = "git";
81+ url = "https://gopkg.in/yaml.v2";
82+ rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
83+ sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
84+ };
85+ }
86+ {
87+ goPackagePath = "github.com/docopt/docopt-go";
88+ fetch = {
89+ type = "git";
90+ url = "https://github.com/docopt/docopt-go";
91+ rev = "784ddc588536785e7299f7272f39101f7faccc3f";
92+ sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
93+ };
94+ }
95+]
96+```
97+
98+To extract dependency information from a Go package in automated way use [go2nix](https://github.com/kamilchm/go2nix). It can produce complete derivation and `goDeps` file for Go programs.
99+
100+You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
101+
102+```bash
103+for p in $NIX_PROFILES; do
104+ GOPATH="$p/share/go:$GOPATH"
105+done
106+```
107+
108+## Attributes used by the builders {#ssec-go-common-attributes}
109+
110+Both `buildGoModule` and `buildGoPackage` can be tweaked to behave slightly differently, if the following attributes are used:
111+
112+### `ldflags` {#var-go-ldflags}
113+
114+Arguments to pass to the Go linker tool via the `-ldflags` argument of `go build`. The most common use case for this argument is to make the resulting executable aware of its own version. For example:
115+
116+```nix
117+ ldflags = [
118+ "-s" "-w"
119+ "-X main.Version=${version}"
120+ "-X main.Commit=${version}"
121+ ];
122+```
123+
124+### `tags` {#var-go-tags}
125+
126+Arguments to pass to the Go via the `-tags` argument of `go build`. For example:
127+
128+```nix
129+ tags = [
130+ "production"
131+ "sqlite"
132+ ];
133+```
134+
135+```nix
136+ tags = [ "production" ] ++ lib.optionals withSqlite [ "sqlite" ];
137+```
138+
139+### `deleteVendor` {#var-go-deleteVendor}
140+
141+Removes the pre-existing vendor directory. This should only be used if the dependencies included in the vendor folder are broken or incomplete.
142+
143+### `subPackages` {#var-go-subPackages}
144+
145+Specified as a string or list of strings. Limits the builder from building child packages that have not been listed. If `subPackages` is not specified, all child packages will be built.
146+
147+### `excludedPackages` {#var-go-excludedPackages}
148+
149+Specified as a string or list of strings. Causes the builder to skip building child packages that match any of the provided values. If `excludedPackages` is not specified, all child packages will be built.
doc/languages-frameworks/go.xmldeleted−160
@@ -1,160 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-go">
4− <title>Go</title>
5−
6− <para>
7− The function <varname>buildGoPackage</varname> builds standard Go programs.
8− </para>
9−
10− <example xml:id='ex-buildGoPackage'>
11− <title>buildGoPackage</title>
12−<programlisting>
13−deis = buildGoPackage rec {
14− name = "deis-${version}";
15− version = "1.13.0";
16−
17− goPackagePath = "github.com/deis/deis"; <co xml:id='ex-buildGoPackage-1' />
18− subPackages = [ "client" ]; <co xml:id='ex-buildGoPackage-2' />
19−
20− src = fetchFromGitHub {
21− owner = "deis";
22− repo = "deis";
23− rev = "v${version}";
24− sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
25− };
26−
27− goDeps = ./deps.nix; <co xml:id='ex-buildGoPackage-3' />
28−
29− buildFlags = "--tags release"; <co xml:id='ex-buildGoPackage-4' />
30−}
31−</programlisting>
32− </example>
33−
34− <para>
35− <xref linkend='ex-buildGoPackage'/> is an example expression using
36− buildGoPackage, the following arguments are of special significance to the
37− function:
38− <calloutlist>
39− <callout arearefs='ex-buildGoPackage-1'>
40− <para>
41− <varname>goPackagePath</varname> specifies the package's canonical Go
42− import path.
43− </para>
44− </callout>
45− <callout arearefs='ex-buildGoPackage-2'>
46− <para>
47− <varname>subPackages</varname> limits the builder from building child
48− packages that have not been listed. If <varname>subPackages</varname> is
49− not specified, all child packages will be built.
50− </para>
51− <para>
52− In this example only <literal>github.com/deis/deis/client</literal> will
53− be built.
54− </para>
55− </callout>
56− <callout arearefs='ex-buildGoPackage-3'>
57− <para>
58− <varname>goDeps</varname> is where the Go dependencies of a Go program are
59− listed as a list of package source identified by Go import path. It could
60− be imported as a separate <varname>deps.nix</varname> file for
61− readability. The dependency data structure is described below.
62− </para>
63− </callout>
64− <callout arearefs='ex-buildGoPackage-4'>
65− <para>
66− <varname>buildFlags</varname> is a list of flags passed to the go build
67− command.
68− </para>
69− </callout>
70− </calloutlist>
71− </para>
72−
73− <para>
74− The <varname>goDeps</varname> attribute can be imported from a separate
75− <varname>nix</varname> file that defines which Go libraries are needed and
76− should be included in <varname>GOPATH</varname> for
77− <varname>buildPhase</varname>.
78− </para>
79−
80− <example xml:id='ex-goDeps'>
81− <title>deps.nix</title>
82−<programlisting>
83−[ <co xml:id='ex-goDeps-1' />
84− {
85− goPackagePath = "gopkg.in/yaml.v2"; <co xml:id='ex-goDeps-2' />
86− fetch = {
87− type = "git"; <co xml:id='ex-goDeps-3' />
88− url = "https://gopkg.in/yaml.v2";
89− rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
90− sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
91− };
92− }
93− {
94− goPackagePath = "github.com/docopt/docopt-go";
95− fetch = {
96− type = "git";
97− url = "https://github.com/docopt/docopt-go";
98− rev = "784ddc588536785e7299f7272f39101f7faccc3f";
99− sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
100− };
101− }
102−]
103−</programlisting>
104− </example>
105−
106− <para>
107− <calloutlist>
108− <callout arearefs='ex-goDeps-1'>
109− <para>
110− <varname>goDeps</varname> is a list of Go dependencies.
111− </para>
112− </callout>
113− <callout arearefs='ex-goDeps-2'>
114− <para>
115− <varname>goPackagePath</varname> specifies Go package import path.
116− </para>
117− </callout>
118− <callout arearefs='ex-goDeps-3'>
119− <para>
120− <varname>fetch type</varname> that needs to be used to get package source.
121− If <varname>git</varname> is used there should be <varname>url</varname>,
122− <varname>rev</varname> and <varname>sha256</varname> defined next to it.
123− </para>
124− </callout>
125− </calloutlist>
126− </para>
127−
128− <para>
129− To extract dependency information from a Go package in automated way use
130− <link xlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can
131− produce complete derivation and <varname>goDeps</varname> file for Go
132− programs.
133− </para>
134−
135− <para>
136− <varname>buildGoPackage</varname> produces
137− <xref linkend='chap-multiple-output' xrefstyle="select: title" /> where
138− <varname>bin</varname> includes program binaries. You can test build a Go
139− binary as follows:
140−<screen>
141− $ nix-build -A deis.bin
142− </screen>
143− or build all outputs with:
144−<screen>
145− $ nix-build -A deis.all
146− </screen>
147− <varname>bin</varname> output will be installed by default with
148− <varname>nix-env -i</varname> or <varname>systemPackages</varname>.
149− </para>
150−
151− <para>
152− You may use Go packages installed into the active Nix profiles by adding the
153− following to your ~/.bashrc:
154−<screen>
155−for p in $NIX_PROFILES; do
156− GOPATH="$p/share/go:$GOPATH"
157−done
158−</screen>
159− </para>
160−</section>
doc/languages-frameworks/haskell.section.md+6−1090
@@ -1,1091 +1,7 @@
1−---
2−title: User's Guide for Haskell in Nixpkgs
3−author: Peter Simons
4−date: 2015-06-01
5−---
6−# User's Guide to the Haskell Infrastructure
1+# Haskell {#haskell}
72
8−
9−## How to install Haskell packages
10−
11−Nixpkgs distributes build instructions for all Haskell packages registered on
12−[Hackage](http://hackage.haskell.org/), but strangely enough normal Nix package
13−lookups don't seem to discover any of them, except for the default version of ghc, cabal-install, and stack:
14−```
15−$ nix-env -i alex
16−error: selector ‘alex’ matches no derivations
17−$ nix-env -qa ghc
18−ghc-7.10.2
19−```
20−
21−The Haskell package set is not registered in the top-level namespace because it
22−is *huge*. If all Haskell packages were visible to these commands, then
23−name-based search/install operations would be much slower than they are now. We
24−avoided that by keeping all Haskell-related packages in a separate attribute
25−set called `haskellPackages`, which the following command will list:
26−```
27−$ nix-env -f "<nixpkgs>" -qaP -A haskellPackages
28−haskellPackages.a50 a50-0.5
29−haskellPackages.abacate haskell-abacate-0.0.0.0
30−haskellPackages.abcBridge haskell-abcBridge-0.12
31−haskellPackages.afv afv-0.1.1
32−haskellPackages.alex alex-3.1.4
33−haskellPackages.Allure Allure-0.4.101.1
34−haskellPackages.alms alms-0.6.7
35−[... some 8000 entries omitted ...]
36−```
37−
38−To install any of those packages into your profile, refer to them by their
39−attribute path (first column):
40−```shell
41−nix-env -f "<nixpkgs>" -iA haskellPackages.Allure ...
42−```
43−
44−The attribute path of any Haskell packages corresponds to the name of that
45−particular package on Hackage: the package `cabal-install` has the attribute
46−`haskellPackages.cabal-install`, and so on. (Actually, this convention causes
47−trouble with packages like `3dmodels` and `4Blocks`, because these names are
48−invalid identifiers in the Nix language. The issue of how to deal with these
49−rare corner cases is currently unresolved.)
50−
51−Haskell packages whose Nix name (second column) begins with a `haskell-` prefix
52−are packages that provide a library whereas packages without that prefix
53−provide just executables. Libraries may provide executables too, though: the
54−package `haskell-pandoc`, for example, installs both a library and an
55−application. You can install and use Haskell executables just like any other
56−program in Nixpkgs, but using Haskell libraries for development is a bit
57−trickier and we'll address that subject in great detail in section [How to
58−create a development environment].
59−
60−Attribute paths are deterministic inside of Nixpkgs, but the path necessary to
61−reach Nixpkgs varies from system to system. We dodged that problem by giving
62−`nix-env` an explicit `-f "<nixpkgs>"` parameter, but if you call `nix-env`
63−without that flag, then chances are the invocation fails:
64−```
65−$ nix-env -iA haskellPackages.cabal-install
66−error: attribute ‘haskellPackages’ in selection path
67− ‘haskellPackages.cabal-install’ not found
68−```
69−
70−On NixOS, for example, Nixpkgs does *not* exist in the top-level namespace by
71−default. To figure out the proper attribute path, it's easiest to query for the
72−path of a well-known Nixpkgs package, i.e.:
73−```
74−$ nix-env -qaP coreutils
75−nixos.coreutils coreutils-8.23
76−```
77−
78−If your system responds like that (most NixOS installations will), then the
79−attribute path to `haskellPackages` is `nixos.haskellPackages`. Thus, if you
80−want to use `nix-env` without giving an explicit `-f` flag, then that's the way
81−to do it:
82−```shell
83−nix-env -qaP -A nixos.haskellPackages
84−nix-env -iA nixos.haskellPackages.cabal-install
85−```
86−
87−Our current default compiler is GHC 7.10.x and the `haskellPackages` set
88−contains packages built with that particular version. Nixpkgs contains the
89−latest major release of every GHC since 6.10.4, however, and there is a whole
90−family of package sets available that defines Hackage packages built with each
91−of those compilers, too:
92−```shell
93−nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc6123
94−nix-env -f "<nixpkgs>" -qaP -A haskell.packages.ghc763
95−```
96−
97−The name `haskellPackages` is really just a synonym for
98−`haskell.packages.ghc7102`, because we prefer that package set internally and
99−recommend it to our users as their default choice, but ultimately you are free
100−to compile your Haskell packages with any GHC version you please. The following
101−command displays the complete list of available compilers:
102−```
103−$ nix-env -f "<nixpkgs>" -qaP -A haskell.compiler
104−haskell.compiler.ghc6104 ghc-6.10.4
105−haskell.compiler.ghc6123 ghc-6.12.3
106−haskell.compiler.ghc704 ghc-7.0.4
107−haskell.compiler.ghc722 ghc-7.2.2
108−haskell.compiler.ghc742 ghc-7.4.2
109−haskell.compiler.ghc763 ghc-7.6.3
110−haskell.compiler.ghc784 ghc-7.8.4
111−haskell.compiler.ghc7102 ghc-7.10.2
112−haskell.compiler.ghcHEAD ghc-7.11.20150402
113−haskell.compiler.ghcNokinds ghc-nokinds-7.11.20150704
114−haskell.compiler.ghcjs ghcjs-0.1.0
115−haskell.compiler.jhc jhc-0.8.2
116−haskell.compiler.uhc uhc-1.1.9.0
117−```
118−
119−We have no package sets for `jhc` or `uhc` yet, unfortunately, but for every
120−version of GHC listed above, there exists a package set based on that compiler.
121−Also, the attributes `haskell.compiler.ghcXYC` and
122−`haskell.packages.ghcXYC.ghc` are synonymous for the sake of convenience.
123−
124−## How to create a development environment
125−
126−### How to install a compiler
127−
128−A simple development environment consists of a Haskell compiler and one or both
129−of the tools `cabal-install` and `stack`. We saw in section
130−[How to install Haskell packages] how you can install those programs into your
131−user profile:
132−```shell
133−nix-env -f "<nixpkgs>" -iA haskellPackages.ghc haskellPackages.cabal-install
134−```
135−
136−Instead of the default package set `haskellPackages`, you can also use the more
137−precise name `haskell.compiler.ghc7102`, which has the advantage that it refers
138−to the same GHC version regardless of what Nixpkgs considers "default" at any
139−given time.
140−
141−Once you've made those tools available in `$PATH`, it's possible to build
142−Hackage packages the same way people without access to Nix do it all the time:
143−```shell
144−cabal get lens-4.11 && cd lens-4.11
145−cabal install -j --dependencies-only
146−cabal configure
147−cabal build
148−```
149−
150−If you enjoy working with Cabal sandboxes, then that's entirely possible too:
151−just execute the command
152−```shell
153−cabal sandbox init
154−```
155−before installing the required dependencies.
156−
157−The `nix-shell` utility makes it easy to switch to a different compiler
158−version; just enter the Nix shell environment with the command
159−```shell
160−nix-shell -p haskell.compiler.ghc784
161−```
162−to bring GHC 7.8.4 into `$PATH`. Alternatively, you can use Stack instead of
163−`nix-shell` directly to select compiler versions and other build tools
164−per-project. It uses `nix-shell` under the hood when Nix support is turned on.
165−See [How to build a Haskell project using Stack].
166−
167−If you're using `cabal-install`, re-running `cabal configure` inside the spawned
168−shell switches your build to use that compiler instead. If you're working on
169−a project that doesn't depend on any additional system libraries outside of GHC,
170−then it's even sufficient to just run the `cabal configure` command inside of
171−the shell:
172−```shell
173−nix-shell -p haskell.compiler.ghc784 --command "cabal configure"
174−```
175−
176−Afterwards, all other commands like `cabal build` work just fine in any shell
177−environment, because the configure phase recorded the absolute paths to all
178−required tools like GHC in its build configuration inside of the `dist/`
179−directory. Please note, however, that `nix-collect-garbage` can break such an
180−environment because the Nix store paths created by `nix-shell` aren't "alive"
181−anymore once `nix-shell` has terminated. If you find that your Haskell builds
182−no longer work after garbage collection, then you'll have to re-run `cabal
183−configure` inside of a new `nix-shell` environment.
184−
185−### How to install a compiler with libraries
186−
187−GHC expects to find all installed libraries inside of its own `lib` directory.
188−This approach works fine on traditional Unix systems, but it doesn't work for
189−Nix, because GHC's store path is immutable once it's built. We cannot install
190−additional libraries into that location. As a consequence, our copies of GHC
191−don't know any packages except their own core libraries, like `base`,
192−`containers`, `Cabal`, etc.
193−
194−We can register additional libraries to GHC, however, using a special build
195−function called `ghcWithPackages`. That function expects one argument: a
196−function that maps from an attribute set of Haskell packages to a list of
197−packages, which determines the libraries known to that particular version of
198−GHC. For example, the Nix expression `ghcWithPackages (pkgs: [pkgs.mtl])`
199−generates a copy of GHC that has the `mtl` library registered in addition to
200−its normal core packages:
201−```
202−$ nix-shell -p "haskellPackages.ghcWithPackages (pkgs: [pkgs.mtl])"
203−
204−[nix-shell:~]$ ghc-pkg list mtl
205−/nix/store/zy79...-ghc-7.10.2/lib/ghc-7.10.2/package.conf.d:
206− mtl-2.2.1
207−```
208−
209−This function allows users to define their own development environment by means
210−of an override. After adding the following snippet to `~/.config/nixpkgs/config.nix`,
211−```nix
212−{
213− packageOverrides = super: let self = super.pkgs; in
214− {
215− myHaskellEnv = self.haskell.packages.ghc7102.ghcWithPackages
216− (haskellPackages: with haskellPackages; [
217− # libraries
218− arrows async cgi criterion
219− # tools
220− cabal-install haskintex
221− ]);
222− };
223−}
224−```
225−it's possible to install that compiler with `nix-env -f "<nixpkgs>" -iA
226−myHaskellEnv`. If you'd like to switch that development environment to a
227−different version of GHC, just replace the `ghc7102` bit in the previous
228−definition with the appropriate name. Of course, it's also possible to define
229−any number of these development environments! (You can't install two of them
230−into the same profile at the same time, though, because that would result in
231−file conflicts.)
232−
233−The generated `ghc` program is a wrapper script that re-directs the real
234−GHC executable to use a new `lib` directory --- one that we specifically
235−constructed to contain all those packages the user requested:
236−```
237−$ cat $(type -p ghc)
238−#! /nix/store/xlxj...-bash-4.3-p33/bin/bash -e
239−export NIX_GHC=/nix/store/19sm...-ghc-7.10.2/bin/ghc
240−export NIX_GHCPKG=/nix/store/19sm...-ghc-7.10.2/bin/ghc-pkg
241−export NIX_GHC_DOCDIR=/nix/store/19sm...-ghc-7.10.2/share/doc/ghc/html
242−export NIX_GHC_LIBDIR=/nix/store/19sm...-ghc-7.10.2/lib/ghc-7.10.2
243−exec /nix/store/j50p...-ghc-7.10.2/bin/ghc "-B$NIX_GHC_LIBDIR" "$@"
244−```
245−
246−The variables `$NIX_GHC`, `$NIX_GHCPKG`, etc. point to the *new* store path
247−`ghcWithPackages` constructed specifically for this environment. The last line
248−of the wrapper script then executes the real `ghc`, but passes the path to the
249−new `lib` directory using GHC's `-B` flag.
250−
251−The purpose of those environment variables is to work around an impurity in the
252−popular [ghc-paths](http://hackage.haskell.org/package/ghc-paths) library. That
253−library promises to give its users access to GHC's installation paths. Only,
254−the library can't possible know that path when it's compiled, because the path
255−GHC considers its own is determined only much later, when the user configures
256−it through `ghcWithPackages`. So we [patched
257−ghc-paths](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/patches/ghc-paths-nix.patch)
258−to return the paths found in those environment variables at run-time rather
259−than trying to guess them at compile-time.
260−
261−To make sure that mechanism works properly all the time, we recommend that you
262−set those variables to meaningful values in your shell environment, too, i.e.
263−by adding the following code to your `~/.bashrc`:
264−```bash
265−if type >/dev/null 2>&1 -p ghc; then
266− eval "$(egrep ^export "$(type -p ghc)")"
267−fi
268−```
269−
270−If you are certain that you'll use only one GHC environment which is located in
271−your user profile, then you can use the following code, too, which has the
272−advantage that it doesn't contain any paths from the Nix store, i.e. those
273−settings always remain valid even if a `nix-env -u` operation updates the GHC
274−environment in your profile:
275−```bash
276−if [ -e ~/.nix-profile/bin/ghc ]; then
277− export NIX_GHC="$HOME/.nix-profile/bin/ghc"
278− export NIX_GHCPKG="$HOME/.nix-profile/bin/ghc-pkg"
279− export NIX_GHC_DOCDIR="$HOME/.nix-profile/share/doc/ghc/html"
280− export NIX_GHC_LIBDIR="$HOME/.nix-profile/lib/ghc-$($NIX_GHC --numeric-version)"
281−fi
282−```
283−
284−### How to install a compiler with libraries, hoogle and documentation indexes
285−
286−If you plan to use your environment for interactive programming, not just
287−compiling random Haskell code, you might want to replace `ghcWithPackages` in
288−all the listings above with `ghcWithHoogle`.
289−
290−This environment generator not only produces an environment with GHC and all
291−the specified libraries, but also generates a `hoogle` and `haddock` indexes
292−for all the packages, and provides a wrapper script around `hoogle` binary that
293−uses all those things. A precise name for this thing would be
294−"`ghcWithPackagesAndHoogleAndDocumentationIndexes`", which is, regrettably, too
295−long and scary.
296−
297−For example, installing the following environment
298−```nix
299−{
300− packageOverrides = super: let self = super.pkgs; in
301− {
302− myHaskellEnv = self.haskellPackages.ghcWithHoogle
303− (haskellPackages: with haskellPackages; [
304− # libraries
305− arrows async cgi criterion
306− # tools
307− cabal-install haskintex
308− ]);
309− };
310−}
311−```
312−allows one to browse module documentation index [not too dissimilar to
313−this](https://downloads.haskell.org/~ghc/latest/docs/html/libraries/index.html)
314−for all the specified packages and their dependencies by directing a browser of
315−choice to `~/.nix-profile/share/doc/hoogle/index.html` (or
316−`/run/current-system/sw/share/doc/hoogle/index.html` in case you put it in
317−`environment.systemPackages` in NixOS).
318−
319−After you've marveled enough at that try adding the following to your
320−`~/.ghc/ghci.conf`
321−```
322−:def hoogle \s -> return $ ":! hoogle search -cl --count=15 \"" ++ s ++ "\""
323−:def doc \s -> return $ ":! hoogle search -cl --info \"" ++ s ++ "\""
324−```
325−and test it by typing into `ghci`:
326−```
327−:hoogle a -> a
328−:doc a -> a
329−```
330−
331−Be sure to note the links to `haddock` files in the output. With any modern and
332−properly configured terminal emulator you can just click those links to
333−navigate there.
334−
335−Finally, you can run
336−```shell
337−hoogle server --local -p 8080
338−```
339−and navigate to http://localhost:8080/ for your own local
340−[Hoogle](https://www.haskell.org/hoogle/). The `--local` flag makes the hoogle
341−server serve files from your nix store over http, without the flag it will use
342−`file://` URIs. Note, however, that Firefox and possibly other browsers
343−disallow navigation from `http://` to `file://` URIs for security reasons,
344−which might be quite an inconvenience. Versions before v5 did not have this
345−flag. See
346−[this page](http://kb.mozillazine.org/Links_to_local_pages_do_not_work) for
347−workarounds.
348−
349−For NixOS users there's a service which runs this exact command for you.
350−Specify the `packages` you want documentation for and the `haskellPackages` set
351−you want them to come from. Add the following to `configuration.nix`.
352−
353−```nix
354−services.hoogle = {
355−enable = true;
356−packages = (hpkgs: with hpkgs; [text cryptonite]);
357−haskellPackages = pkgs.haskellPackages;
358−};
359−```
360−
361−### How to build a Haskell project using Stack
362−
363−[Stack](http://haskellstack.org) is a popular build tool for Haskell projects.
364−It has first-class support for Nix. Stack can optionally use Nix to
365−automatically select the right version of GHC and other build tools to build,
366−test and execute apps in an existing project downloaded from somewhere on the
367−Internet. Pass the `--nix` flag to any `stack` command to do so, e.g.
368−```shell
369−git clone --recursive http://github.com/yesodweb/wai
370−cd wai
371−stack --nix build
372−```
373−
374−If you want `stack` to use Nix by default, you can add a `nix` section to the
375−`stack.yaml` file, as explained in the [Stack documentation][stack-nix-doc]. For
376−example:
377−```yaml
378−nix:
379− enable: true
380− packages: [pkgconfig zeromq zlib]
381−```
382−
383−The example configuration snippet above tells Stack to create an ad hoc
384−environment for `nix-shell` as in the below section, in which the `pkgconfig`,
385−`zeromq` and `zlib` packages from Nixpkgs are available. All `stack` commands
386−will implicitly be executed inside this ad hoc environment.
387−
388−Some projects have more sophisticated needs. For examples, some ad hoc
389−environments might need to expose Nixpkgs packages compiled in a certain way, or
390−with extra environment variables. In these cases, you'll need a `shell` field
391−instead of `packages`:
392−```yaml
393−nix:
394− enable: true
395− shell-file: shell.nix
396−```
397−
398−For more on how to write a `shell.nix` file see the below section. You'll need
399−to express a derivation. Note that Nixpkgs ships with a convenience wrapper
400−function around `mkDerivation` called `haskell.lib.buildStackProject` to help you
401−create this derivation in exactly the way Stack expects. All of the same inputs
402−as `mkDerivation` can be provided. For example, to build a Stack project that
403−including packages that link against a version of the R library compiled with
404−special options turned on:
405−```nix
406−with (import <nixpkgs> { });
407−
408−let R = pkgs.R.override { enableStrictBarrier = true; };
409−in
410−haskell.lib.buildStackProject {
411− name = "HaskellR";
412− buildInputs = [ R zeromq zlib ];
413−}
414−```
415−
416−You can select a particular GHC version to compile with by setting the
417−`ghc` attribute as an argument to `buildStackProject`. Better yet, let
418−Stack choose what GHC version it wants based on the snapshot specified
419−in `stack.yaml` (only works with Stack >= 1.1.3):
420−```nix
421−{nixpkgs ? import <nixpkgs> { }, ghc ? nixpkgs.ghc}:
422−
423−with nixpkgs;
424−
425−let R = pkgs.R.override { enableStrictBarrier = true; };
426−in
427−haskell.lib.buildStackProject {
428− name = "HaskellR";
429− buildInputs = [ R zeromq zlib ];
430− inherit ghc;
431−}
432−```
433−
434−[stack-nix-doc]: http://docs.haskellstack.org/en/stable/nix_integration.html
435−
436−### How to create ad hoc environments for `nix-shell`
437−
438−The easiest way to create an ad hoc development environment is to run
439−`nix-shell` with the appropriate GHC environment given on the command-line:
440−```shell
441−nix-shell -p "haskellPackages.ghcWithPackages (pkgs: with pkgs; [mtl pandoc])"
442−```
443−
444−For more sophisticated use-cases, however, it's more convenient to save the
445−desired configuration in a file called `shell.nix` that looks like this:
446−```nix
447−{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
448−let
449− inherit (nixpkgs) pkgs;
450− ghc = pkgs.haskell.packages.${compiler}.ghcWithPackages (ps: with ps; [
451− monad-par mtl
452− ]);
453−in
454−pkgs.stdenv.mkDerivation {
455− name = "my-haskell-env-0";
456− buildInputs = [ ghc ];
457− shellHook = "eval $(egrep ^export ${ghc}/bin/ghc)";
458−}
459−```
460−
461−Now run `nix-shell` --- or even `nix-shell --pure` --- to enter a shell
462−environment that has the appropriate compiler in `$PATH`. If you use `--pure`,
463−then add all other packages that your development environment needs into the
464−`buildInputs` attribute. If you'd like to switch to a different compiler
465−version, then pass an appropriate `compiler` argument to the expression, i.e.
466−`nix-shell --argstr compiler ghc784`.
467−
468−If you need such an environment because you'd like to compile a Hackage package
469−outside of Nix --- i.e. because you're hacking on the latest version from Git
470−---, then the package set provides suitable nix-shell environments for you
471−already! Every Haskell package has an `env` attribute that provides a shell
472−environment suitable for compiling that particular package. If you'd like to
473−hack the `lens` library, for example, then you just have to check out the
474−source code and enter the appropriate environment:
475−```
476−$ cabal get lens-4.11 && cd lens-4.11
477−Downloading lens-4.11...
478−Unpacking to lens-4.11/
479−
480−$ nix-shell "<nixpkgs>" -A haskellPackages.lens.env
481−[nix-shell:/tmp/lens-4.11]$
482−```
483−
484−At point, you can run `cabal configure`, `cabal build`, and all the other
485−development commands. Note that you need `cabal-install` installed in your
486−`$PATH` already to use it here --- the `nix-shell` environment does not provide
487−it.
488−
489−## How to create Nix builds for your own private Haskell packages
490−
491−If your own Haskell packages have build instructions for Cabal, then you can
492−convert those automatically into build instructions for Nix using the
493−`cabal2nix` utility, which you can install into your profile by running
494−`nix-env -i cabal2nix`.
495−
496−### How to build a stand-alone project
497−
498−For example, let's assume that you're working on a private project called
499−`foo`. To generate a Nix build expression for it, change into the project's
500−top-level directory and run the command:
501−```shell
502−cabal2nix . > foo.nix
503−```
504−Then write the following snippet into a file called `default.nix`:
505−```nix
506−{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
507−nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./foo.nix { }
508−```
509−
510−Finally, store the following code in a file called `shell.nix`:
511−```nix
512−{ nixpkgs ? import <nixpkgs> {}, compiler ? "ghc7102" }:
513−(import ./default.nix { inherit nixpkgs compiler; }).env
514−```
515−
516−At this point, you can run `nix-build` to have Nix compile your project and
517−install it into a Nix store path. The local directory will contain a symlink
518−called `result` after `nix-build` returns that points into that location. Of
519−course, passing the flag `--argstr compiler ghc763` allows switching the build
520−to any version of GHC currently supported.
521−
522−Furthermore, you can call `nix-shell` to enter an interactive development
523−environment in which you can use `cabal configure` and `cabal build` to develop
524−your code. That environment will automatically contain a proper GHC derivation
525−with all the required libraries registered as well as all the system-level
526−libraries your package might need.
527−
528−If your package does not depend on any system-level libraries, then it's
529−sufficient to run
530−```shell
531−nix-shell --command "cabal configure"
532−```
533−once to set up your build. `cabal-install` determines the absolute paths to all
534−resources required for the build and writes them into a config file in the
535−`dist/` directory. Once that's done, you can run `cabal build` and any other
536−command for that project even outside of the `nix-shell` environment. This
537−feature is particularly nice for those of us who like to edit their code with
538−an IDE, like Emacs' `haskell-mode`, because it's not necessary to start Emacs
539−inside of nix-shell just to make it find out the necessary settings for
540−building the project; `cabal-install` has already done that for us.
541−
542−If you want to do some quick-and-dirty hacking and don't want to bother setting
543−up a `default.nix` and `shell.nix` file manually, then you can use the
544−`--shell` flag offered by `cabal2nix` to have it generate a stand-alone
545−`nix-shell` environment for you. With that feature, running
546−```shell
547−cabal2nix --shell . > shell.nix
548−nix-shell --command "cabal configure"
549−```
550−is usually enough to set up a build environment for any given Haskell package.
551−You can even use that generated file to run `nix-build`, too:
552−```shell
553−nix-build shell.nix
554−```
555−
556−### How to build projects that depend on each other
557−
558−If you have multiple private Haskell packages that depend on each other, then
559−you'll have to register those packages in the Nixpkgs set to make them visible
560−for the dependency resolution performed by `callPackage`. First of all, change
561−into each of your projects top-level directories and generate a `default.nix`
562−file with `cabal2nix`:
563−```shell
564−cd ~/src/foo && cabal2nix . > default.nix
565−cd ~/src/bar && cabal2nix . > default.nix
566−```
567−Then edit your `~/.config/nixpkgs/config.nix` file to register those builds in the
568−default Haskell package set:
569−```nix
570−{
571− packageOverrides = super: let self = super.pkgs; in
572− {
573− haskellPackages = super.haskellPackages.override {
574− overrides = self: super: {
575− foo = self.callPackage ../src/foo {};
576− bar = self.callPackage ../src/bar {};
577− };
578− };
579− };
580−}
581−```
582−Once that's accomplished, `nix-env -f "<nixpkgs>" -qA haskellPackages` will
583−show your packages like any other package from Hackage, and you can build them
584−```shell
585−nix-build "<nixpkgs>" -A haskellPackages.foo
586−```
587−or enter an interactive shell environment suitable for building them:
588−```shell
589−nix-shell "<nixpkgs>" -A haskellPackages.bar.env
590−```
591−
592−## Miscellaneous Topics
593−
594−### How to build with profiling enabled
595−
596−Every Haskell package set takes a function called `overrides` that you can use
597−to manipulate the package as much as you please. One useful application of this
598−feature is to replace the default `mkDerivation` function with one that enables
599−library profiling for all packages. To accomplish that add the following
600−snippet to your `~/.config/nixpkgs/config.nix` file:
601−```nix
602−{
603− packageOverrides = super: let self = super.pkgs; in
604− {
605− profiledHaskellPackages = self.haskellPackages.override {
606− overrides = self: super: {
607− mkDerivation = args: super.mkDerivation (args // {
608− enableLibraryProfiling = true;
609− });
610− };
611− };
612− };
613−}
614−```
615−Then, replace instances of `haskellPackages` in the `cabal2nix`-generated
616−`default.nix` or `shell.nix` files with `profiledHaskellPackages`.
617−
618−### How to override package versions in a compiler-specific package set
619−
620−Nixpkgs provides the latest version of
621−[`ghc-events`](http://hackage.haskell.org/package/ghc-events), which is 0.4.4.0
622−at the time of this writing. This is fine for users of GHC 7.10.x, but GHC
623−7.8.4 cannot compile that binary. Now, one way to solve that problem is to
624−register an older version of `ghc-events` in the 7.8.x-specific package set.
625−The first step is to generate Nix build instructions with `cabal2nix`:
626−```shell
627−cabal2nix cabal://ghc-events-0.4.3.0 > ~/.nixpkgs/ghc-events-0.4.3.0.nix
628−```
629−Then add the override in `~/.config/nixpkgs/config.nix`:
630−```nix
631−{
632− packageOverrides = super: let self = super.pkgs; in
633− {
634− haskell = super.haskell // {
635− packages = super.haskell.packages // {
636− ghc784 = super.haskell.packages.ghc784.override {
637− overrides = self: super: {
638− ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
639− };
640− };
641− };
642− };
643− };
644−}
645−```
646−
647−This code is a little crazy, no doubt, but it's necessary because the intuitive
648−version
649−```nix
650−{ # ...
651−
652− haskell.packages.ghc784 = super.haskell.packages.ghc784.override {
653− overrides = self: super: {
654− ghc-events = self.callPackage ./ghc-events-0.4.3.0.nix {};
655− };
656− };
657−}
658−```
659−doesn't do what we want it to: that code replaces the `haskell` package set in
660−Nixpkgs with one that contains only one entry,`packages`, which contains only
661−one entry `ghc784`. This override loses the `haskell.compiler` set, and it
662−loses the `haskell.packages.ghcXYZ` sets for all compilers but GHC 7.8.4. To
663−avoid that problem, we have to perform the convoluted little dance from above,
664−iterating over each step in hierarchy.
665−
666−Once it's accomplished, however, we can install a variant of `ghc-events`
667−that's compiled with GHC 7.8.4:
668−```shell
669−nix-env -f "<nixpkgs>" -iA haskell.packages.ghc784.ghc-events
670−```
671−Unfortunately, it turns out that this build fails again while executing the
672−test suite! Apparently, the release archive on Hackage is missing some data
673−files that the test suite requires, so we cannot run it. We accomplish that by
674−re-generating the Nix expression with the `--no-check` flag:
675−```shell
676−cabal2nix --no-check cabal://ghc-events-0.4.3.0 > ~/.nixpkgs/ghc-events-0.4.3.0.nix
677−```
678−Now the builds succeeds.
679−
680−Of course, in the concrete example of `ghc-events` this whole exercise is not
681−an ideal solution, because `ghc-events` can analyze the output emitted by any
682−version of GHC later than 6.12 regardless of the compiler version that was used
683−to build the `ghc-events` executable, so strictly speaking there's no reason to
684−prefer one built with GHC 7.8.x in the first place. However, for users who
685−cannot use GHC 7.10.x at all for some reason, the approach of downgrading to an
686−older version might be useful.
687−
688−### How to override packages in all compiler-specific package sets
689−
690−In the previous section we learned how to override a package in a single
691−compiler-specific package set. You may have some overrides defined that you want
692−to use across multiple package sets. To accomplish this you could use the
693−technique that we learned in the previous section by repeating the overrides for
694−all the compiler-specific package sets. For example:
695−
696−```nix
697−{
698− packageOverrides = super: let self = super.pkgs; in
699− {
700− haskell = super.haskell // {
701− packages = super.haskell.packages // {
702− ghc784 = super.haskell.packages.ghc784.override {
703− overrides = self: super: {
704− my-package = ...;
705− my-other-package = ...;
706− };
707− };
708− ghc822 = super.haskell.packages.ghc784.override {
709− overrides = self: super: {
710− my-package = ...;
711− my-other-package = ...;
712− };
713− };
714− ...
715− };
716− };
717− };
718−}
719−```
720−
721−However there's a more convenient way to override all compiler-specific package
722−sets at once:
723−
724−```nix
725−{
726− packageOverrides = super: let self = super.pkgs; in
727− {
728− haskell = super.haskell // {
729− packageOverrides = self: super: {
730− my-package = ...;
731− my-other-package = ...;
732− };
733− };
734− };
735−}
736−```
737−
738−### How to specify source overrides for your Haskell package
739−
740−When starting a Haskell project you can use `developPackage`
741−to define a derivation for your package at the `root` path
742−as well as source override versions for Hackage packages, like so:
743−
744−```nix
745−# default.nix
746−{ compilerVersion ? "ghc842" }:
747−let
748− # pinning nixpkgs using new Nix 2.0 builtin `fetchGit`
749− pkgs = import (fetchGit (import ./version.nix)) { };
750− compiler = pkgs.haskell.packages."${compilerVersion}";
751− pkg = compiler.developPackage {
752− root = ./.;
753− source-overrides = {
754− # Let's say the GHC 8.4.2 haskellPackages uses 1.6.0.0 and your test suite is incompatible with >= 1.6.0.0
755− HUnit = "1.5.0.0";
756− };
757− };
758−in pkg
759−```
760−
761−This could be used in place of a simplified `stack.yaml` defining a Nix
762−derivation for your Haskell package.
763−
764−As you can see this allows you to specify only the source version found on
765−Hackage and nixpkgs will take care of the rest.
766−
767−You can also specify `buildInputs` for your Haskell derivation for packages
768−that directly depend on external libraries like so:
769−
770−```nix
771−# default.nix
772−{ compilerVersion ? "ghc842" }:
773−let
774− # pinning nixpkgs using new Nix 2.0 builtin `fetchGit`
775− pkgs = import (fetchGit (import ./version.nix)) { };
776− compiler = pkgs.haskell.packages."${compilerVersion}";
777− pkg = compiler.developPackage {
778− root = ./.;
779− source-overrides = {
780− HUnit = "1.5.0.0"; # Let's say the GHC 8.4.2 haskellPackages uses 1.6.0.0 and your test suite is incompatible with >= 1.6.0.0
781− };
782− };
783− # in case your package source depends on any libraries directly, not just transitively.
784− buildInputs = [ zlib ];
785−in pkg.overrideAttrs(attrs: {
786− buildInputs = attrs.buildInputs ++ buildInputs;
787−})
788−```
789−
790−Notice that you will need to override (via `overrideAttrs` or similar) the
791−derivation returned by the `developPackage` Nix lambda as there is no `buildInputs`
792−named argument you can pass directly into the `developPackage` lambda.
793−
794−### How to recover from GHC's infamous non-deterministic library ID bug
795−
796−GHC and distributed build farms don't get along well:
797−
798− - https://ghc.haskell.org/trac/ghc/ticket/4012
799−
800−When you see an error like this one
801−```
802−package foo-0.7.1.0 is broken due to missing package
803−text-1.2.0.4-98506efb1b9ada233bb5c2b2db516d91
804−```
805−then you have to download and re-install `foo` and all its dependents from
806−scratch:
807−```shell
808−nix-store -q --referrers /nix/store/*-haskell-text-1.2.0.4 \
809− | xargs -L 1 nix-store --repair-path
810−```
811−
812−If you're using additional Hydra servers other than `hydra.nixos.org`, then it
813−might be necessary to purge the local caches that store data from those
814−machines to disable these binary channels for the duration of the previous
815−command, i.e. by running:
816−```shell
817−rm ~/.cache/nix/binary-cache*.sqlite
818−```
819−
820−### Builds on Darwin fail with `math.h` not found
821−
822−Users of GHC on Darwin have occasionally reported that builds fail, because the
823−compiler complains about a missing include file:
824−```
825−fatal error: 'math.h' file not found
826−```
827−The issue has been discussed at length in [ticket
828−6390](https://github.com/NixOS/nixpkgs/issues/6390), and so far no good
829−solution has been proposed. As a work-around, users who run into this problem
830−can configure the environment variables
831−```shell
832−export NIX_CFLAGS_COMPILE="-idirafter /usr/include"
833−export NIX_CFLAGS_LINK="-L/usr/lib"
834−```
835−in their `~/.bashrc` file to avoid the compiler error.
836−
837−### Builds using Stack complain about missing system libraries
838−
839−```
840−-- While building package zlib-0.5.4.2 using:
841− runhaskell -package=Cabal-1.22.4.0 -clear-package-db [... lots of flags ...]
842−Process exited with code: ExitFailure 1
843−Logs have been written to: /home/foo/src/stack-ide/.stack-work/logs/zlib-0.5.4.2.log
844−
845−Configuring zlib-0.5.4.2...
846−Setup.hs: Missing dependency on a foreign library:
847−* Missing (or bad) header file: zlib.h
848−This problem can usually be solved by installing the system package that
849−provides this library (you may need the "-dev" version). If the library is
850−already installed but in a non-standard location then you can use the flags
851−--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
852−If the header file does exist, it may contain errors that are caught by the C
853−compiler at the preprocessing stage. In this case you can re-run configure
854−with the verbosity flag -v3 to see the error messages.
855−```
856−
857−When you run the build inside of the nix-shell environment, the system
858−is configured to find `libz.so` without any special flags -- the compiler
859−and linker "just know" how to find it. Consequently, Cabal won't record
860−any search paths for `libz.so` in the package description, which means
861−that the package works fine inside of nix-shell, but once you leave the
862−shell the shared object can no longer be found. That issue is by no
863−means specific to Stack: you'll have that problem with any other
864−Haskell package that's built inside of nix-shell but run outside of that
865−environment.
866−
867−You can remedy this issue in several ways. The easiest is to add a `nix` section
868−to the `stack.yaml` like the following:
869−```yaml
870−nix:
871− enable: true
872− packages: [ zlib ]
873−```
874−
875−Stack's Nix support knows to add `${zlib.out}/lib` and `${zlib.dev}/include`
876−as an `--extra-lib-dirs` and `extra-include-dirs`, respectively.
877−Alternatively, you can achieve the same effect by hand. First of all, run
878−```
879−$ nix-build --no-out-link "<nixpkgs>" -A zlib
880−/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8
881−```
882−to find out the store path of the system's zlib library. Now, you can
883−
884− 1. add that path (plus a "/lib" suffix) to your `$LD_LIBRARY_PATH`
885− environment variable to make sure your system linker finds `libz.so`
886− automatically. It's no pretty solution, but it will work.
887−
888− 2. As a variant of (1), you can also install any number of system
889− libraries into your user's profile (or some other profile) and point
890− `$LD_LIBRARY_PATH` to that profile instead, so that you don't have to
891− list dozens of those store paths all over the place.
892−
893− 3. The solution I prefer is to call stack with an appropriate
894− --extra-lib-dirs flag like so:
895− ```shell
896− stack --extra-lib-dirs=/nix/store/alsvwzkiw4b7ip38l4nlfjijdvg3fvzn-zlib-1.2.8/lib build
897− ```
898−
899−Typically, you'll need `--extra-include-dirs` as well. It's possible
900−to add those flag to the project's `stack.yaml` or your user's
901−global `~/.stack/global/stack.yaml` file so that you don't have to
902−specify them manually every time. But again, you're likely better off
903−using Stack's Nix support instead.
904−
905−The same thing applies to `cabal configure`, of course, if you're
906−building with `cabal-install` instead of Stack.
907−
908−### Creating statically linked binaries
909−
910−There are two levels of static linking. The first option is to configure the
911−build with the Cabal flag `--disable-executable-dynamic`. In Nix expressions,
912−this can be achieved by setting the attribute:
913−```
914−enableSharedExecutables = false;
915−```
916−That gives you a binary with statically linked Haskell libraries and
917−dynamically linked system libraries.
918−
919−To link both Haskell libraries and system libraries statically, the additional
920−flags `--ghc-option=-optl=-static --ghc-option=-optl=-pthread` need to be used.
921−In Nix, this is accomplished with:
922−```
923−configureFlags = [ "--ghc-option=-optl=-static" "--ghc-option=-optl=-pthread" ];
924−```
925−
926−It's important to realize, however, that most system libraries in Nix are
927−built as shared libraries only, i.e. there is just no static library
928−available that Cabal could link!
929−
930−### Building GHC with integer-simple
931−
932−By default GHC implements the Integer type using the
933−[GNU Multiple Precision Arithmetic (GMP) library](https://gmplib.org/).
934−The implementation can be found in the
935−[integer-gmp](http://hackage.haskell.org/package/integer-gmp) package.
936−
937−A potential problem with this is that GMP is licensed under the
938−[GNU Lesser General Public License (LGPL)](http://www.gnu.org/copyleft/lesser.html),
939−a kind of "copyleft" license. According to the terms of the LGPL, paragraph 5,
940−you may distribute a program that is designed to be compiled and dynamically
941−linked with the library under the terms of your choice (i.e., commercially) but
942−if your program incorporates portions of the library, if it is linked
943−statically, then your program is a "derivative"--a "work based on the
944−library"--and according to paragraph 2, section c, you "must cause the whole of
945−the work to be licensed" under the terms of the LGPL (including for free).
946−
947−The LGPL licensing for GMP is a problem for the overall licensing of binary
948−programs compiled with GHC because most distributions (and builds) of GHC use
949−static libraries. (Dynamic libraries are currently distributed only for macOS.)
950−The LGPL licensing situation may be worse: even though
951−[The Glasgow Haskell Compiler License](https://www.haskell.org/ghc/license)
952−is essentially a "free software" license (BSD3), according to
953−paragraph 2 of the LGPL, GHC must be distributed under the terms of the LGPL!
954−
955−To work around these problems GHC can be build with a slower but LGPL-free
956−alternative implemention for Integer called
957−[integer-simple](http://hackage.haskell.org/package/integer-simple).
958−
959−To get a GHC compiler build with `integer-simple` instead of `integer-gmp` use
960−the attribute: `haskell.compiler.integer-simple."${ghcVersion}"`.
961−For example:
962−```
963−$ nix-build -E '(import <nixpkgs> {}).haskell.compiler.integer-simple.ghc802'
964−...
965−$ result/bin/ghc-pkg list | grep integer
966− integer-simple-0.1.1.1
967−```
968−The following command displays the complete list of GHC compilers build with `integer-simple`:
969−```
970−$ nix-env -f "<nixpkgs>" -qaP -A haskell.compiler.integer-simple
971−haskell.compiler.integer-simple.ghc7102 ghc-7.10.2
972−haskell.compiler.integer-simple.ghc7103 ghc-7.10.3
973−haskell.compiler.integer-simple.ghc722 ghc-7.2.2
974−haskell.compiler.integer-simple.ghc742 ghc-7.4.2
975−haskell.compiler.integer-simple.ghc783 ghc-7.8.3
976−haskell.compiler.integer-simple.ghc784 ghc-7.8.4
977−haskell.compiler.integer-simple.ghc801 ghc-8.0.1
978−haskell.compiler.integer-simple.ghc802 ghc-8.0.2
979−haskell.compiler.integer-simple.ghcHEAD ghc-8.1.20170106
980−```
981−
982−To get a package set supporting `integer-simple` use the attribute:
983−`haskell.packages.integer-simple."${ghcVersion}"`. For example
984−use the following to get the `scientific` package build with `integer-simple`:
985−```shell
986−nix-build -A haskell.packages.integer-simple.ghc802.scientific
987−```
988−
989−### Quality assurance
990−
991−The `haskell.lib` library includes a number of functions for checking for
992−various imperfections in Haskell packages. It's useful to apply these functions
993−to your own Haskell packages and integrate that in a Continuous Integration
994−server like [hydra](https://nixos.org/hydra/) to assure your packages maintain a
995−minimum level of quality. This section discusses some of these functions.
996−
997−#### failOnAllWarnings
998−
999−Applying `haskell.lib.failOnAllWarnings` to a Haskell package enables the
1000−`-Wall` and `-Werror` GHC options to turn all warnings into build failures.
1001−
1002−#### buildStrictly
1003−
1004−Applying `haskell.lib.buildStrictly` to a Haskell package calls
1005−`failOnAllWarnings` on the given package to turn all warnings into build
1006−failures. Additionally the source of your package is gotten from first invoking
1007−`cabal sdist` to ensure all needed files are listed in the Cabal file.
1008−
1009−#### checkUnusedPackages
1010−
1011−Applying `haskell.lib.checkUnusedPackages` to a Haskell package invokes
1012−the [packunused](http://hackage.haskell.org/package/packunused) tool on the
1013−package. `packunused` complains when it finds packages listed as build-depends
1014−in the Cabal file which are redundant. For example:
1015−
1016−```
1017−$ nix-build -E 'let pkgs = import <nixpkgs> {}; in pkgs.haskell.lib.checkUnusedPackages {} pkgs.haskellPackages.scientific'
1018−these derivations will be built:
1019− /nix/store/3lc51cxj2j57y3zfpq5i69qbzjpvyci1-scientific-0.3.5.1.drv
1020−...
1021−detected package components
1022−~~~~~~~~~~~~~~~~~~~~~~~~~~~
1023−
1024− - library
1025− - testsuite(s): test-scientific
1026− - benchmark(s): bench-scientific*
1027−
1028−(component names suffixed with '*' are not configured to be built)
1029−
1030−library
1031−~~~~~~~
1032−
1033−The following package dependencies seem redundant:
1034−
1035− - ghc-prim-0.5.0.0
1036−
1037−testsuite(test-scientific)
1038−~~~~~~~~~~~~~~~~~~~~~~~~~~
1039−
1040−no redundant packages dependencies found
1041−
1042−builder for ‘/nix/store/3lc51cxj2j57y3zfpq5i69qbzjpvyci1-scientific-0.3.5.1.drv’ failed with exit code 1
1043−error: build of ‘/nix/store/3lc51cxj2j57y3zfpq5i69qbzjpvyci1-scientific-0.3.5.1.drv’ failed
1044−```
1045−
1046−As you can see, `packunused` finds out that although the testsuite component has
1047−no redundant dependencies the library component of `scientific-0.3.5.1` depends
1048−on `ghc-prim` which is unused in the library.
1049−
1050−### Using hackage2nix with nixpkgs
1051−
1052−Hackage package derivations are found in the
1053−[`hackage-packages.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/hackage-packages.nix)
1054−file within `nixpkgs` and are used as the initial package set for
1055−`haskellPackages`. The `hackage-packages.nix` file is not meant to be edited
1056−by hand, but rather autogenerated by [`hackage2nix`](https://github.com/NixOS/cabal2nix/tree/master/hackage2nix),
1057−which by default uses the [`configuration-hackage2nix.yaml`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/haskell-modules/configuration-hackage2nix.yaml)
1058−file to generate all the derivations.
1059−
1060−To modify the contents `configuration-hackage2nix.yaml`, follow the
1061−instructions on [`hackage2nix`](https://github.com/NixOS/cabal2nix/tree/master/hackage2nix).
1062−
1063−## Other resources
1064−
1065− - The Youtube video [Nix Loves Haskell](https://www.youtube.com/watch?v=BsBhi_r-OeE)
1066− provides an introduction into Haskell NG aimed at beginners. The slides are
1067− available at http://cryp.to/nixos-meetup-3-slides.pdf and also -- in a form
1068− ready for cut & paste -- at
1069− https://github.com/NixOS/cabal2nix/blob/master/doc/nixos-meetup-3-slides.md.
1070−
1071− - Another Youtube video is [Escaping Cabal Hell with Nix](https://www.youtube.com/watch?v=mQd3s57n_2Y),
1072− which discusses the subject of Haskell development with Nix but also provides
1073− a basic introduction to Nix as well, i.e. it's suitable for viewers with
1074− almost no prior Nix experience.
1075−
1076− - Oliver Charles wrote a very nice [Tutorial how to develop Haskell packages with Nix](http://wiki.ocharles.org.uk/Nix).
1077−
1078− - The *Journey into the Haskell NG infrastructure* series of postings
1079− describe the new Haskell infrastructure in great detail:
1080−
1081− - [Part 1](https://nixos.org/nix-dev/2015-January/015591.html)
1082− explains the differences between the old and the new code and gives
1083− instructions how to migrate to the new setup.
1084−
1085− - [Part 2](https://nixos.org/nix-dev/2015-January/015608.html)
1086− looks in-depth at how to tweak and configure your setup by means of
1087− overrides.
1088−
1089− - [Part 3](https://nixos.org/nix-dev/2015-April/016912.html)
1090− describes the infrastructure that keeps the Haskell package set in Nixpkgs
1091− up-to-date.
3+The documentation for the Haskell infrastructure is published at
4+<https://haskell4nix.readthedocs.io/>. The source code for that
5+site lives in the `doc/` sub-directory of the
6+[`cabal2nix` Git repository](https://github.com/NixOS/cabal2nix)
7+and changes can be submitted there.
doc/languages-frameworks/hy.section.mdnew file+31
@@ -0,0 +1,31 @@
1+# Hy {#sec-language-hy}
2+
3+## Installation {#ssec-hy-installation}
4+
5+### Installation without packages {#installation-without-packages}
6+
7+You can install `hy` via nix-env or by adding it to `configuration.nix` by reffering to it as a `hy` attribute. This kind of installation adds `hy` to your environment and it succesfully works with `python3`.
8+
9+::: {.caution}
10+Packages that are installed with your python derivation, are not accesible by `hy` this way.
11+:::
12+
13+### Installation with packages {#installation-with-packages}
14+
15+Creating `hy` derivation with custom `python` packages is really simple and similar to the way that python does it. Attribute `hy` provides function `withPackages` that creates custom `hy` derivation with specified packages.
16+
17+For example if you want to create shell with `matplotlib` and `numpy`, you can do it like so:
18+
19+```ShellSession
20+$ nix-shell -p "hy.withPackages (ps: with ps; [ numpy matplotlib ])"
21+```
22+
23+Or if you want to extend your `configuration.nix`:
24+```nix
25+{ # ...
26+
27+ environment.systemPackages = with pkgs; [
28+ (hy.withPackages (py-packages: with py-packages; [ numpy matplotlib ]))
29+ ];
30+}
31+```
doc/languages-frameworks/idris.section.md+51−23
@@ -1,24 +1,33 @@
1−# Idris packages
1+# Idris {#idris}
22
3−## Installing Idris
3+## Installing Idris {#installing-idris}
44
55The easiest way to get a working idris version is to install the `idris` attribute:
66
7−```
8−$ # On NixOS
9−$ nix-env -i nixos.idris
10−$ # On non-NixOS
11−$ nix-env -i nixpkgs.idris
7+```ShellSession
8+$ nix-env -f "<nixpkgs>" -iA idris
129```
1310
14−This however only provides the `prelude` and `base` libraries. To install additional libraries:
11+This however only provides the `prelude` and `base` libraries. To install idris with additional libraries, you can use the `idrisPackages.with-packages` function, e.g. in an overlay in `~/.config/nixpkgs/overlays/my-idris.nix`:
1512
13+```nix
14+self: super: {
15+ myIdris = with self.idrisPackages; with-packages [ contrib pruviloj ];
16+}
1617```
17−$ nix-env -iE 'pkgs: pkgs.idrisPackages.with-packages (with pkgs.idrisPackages; [ contrib pruviloj ])'
18+
19+And then:
20+
21+```ShellSession
22+$ # On NixOS
23+$ nix-env -iA nixos.myIdris
24+$ # On non-NixOS
25+$ nix-env -iA nixpkgs.myIdris
1826```
1927
2028To see all available Idris packages:
21−```
29+
30+```ShellSession
2231$ # On NixOS
2332$ nix-env -qaPA nixos.idrisPackages
2433$ # On non-NixOS
@@ -26,22 +35,23 @@ $ nix-env -qaPA nixpkgs.idrisPackages
2635```
2736
2837Similarly, entering a `nix-shell`:
29−```
38+
39+```ShellSession
3040$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
3141```
3242
33−## Starting Idris with library support
43+## Starting Idris with library support {#starting-idris-with-library-support}
3444
3545To have access to these libraries in idris, call it with an argument `-p <library name>` for each library:
3646
37−```
47+```ShellSession
3848$ nix-shell -p 'idrisPackages.with-packages (with idrisPackages; [ contrib pruviloj ])'
3949[nix-shell:~]$ idris -p contrib -p pruviloj
4050```
4151
4252A listing of all available packages the Idris binary has access to is available via `--listlibs`:
4353
44−```
54+```ShellSession
4555$ idris --listlibs
465600prelude-idx.ibc
4757pruviloj
@@ -53,16 +63,16 @@ prelude
536300contrib-idx.ibc
5464```
5565
56−## Building an Idris project with Nix
66+## Building an Idris project with Nix {#building-an-idris-project-with-nix}
5767
5868As an example of how a Nix expression for an Idris package can be created, here is the one for `idrisPackages.yaml`:
5969
6070```nix
61−{ build-idris-package
71+{ lib
72+, build-idris-package
6273, fetchFromGitHub
6374, contrib
6475, lightyear
65−, lib
6676}:
6777build-idris-package {
6878 name = "yaml";
@@ -83,18 +93,18 @@ build-idris-package {
8393 sha256 = "1g4pi0swmg214kndj85hj50ccmckni7piprsxfdzdfhg87s0avw7";
8494 };
8595
86− meta = {
96+ meta = with lib; {
8797 description = "Idris YAML lib";
88− homepage = https://github.com/Heather/Idris.Yaml;
89− license = lib.licenses.mit;
90− maintainers = [ lib.maintainers.brainrape ];
98+ homepage = "https://github.com/Heather/Idris.Yaml";
99+ license = licenses.mit;
100+ maintainers = [ maintainers.brainrape ];
91101 };
92102}
93103```
94104
95105Assuming this file is saved as `yaml.nix`, it's buildable using
96106
97−```
107+```ShellSession
98108$ nix-build -E '(import <nixpkgs> {}).idrisPackages.callPackage ./yaml.nix {}'
99109```
100110
@@ -110,6 +120,24 @@ with import <nixpkgs> {};
110120
111121in another file (say `default.nix`) to be able to build it with
112122
113−```
123+```ShellSession
114124$ nix-build -A yaml
115125```
126+
127+## Passing options to `idris` commands {#passing-options-to-idris-commands}
128+
129+The `build-idris-package` function provides also optional input values to set additional options for the used `idris` commands.
130+
131+Specifically, you can set `idrisBuildOptions`, `idrisTestOptions`, `idrisInstallOptions` and `idrisDocOptions` to provide additional options to the `idris` command respectively when building, testing, installing and generating docs for your package.
132+
133+For example you could set
134+
135+```nix
136+build-idris-package {
137+ idrisBuildOptions = [ "--log" "1" "--verbose" ]
138+
139+ ...
140+}
141+```
142+
143+to require verbose output during `idris` build phase.
doc/languages-frameworks/index.xml+30−20
@@ -1,32 +1,42 @@
11<chapter xmlns="http://docbook.org/ns/docbook"
22 xmlns:xi="http://www.w3.org/2001/XInclude"
33 xml:id="chap-language-support">
4− <title>Support for specific programming languages and frameworks</title>
4+ <title>Languages and frameworks</title>
55 <para>
6− The <link linkend="chap-stdenv">standard build environment</link> makes it
7− easy to build typical Autotools-based packages with very little code. Any
8− other kind of package can be accomodated by overriding the appropriate phases
9− of <literal>stdenv</literal>. However, there are specialised functions in
10− Nixpkgs to easily build packages for other programming languages, such as
11− Perl or Haskell. These are described in this chapter.
6+ The <link linkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
127 </para>
13− <xi:include href="beam.xml" />
14− <xi:include href="bower.xml" />
15− <xi:include href="coq.xml" />
16− <xi:include href="go.xml" />
8+ <xi:include href="agda.section.xml" />
9+ <xi:include href="android.section.xml" />
10+ <xi:include href="beam.section.xml" />
11+ <xi:include href="bower.section.xml" />
12+ <xi:include href="chicken.section.xml" />
13+ <xi:include href="coq.section.xml" />
14+ <xi:include href="crystal.section.xml" />
15+ <xi:include href="cuda.section.xml" />
16+ <xi:include href="dhall.section.xml" />
17+ <xi:include href="dotnet.section.xml" />
18+ <xi:include href="emscripten.section.xml" />
19+ <xi:include href="gnome.section.xml" />
20+ <xi:include href="go.section.xml" />
1721 <xi:include href="haskell.section.xml" />
22+ <xi:include href="hy.section.xml" />
1823 <xi:include href="idris.section.xml" />
19− <xi:include href="java.xml" />
20− <xi:include href="lua.xml" />
21− <xi:include href="node.section.xml" />
22− <xi:include href="ocaml.xml" />
23− <xi:include href="perl.xml" />
24+ <xi:include href="ios.section.xml" />
25+ <xi:include href="java.section.xml" />
26+ <xi:include href="javascript.section.xml" />
27+ <xi:include href="lua.section.xml" />
28+ <xi:include href="maven.section.xml" />
29+ <xi:include href="nim.section.xml" />
30+ <xi:include href="ocaml.section.xml" />
31+ <xi:include href="octave.section.xml" />
32+ <xi:include href="perl.section.xml" />
33+ <xi:include href="php.section.xml" />
2434 <xi:include href="python.section.xml" />
25− <xi:include href="qt.xml" />
35+ <xi:include href="qt.section.xml" />
2636 <xi:include href="r.section.xml" />
27− <xi:include href="ruby.xml" />
37+ <xi:include href="ruby.section.xml" />
2838 <xi:include href="rust.section.xml" />
29− <xi:include href="texlive.xml" />
39+ <xi:include href="texlive.section.xml" />
40+ <xi:include href="titanium.section.xml" />
3041 <xi:include href="vim.section.xml" />
31− <xi:include href="emscripten.section.xml" />
3242</chapter>
doc/languages-frameworks/ios.section.mdnew file+225
@@ -0,0 +1,225 @@
1+# iOS {#ios}
2+
3+This component is basically a wrapper/workaround that makes it possible to
4+expose an Xcode installation as a Nix package by means of symlinking to the
5+relevant executables on the host system.
6+
7+Since Xcode can't be packaged with Nix, nor we can publish it as a Nix package
8+(because of its license) this is basically the only integration strategy
9+making it possible to do iOS application builds that integrate with other
10+components of the Nix ecosystem
11+
12+The primary objective of this project is to use the Nix expression language to
13+specify how iOS apps can be built from source code, and to automatically spawn
14+iOS simulator instances for testing.
15+
16+This component also makes it possible to use [Hydra](https://nixos.org/hydra),
17+the Nix-based continuous integration server to regularly build iOS apps and to
18+do wireless ad-hoc installations of enterprise IPAs on iOS devices through
19+Hydra.
20+
21+The Xcode build environment implements a number of features.
22+
23+## Deploying a proxy component wrapper exposing Xcode {#deploying-a-proxy-component-wrapper-exposing-xcode}
24+
25+The first use case is deploying a Nix package that provides symlinks to the Xcode
26+installation on the host system. This package can be used as a build input to
27+any build function implemented in the Nix expression language that requires
28+Xcode.
29+
30+```nix
31+let
32+ pkgs = import <nixpkgs> {};
33+
34+ xcodeenv = import ./xcodeenv {
35+ inherit (pkgs) stdenv;
36+ };
37+in
38+xcodeenv.composeXcodeWrapper {
39+ version = "9.2";
40+ xcodeBaseDir = "/Applications/Xcode.app";
41+}
42+```
43+
44+By deploying the above expression with `nix-build` and inspecting its content
45+you will notice that several Xcode-related executables are exposed as a Nix
46+package:
47+
48+```bash
49+$ ls result/bin
50+lrwxr-xr-x 1 sander staff 94 1 jan 1970 Simulator -> /Applications/Xcode.app/Contents/Developer/Applications/Simulator.app/Contents/MacOS/Simulator
51+lrwxr-xr-x 1 sander staff 17 1 jan 1970 codesign -> /usr/bin/codesign
52+lrwxr-xr-x 1 sander staff 17 1 jan 1970 security -> /usr/bin/security
53+lrwxr-xr-x 1 sander staff 21 1 jan 1970 xcode-select -> /usr/bin/xcode-select
54+lrwxr-xr-x 1 sander staff 61 1 jan 1970 xcodebuild -> /Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
55+lrwxr-xr-x 1 sander staff 14 1 jan 1970 xcrun -> /usr/bin/xcrun
56+```
57+
58+## Building an iOS application {#building-an-ios-application}
59+
60+We can build an iOS app executable for the simulator, or an IPA/xcarchive file
61+for release purposes, e.g. ad-hoc, enterprise or store installations, by
62+executing the `xcodeenv.buildApp {}` function:
63+
64+```nix
65+let
66+ pkgs = import <nixpkgs> {};
67+
68+ xcodeenv = import ./xcodeenv {
69+ inherit (pkgs) stdenv;
70+ };
71+in
72+xcodeenv.buildApp {
73+ name = "MyApp";
74+ src = ./myappsources;
75+ sdkVersion = "11.2";
76+
77+ target = null; # Corresponds to the name of the app by default
78+ configuration = null; # Release for release builds, Debug for debug builds
79+ scheme = null; # -scheme will correspond to the app name by default
80+ sdk = null; # null will set it to 'iphonesimulator` for simulator builds or `iphoneos` to real builds
81+ xcodeFlags = "";
82+
83+ release = true;
84+ certificateFile = ./mycertificate.p12;
85+ certificatePassword = "secret";
86+ provisioningProfile = ./myprovisioning.profile;
87+ signMethod = "ad-hoc"; # 'enterprise' or 'store'
88+ generateIPA = true;
89+ generateXCArchive = false;
90+
91+ enableWirelessDistribution = true;
92+ installURL = "/installipa.php";
93+ bundleId = "mycompany.myapp";
94+ appVersion = "1.0";
95+
96+ # Supports all xcodewrapper parameters as well
97+ xcodeBaseDir = "/Applications/Xcode.app";
98+}
99+```
100+
101+The above function takes a variety of parameters:
102+
103+* The `name` and `src` parameters are mandatory and specify the name of the app
104+ and the location where the source code resides
105+* `sdkVersion` specifies which version of the iOS SDK to use.
106+
107+It also possile to adjust the `xcodebuild` parameters. This is only needed in
108+rare circumstances. In most cases the default values should suffice:
109+
110+* Specifies which `xcodebuild` target to build. By default it takes the target
111+ that has the same name as the app.
112+* The `configuration` parameter can be overridden if desired. By default, it
113+ will do a debug build for the simulator and a release build for real devices.
114+* The `scheme` parameter specifies which `-scheme` parameter to propagate to
115+ `xcodebuild`. By default, it corresponds to the app name.
116+* The `sdk` parameter specifies which SDK to use. By default, it picks
117+ `iphonesimulator` for simulator builds and `iphoneos` for release builds.
118+* The `xcodeFlags` parameter specifies arbitrary command line parameters that
119+ should be propagated to `xcodebuild`.
120+
121+By default, builds are carried out for the iOS simulator. To do release builds
122+(builds for real iOS devices), you must set the `release` parameter to `true`.
123+In addition, you need to set the following parameters:
124+
125+* `certificateFile` refers to a P12 certificate file.
126+* `certificatePassword` specifies the password of the P12 certificate.
127+* `provisioningProfile` refers to the provision profile needed to sign the app
128+* `signMethod` should refer to `ad-hoc` for signing the app with an ad-hoc
129+ certificate, `enterprise` for enterprise certificates and `app-store` for App
130+ store certificates.
131+* `generateIPA` specifies that we want to produce an IPA file (this is probably
132+ what you want)
133+* `generateXCArchive` specifies thet we want to produce an xcarchive file.
134+
135+When building IPA files on Hydra and when it is desired to allow iOS devices to
136+install IPAs by browsing to the Hydra build products page, you can enable the
137+`enableWirelessDistribution` parameter.
138+
139+When enabled, you need to configure the following options:
140+
141+* The `installURL` parameter refers to the URL of a PHP script that composes the
142+ `itms-services://` URL allowing iOS devices to install the IPA file.
143+* `bundleId` refers to the bundle ID value of the app
144+* `appVersion` refers to the app's version number
145+
146+To use wireless adhoc distributions, you must also install the corresponding
147+PHP script on a web server (see section: 'Installing the PHP script for wireless
148+ad hoc installations from Hydra' for more information).
149+
150+In addition to the build parameters, you can also specify any parameters that
151+the `xcodeenv.composeXcodeWrapper {}` function takes. For example, the
152+`xcodeBaseDir` parameter can be overridden to refer to a different Xcode
153+version.
154+
155+## Spawning simulator instances {#spawning-simulator-instances}
156+
157+In addition to building iOS apps, we can also automatically spawn simulator
158+instances:
159+
160+```nix
161+let
162+ pkgs = import <nixpkgs> {};
163+
164+ xcodeenv = import ./xcodeenv {
165+ inherit (pkgs) stdenv;
166+ };
167+in
168+xcode.simulateApp {
169+ name = "simulate";
170+
171+ # Supports all xcodewrapper parameters as well
172+ xcodeBaseDir = "/Applications/Xcode.app";
173+}
174+```
175+
176+The above expression produces a script that starts the simulator from the
177+provided Xcode installation. The script can be started as follows:
178+
179+```bash
180+./result/bin/run-test-simulator
181+```
182+
183+By default, the script will show an overview of UDID for all available simulator
184+instances and asks you to pick one. You can also provide a UDID as a
185+command-line parameter to launch an instance automatically:
186+
187+```bash
188+./result/bin/run-test-simulator 5C93129D-CF39-4B1A-955F-15180C3BD4B8
189+```
190+
191+You can also extend the simulator script to automatically deploy and launch an
192+app in the requested simulator instance:
193+
194+```nix
195+let
196+ pkgs = import <nixpkgs> {};
197+
198+ xcodeenv = import ./xcodeenv {
199+ inherit (pkgs) stdenv;
200+ };
201+in
202+xcode.simulateApp {
203+ name = "simulate";
204+ bundleId = "mycompany.myapp";
205+ app = xcode.buildApp {
206+ # ...
207+ };
208+
209+ # Supports all xcodewrapper parameters as well
210+ xcodeBaseDir = "/Applications/Xcode.app";
211+}
212+```
213+
214+By providing the result of an `xcode.buildApp {}` function and configuring the
215+app bundle id, the app gets deployed automatically and started.
216+
217+## Troubleshooting {#troubleshooting}
218+
219+In some rare cases, it may happen that after a failure, changes are not picked
220+up. Most likely, this is caused by a derived data cache that Xcode maintains.
221+To wipe it you can run:
222+
223+```bash
224+$ rm -rf ~/Library/Developer/Xcode/DerivedData
225+```
doc/languages-frameworks/java.section.mdnew file+100
@@ -0,0 +1,100 @@
1+# Java {#sec-language-java}
2+
3+Ant-based Java packages are typically built from source as follows:
4+
5+```nix
6+stdenv.mkDerivation {
7+ name = "...";
8+ src = fetchurl { ... };
9+
10+ nativeBuildInputs = [ jdk ant ];
11+
12+ buildPhase = "ant";
13+}
14+```
15+
16+Note that `jdk` is an alias for the OpenJDK (self-built where available,
17+or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs
18+(`Aarch32`, `Aarch64`) point to the (unfree) `oraclejdk`.
19+
20+JAR files that are intended to be used by other packages should be
21+installed in `$out/share/java`. JDKs have a stdenv setup hook that add
22+any JARs in the `share/java` directories of the build inputs to the
23+`CLASSPATH` environment variable. For instance, if the package `libfoo`
24+installs a JAR named `foo.jar` in its `share/java` directory, and
25+another package declares the attribute
26+
27+```nix
28+buildInputs = [ libfoo ];
29+nativeBuildInputs = [ jdk ];
30+```
31+
32+then `CLASSPATH` will be set to
33+`/nix/store/...-libfoo/share/java/foo.jar`.
34+
35+Private JARs should be installed in a location like
36+`$out/share/package-name`.
37+
38+If your Java package provides a program, you need to generate a wrapper
39+script to run it using a JRE. You can use `makeWrapper` for this:
40+
41+```nix
42+nativeBuildInputs = [ makeWrapper ];
43+
44+installPhase = ''
45+ mkdir -p $out/bin
46+ makeWrapper ${jre}/bin/java $out/bin/foo \
47+ --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
48+'';
49+```
50+
51+Since the introduction of the Java Platform Module System in Java 9,
52+Java distributions typically no longer ship with a general-purpose JRE:
53+instead, they allow generating a JRE with only the modules required for
54+your application(s). Because we can't predict what modules will be
55+needed on a general-purpose system, the default jre package is the full
56+JDK. When building a minimal system/image, you can override the
57+`modules` parameter on `jre_minimal` to build a JRE with only the
58+modules relevant for you:
59+
60+```nix
61+let
62+ my_jre = pkgs.jre_minimal.override {
63+ modules = [
64+ # The modules used by 'something' and 'other' combined:
65+ "java.base"
66+ "java.logging"
67+ ];
68+ };
69+ something = (pkgs.something.override { jre = my_jre; });
70+ other = (pkgs.other.override { jre = my_jre; });
71+in
72+ ...
73+```
74+
75+You can also specify what JDK your JRE should be based on, for example
76+selecting a 'headless' build to avoid including a link to GTK+:
77+
78+```nix
79+my_jre = pkgs.jre_minimal.override {
80+ jdk = jdk11_headless;
81+};
82+```
83+
84+Note all JDKs passthru `home`, so if your application requires
85+environment variables like `JAVA_HOME` being set, that can be done in a
86+generic fashion with the `--set` argument of `makeWrapper`:
87+
88+```bash
89+--set JAVA_HOME ${jdk.home}
90+```
91+
92+It is possible to use a different Java compiler than `javac` from the
93+OpenJDK. For instance, to use the GNU Java Compiler:
94+
95+```nix
96+nativeBuildInputs = [ gcj ant ];
97+```
98+
99+Here, Ant will automatically use `gij` (the GNU Java Runtime) instead of
100+the OpenJRE.
doc/languages-frameworks/java.xmldeleted−84
@@ -1,84 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-java">
4− <title>Java</title>
5−
6− <para>
7− Ant-based Java packages are typically built from source as follows:
8−<programlisting>
9−stdenv.mkDerivation {
10− name = "...";
11− src = fetchurl { ... };
12−
13− buildInputs = [ jdk ant ];
14−
15− buildPhase = "ant";
16−}
17−</programlisting>
18− Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built
19− where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in
20− Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the
21− (unfree) <literal>oraclejdk</literal>.
22− </para>
23−
24− <para>
25− JAR files that are intended to be used by other packages should be installed
26− in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that
27− add any JARs in the <filename>share/java</filename> directories of the build
28− inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if
29− the package <literal>libfoo</literal> installs a JAR named
30− <filename>foo.jar</filename> in its <filename>share/java</filename>
31− directory, and another package declares the attribute
32−<programlisting>
33−buildInputs = [ jdk libfoo ];
34−</programlisting>
35− then <envar>CLASSPATH</envar> will be set to
36− <filename>/nix/store/...-libfoo/share/java/foo.jar</filename>.
37− </para>
38−
39− <para>
40− Private JARs should be installed in a location like
41− <filename>$out/share/<replaceable>package-name</replaceable></filename>.
42− </para>
43−
44− <para>
45− If your Java package provides a program, you need to generate a wrapper
46− script to run it using the OpenJRE. You can use
47− <literal>makeWrapper</literal> for this:
48−<programlisting>
49−buildInputs = [ makeWrapper ];
50−
51−installPhase =
52− ''
53− mkdir -p $out/bin
54− makeWrapper ${jre}/bin/java $out/bin/foo \
55− --add-flags "-cp $out/share/java/foo.jar org.foo.Main"
56− '';
57−</programlisting>
58− Note the use of <literal>jre</literal>, which is the part of the OpenJDK
59− package that contains the Java Runtime Environment. By using
60− <literal>${jre}/bin/java</literal> instead of
61− <literal>${jdk}/bin/java</literal>, you prevent your package from depending
62− on the JDK at runtime.
63− </para>
64−
65− <para>
66− Note all JDKs passthru <literal>home</literal>, so if your application
67− requires environment variables like <envar>JAVA_HOME</envar> being set, that
68− can be done in a generic fashion with the <literal>--set</literal> argument
69− of <literal>makeWrapper</literal>:
70−<programlisting>
71− --set JAVA_HOME ${jdk.home}
72−</programlisting>
73− </para>
74−
75− <para>
76− It is possible to use a different Java compiler than <command>javac</command>
77− from the OpenJDK. For instance, to use the GNU Java Compiler:
78−<programlisting>
79−buildInputs = [ gcj ant ];
80−</programlisting>
81− Here, Ant will automatically use <command>gij</command> (the GNU Java
82− Runtime) instead of the OpenJRE.
83− </para>
84−</section>
doc/languages-frameworks/javascript.section.mdnew file+278
@@ -0,0 +1,278 @@
1+# Javascript {#language-javascript}
2+
3+## Introduction {#javascript-introduction}
4+
5+This contains instructions on how to package javascript applications.
6+
7+The various tools available will be listed in the [tools-overview](#javascript-tools-overview). Some general principles for packaging will follow. Finally some tool specific instructions will be given.
8+
9+## Getting unstuck / finding code examples
10+
11+If you find you are lacking inspiration for packing javascript applications, the links below might prove useful.
12+Searching online for prior art can be helpful if you are running into solved problems.
13+
14+### Github
15+
16+- Searching Nix files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+language%3ANix&type=code>
17+
18+- Searching just `flake.nix` files for `mkYarnPackage`: <https://github.com/search?q=mkYarnPackage+filename%3Aflake.nix&type=code>
19+
20+### Gitlab
21+
22+- Searching Nix files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+extension%3Anix>
23+
24+- Searching just `flake.nix` files for `mkYarnPackage`: <https://gitlab.com/search?scope=blobs&search=mkYarnPackage+filename%3Aflake.nix>
25+
26+## Tools overview {#javascript-tools-overview}
27+
28+## General principles {#javascript-general-principles}
29+
30+The following principles are given in order of importance with potential exceptions.
31+
32+### Try to use the same node version used upstream {#javascript-upstream-node-version}
33+
34+It is often not documented which node version is used upstream, but if it is, try to use the same version when packaging.
35+
36+This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node. Some cryptic errors regarding V8 may appear.
37+
38+An exception to this:
39+
40+### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
41+
42+A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of node_modules for each tool.
43+
44+Guidelines of package managers, recommend to commit those lock files to the repos. If a particular lock file is present, it is a strong indication of which package manager is used upstream.
45+
46+It's better to try to use a nix tool that understand the lock file. Using a different tool might give you hard to understand error because different packages have been installed. An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629). Upstream uses npm, but this is an attempt to package it with yarn2nix (that uses yarn.lock)
47+
48+Using a different tool forces to commit a lock file to the repository. Those files are fairly large, so when packaging for nixpkgs, this approach does not scale well.
49+
50+Exceptions to this rule are:
51+
52+- when you encounter one of the bugs from a nix tool. In each of the tool specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to recreate a lock file and commit it to nixpkgs. In general yarn2nix has less known problems and so a simple search in nixpkgs will reveal many yarn.lock files committed
53+- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
54+- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is yarn2nix. If upstream has workspaces you should try yarn2nix.
55+
56+### Try to use upstream package.json {#javascript-upstream-package-json}
57+
58+Exceptions to this rule are
59+
60+- Sometimes the upstream repo assumes some dependencies be installed globally. In that case you can add them manually to the upstream package.json (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for cli tools. (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
61+- Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version (by removing the `^`).
62+- Sometimes the script defined in the package.json does not work as is. Some scripts for example use cli tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into:
63+
64+```Shell
65+yarn build:ui
66+yarn build:server
67+# OR
68+npm run build:ui
69+npm run build:server
70+```
71+
72+when you need to override a package.json. It's nice to use the one from the upstream src and do some explicit override. Here is an example.
73+
74+```nix
75+patchedPackageJSON = final.runCommand "package.json" { } ''
76+ ${jq}/bin/jq '.version = "0.4.0" |
77+ .devDependencies."@jsdoc/cli" = "^0.2.5"
78+ ${sonar-src}/package.json > $out
79+'';
80+```
81+
82+you will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
83+
84+### Using node_modules directly {#javascript-using-node_modules}
85+
86+each tool has an abstraction to just build the node_modules (dependencies) directory. you can always use the stdenv.mkDerivation with the node_modules to build the package (symlink the node_modules directory and then use the package build command). the node_modules abstraction can be also used to build some web framework frontends. For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. mkYarnModules to make the derivation containing node_modules. Then when building the frontend you can just symlink the node_modules directory
87+
88+## Javascript packages inside nixpkgs {#javascript-packages-nixpkgs}
89+
90+The `pkgs/development/node-packages` folder contains a generated collection of
91+[NPM packages](https://npmjs.com/) that can be installed with the Nix package
92+manager.
93+
94+As a rule of thumb, the package set should only provide _end user_ software
95+packages, such as command-line utilities. Libraries should only be added to the
96+package set if there is a non-NPM package that requires it.
97+
98+When it is desired to use NPM libraries in a development project, use the
99+`node2nix` generator directly on the `package.json` configuration file of the
100+project.
101+
102+The package set provides support for the official stable Node.js versions.
103+The latest stable LTS release in `nodePackages`, as well as the latest stable
104+Current release in `nodePackages_latest`.
105+
106+If your package uses native addons, you need to examine what kind of native
107+build system it uses. Here are some examples:
108+
109+- `node-gyp`
110+- `node-gyp-builder`
111+- `node-pre-gyp`
112+
113+After you have identified the correct system, you need to override your package
114+expression while adding in build system as a build input. For example, `dat`
115+requires `node-gyp-build`, so [we override](https://github.com/NixOS/nixpkgs/blob/32f5e5da4a1b3f0595527f5195ac3a91451e9b56/pkgs/development/node-packages/default.nix#L37-L40) its expression in [`default.nix`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/node-packages/default.nix):
116+
117+```nix
118+ dat = super.dat.override {
119+ buildInputs = [ self.node-gyp-build pkgs.libtool pkgs.autoconf pkgs.automake ];
120+ meta.broken = since "12";
121+ };
122+```
123+
124+### Adding and Updating Javascript packages in nixpkgs
125+
126+To add a package from NPM to nixpkgs:
127+
128+1. Modify `pkgs/development/node-packages/node-packages.json` to add, update
129+ or remove package entries to have it included in `nodePackages` and
130+ `nodePackages_latest`.
131+2. Run the script: `./pkgs/development/node-packages/generate.sh`.
132+3. Build your new package to test your changes:
133+ `cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
134+ To build against the latest stable Current Node.js version (e.g. 14.x):
135+ `nix-build -A nodePackages_latest.<new-or-updated-package>`
136+4. Add and commit all modified and generated files.
137+
138+For more information about the generation process, consult the
139+[README.md](https://github.com/svanderburg/node2nix) file of the `node2nix`
140+tool.
141+
142+To update NPM packages in nixpkgs, run the same `generate.sh` script:
143+
144+```sh
145+./pkgs/development/node-packages/generate.sh
146+```
147+
148+#### Git protocol error
149+
150+Some packages may have Git dependencies from GitHub specified with `git://`.
151+GitHub has
152+[disabled unecrypted Git connections](https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git),
153+so you may see the following error when running the generate script:
154+`The unauthenticated git protocol on port 9418 is no longer supported`.
155+
156+Use the following Git configuration to resolve the issue:
157+
158+```sh
159+git config --global url."https://github.com/".insteadOf git://github.com/
160+```
161+
162+## Tool specific instructions {#javascript-tool-specific}
163+
164+### node2nix {#javascript-node2nix}
165+
166+#### Preparation {#javascript-node2nix-preparation}
167+
168+you will need to generate a nix expression for the dependencies
169+
170+- don't forget the `-l package-lock.json` if there is a lock file
171+- Most probably you will need the `--development` to include the `devDependencies`
172+
173+so the command will most likely be
174+`node2nix --development -l package-lock.json`
175+
176+[link to the doc in the repo](https://github.com/svanderburg/node2nix)
177+
178+#### Pitfalls {#javascript-node2nix-pitfalls}
179+
180+- if upstream package.json does not have a "version" attribute, node2nix will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json)
181+- node2nix has some [bugs](https://github.com/svanderburg/node2nix/issues/238). related to working with lock files from npm distributed with nodejs-16_x
182+- node2nix does not like missing packages from npm. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of npm.
183+
184+### yarn2nix {#javascript-yarn2nix}
185+
186+#### Preparation {#javascript-yarn2nix-preparation}
187+
188+you will need at least a yarn.lock and yarn.nix file
189+
190+- generate a yarn.lock in upstream if it is not already there
191+- `yarn2nix > yarn.nix` will generate the dependencies in a nix format
192+
193+#### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}
194+
195+this will by default try to generate a binary. For package only generating static assets (Svelte, Vue, React...), you will need to explicitly override the build step with your instructions. It's important to use the `--offline` flag. For example if you script is `"build": "something"` in package.json use
196+
197+```nix
198+buildPhase = ''
199+ yarn build --offline
200+'';
201+```
202+
203+The dist phase is also trying to build a binary, the only way to override it is with
204+
205+```nix
206+distPhase = "true";
207+```
208+
209+the configure phase can sometimes fail because it tries to be too clever.
210+One common override is
211+
212+```nix
213+configurePhase = "ln -s $node_modules node_modules";
214+```
215+
216+#### mkYarnModules {#javascript-yarn2nix-mkYarnModules}
217+
218+this will generate a derivation including the node_modules. If you have to build a derivation for an integrated web framework (rails, phoenix..), this is probably the easiest way. [Plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix#L39) offers a good example of how to do this.
219+
220+#### Overriding dependency behavior
221+
222+In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.
223+
224+For instance, say your package is throwing errors when trying to invoke node-sass: `ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'`
225+
226+To fix this we will specify different versions of build inputs to use, as well as some post install steps to get the software built the way we want:
227+
228+```nix
229+mkYarnPackage rec {
230+ pkgConfig = {
231+ node-sass = {
232+ buildInputs = with final;[ python libsass pkg-config ];
233+ postInstall = ''
234+ LIBSASS_EXT=auto yarn --offline run build
235+ rm build/config.gypi
236+ '';
237+ };
238+ };
239+}
240+```
241+
242+#### Pitfalls {#javascript-yarn2nix-pitfalls}
243+
244+- if version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)
245+
246+- having trouble with node-gyp? Try adding these lines to the `yarnPreBuild` steps:
247+
248+ ```nix
249+ yarnPreBuild = ''
250+ mkdir -p $HOME/.node-gyp/${nodejs.version}
251+ echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion
252+ ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}
253+ export npm_config_nodedir=${nodejs}
254+ '';
255+ ```
256+
257+ - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
258+ - Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>
259+
260+## Outside of nixpkgs {#javascript-outside-nixpkgs}
261+
262+There are some other options available that can't be used inside nixpkgs. Those other options are written in nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in hydra at present. If you are packaging something outside nixpkgs, those can be considered
263+
264+### npmlock2nix {#javascript-npmlock2nix}
265+
266+[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might be subject to change.
267+
268+#### Pitfalls {#javascript-npmlock2nix-pitfalls}
269+
270+- there are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issues/45).
271+
272+### nix-npm-buildpackage {#javascript-nix-npm-buildpackage}
273+
274+[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the api might change. It supports both package-lock.json and yarn.lock.
275+
276+#### Pitfalls {#javascript-nix-npm-buildpackage-pitfalls}
277+
278+- there are some [problems with npm v7](https://github.com/serokell/nix-npm-buildpackage/issues/33).
doc/languages-frameworks/lua.section.mdnew file+253
@@ -0,0 +1,253 @@
1+# User’s Guide to Lua Infrastructure {#users-guide-to-lua-infrastructure}
2+
3+## Using Lua {#using-lua}
4+
5+### Overview of Lua {#overview-of-lua}
6+
7+Several versions of the Lua interpreter are available: luajit, lua 5.1, 5.2, 5.3.
8+The attribute `lua` refers to the default interpreter, it is also possible to refer to specific versions, e.g. `lua5_2` refers to Lua 5.2.
9+
10+Lua libraries are in separate sets, with one set per interpreter version.
11+
12+The interpreters have several common attributes. One of these attributes is
13+`pkgs`, which is a package set of Lua libraries for this specific
14+interpreter. E.g., the `busted` package corresponding to the default interpreter
15+is `lua.pkgs.busted`, and the lua 5.2 version is `lua5_2.pkgs.busted`.
16+The main package set contains aliases to these package sets, e.g.
17+`luaPackages` refers to `lua5_1.pkgs` and `lua52Packages` to
18+`lua5_2.pkgs`.
19+
20+### Installing Lua and packages {#installing-lua-and-packages}
21+
22+#### Lua environment defined in separate `.nix` file {#lua-environment-defined-in-separate-.nix-file}
23+
24+Create a file, e.g. `build.nix`, with the following expression
25+
26+```nix
27+with import <nixpkgs> {};
28+
29+lua5_2.withPackages (ps: with ps; [ busted luafilesystem ])
30+```
31+
32+and install it in your profile with
33+
34+```shell
35+nix-env -if build.nix
36+```
37+Now you can use the Lua interpreter, as well as the extra packages (`busted`,
38+`luafilesystem`) that you added to the environment.
39+
40+#### Lua environment defined in `~/.config/nixpkgs/config.nix` {#lua-environment-defined-in-.confignixpkgsconfig.nix}
41+
42+If you prefer to, you could also add the environment as a package override to the Nixpkgs set, e.g.
43+using `config.nix`,
44+
45+```nix
46+{ # ...
47+
48+ packageOverrides = pkgs: with pkgs; {
49+ myLuaEnv = lua5_2.withPackages (ps: with ps; [ busted luafilesystem ]);
50+ };
51+}
52+```
53+
54+and install it in your profile with
55+
56+```shell
57+nix-env -iA nixpkgs.myLuaEnv
58+```
59+The environment is installed by referring to the attribute, and considering
60+the `nixpkgs` channel was used.
61+
62+#### Lua environment defined in `/etc/nixos/configuration.nix` {#lua-environment-defined-in-etcnixosconfiguration.nix}
63+
64+For the sake of completeness, here's another example how to install the environment system-wide.
65+
66+```nix
67+{ # ...
68+
69+ environment.systemPackages = with pkgs; [
70+ (lua.withPackages(ps: with ps; [ busted luafilesystem ]))
71+ ];
72+}
73+```
74+
75+### How to override a Lua package using overlays? {#how-to-override-a-lua-package-using-overlays}
76+
77+Use the following overlay template:
78+
79+```nix
80+final: prev:
81+{
82+
83+ lua = prev.lua.override {
84+ packageOverrides = luaself: luaprev: {
85+
86+ luarocks-nix = luaprev.luarocks-nix.overrideAttrs(oa: {
87+ pname = "luarocks-nix";
88+ src = /home/my_luarocks/repository;
89+ });
90+ };
91+
92+ luaPackages = lua.pkgs;
93+}
94+```
95+
96+### Temporary Lua environment with `nix-shell` {#temporary-lua-environment-with-nix-shell}
97+
98+
99+There are two methods for loading a shell with Lua packages. The first and recommended method
100+is to create an environment with `lua.buildEnv` or `lua.withPackages` and load that. E.g.
101+
102+```sh
103+$ nix-shell -p 'lua.withPackages(ps: with ps; [ busted luafilesystem ])'
104+```
105+
106+opens a shell from which you can launch the interpreter
107+
108+```sh
109+[nix-shell:~] lua
110+```
111+
112+The other method, which is not recommended, does not create an environment and requires you to list the packages directly,
113+
114+```sh
115+$ nix-shell -p lua.pkgs.busted lua.pkgs.luafilesystem
116+```
117+Again, it is possible to launch the interpreter from the shell.
118+The Lua interpreter has the attribute `pkgs` which contains all Lua libraries for that specific interpreter.
119+
120+
121+## Developing with Lua {#developing-with-lua}
122+
123+Now that you know how to get a working Lua environment with Nix, it is time
124+to go forward and start actually developing with Lua. There are two ways to
125+package lua software, either it is on luarocks and most of it can be taken care
126+of by the luarocks2nix converter or the packaging has to be done manually.
127+Let's present the luarocks way first and the manual one in a second time.
128+
129+### Packaging a library on luarocks {#packaging-a-library-on-luarocks}
130+
131+[Luarocks.org](https://luarocks.org/) is the main repository of lua packages.
132+The site proposes two types of packages, the rockspec and the src.rock
133+(equivalent of a [rockspec](https://github.com/luarocks/luarocks/wiki/Rockspec-format) but with the source).
134+These packages can have different build types such as `cmake`, `builtin` etc .
135+
136+Luarocks-based packages are generated in pkgs/development/lua-modules/generated-packages.nix from
137+the whitelist maintainers/scripts/luarocks-packages.csv and updated by running maintainers/scripts/update-luarocks-packages.
138+
139+[luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
140+The automation only goes so far though and some packages need to be customized.
141+These customizations go in `pkgs/development/lua-modules/overrides.nix`.
142+For instance if the rockspec defines `external_dependencies`, these need to be manually added to the overrides.nix.
143+
144+You can try converting luarocks packages to nix packages with the command `nix-shell -p luarocks-nix` and then `luarocks nix PKG_NAME`.
145+
146+#### Packaging a library manually {#packaging-a-library-manually}
147+
148+You can develop your package as you usually would, just don't forget to wrap it
149+within a `toLuaModule` call, for instance
150+
151+```nix
152+mynewlib = toLuaModule ( stdenv.mkDerivation { ... });
153+```
154+
155+There is also the `buildLuaPackage` function that can be used when lua modules
156+are not packaged for luarocks. You can see a few examples at `pkgs/top-level/lua-packages.nix`.
157+
158+## Lua Reference {#lua-reference}
159+
160+### Lua interpreters {#lua-interpreters}
161+
162+Versions 5.1, 5.2, 5.3 and 5.4 of the lua interpreter are available as
163+respectively `lua5_1`, `lua5_2`, `lua5_3` and `lua5_4`. Luajit is available too.
164+The Nix expressions for the interpreters can be found in `pkgs/development/interpreters/lua-5`.
165+
166+#### Attributes on lua interpreters packages {#attributes-on-lua-interpreters-packages}
167+
168+Each interpreter has the following attributes:
169+
170+- `interpreter`. Alias for `${pkgs.lua}/bin/lua`.
171+- `buildEnv`. Function to build lua interpreter environments with extra packages bundled together. See section *lua.buildEnv function* for usage and documentation.
172+- `withPackages`. Simpler interface to `buildEnv`.
173+- `pkgs`. Set of Lua packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
174+
175+#### `buildLuarocksPackage` function {#buildluarockspackage-function}
176+
177+The `buildLuarocksPackage` function is implemented in `pkgs/development/interpreters/lua-5/build-lua-package.nix`
178+The following is an example:
179+```nix
180+luaposix = buildLuarocksPackage {
181+ pname = "luaposix";
182+ version = "34.0.4-1";
183+
184+ src = fetchurl {
185+ url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
186+ sha256 = "0yrm5cn2iyd0zjd4liyj27srphvy0gjrjx572swar6zqr4dwjqp2";
187+ };
188+ disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
189+ propagatedBuildInputs = [ bit32 lua std_normalize ];
190+
191+ meta = with lib; {
192+ homepage = "https://github.com/luaposix/luaposix/";
193+ description = "Lua bindings for POSIX";
194+ maintainers = with maintainers; [ vyp lblasc ];
195+ license.fullName = "MIT/X11";
196+ };
197+};
198+```
199+
200+The `buildLuarocksPackage` delegates most tasks to luarocks:
201+
202+* it adds `luarocks` as an unpacker for `src.rock` files (zip files really).
203+* configurePhase` writes a temporary luarocks configuration file which location
204+is exported via the environment variable `LUAROCKS_CONFIG`.
205+* the `buildPhase` does nothing.
206+* `installPhase` calls `luarocks make --deps-mode=none --tree $out` to build and
207+install the package
208+* In the `postFixup` phase, the `wrapLuaPrograms` bash function is called to
209+ wrap all programs in the `$out/bin/*` directory to include `$PATH`
210+ environment variable and add dependent libraries to script's `LUA_PATH` and
211+ `LUA_CPATH`.
212+
213+By default `meta.platforms` is set to the same value as the interpreter unless overridden otherwise.
214+
215+#### `buildLuaApplication` function {#buildluaapplication-function}
216+
217+The `buildLuaApplication` function is practically the same as `buildLuaPackage`.
218+The difference is that `buildLuaPackage` by default prefixes the names of the packages with the version of the interpreter.
219+Because with an application we're not interested in multiple version the prefix is dropped.
220+
221+#### lua.withPackages function {#lua.withpackages-function}
222+
223+The `lua.withPackages` takes a function as an argument that is passed the set of lua packages and returns the list of packages to be included in the environment.
224+Using the `withPackages` function, the previous example for the luafilesystem environment can be written like this:
225+
226+```nix
227+with import <nixpkgs> {};
228+
229+lua.withPackages (ps: [ps.luafilesystem])
230+```
231+
232+`withPackages` passes the correct package set for the specific interpreter version as an argument to the function. In the above example, `ps` equals `luaPackages`.
233+But you can also easily switch to using `lua5_2`:
234+
235+```nix
236+with import <nixpkgs> {};
237+
238+lua5_2.withPackages (ps: [ps.lua])
239+```
240+
241+Now, `ps` is set to `lua52Packages`, matching the version of the interpreter.
242+
243+### Possible Todos {#possible-todos}
244+
245+* export/use version specific variables such as `LUA_PATH_5_2`/`LUAROCKS_CONFIG_5_2`
246+* let luarocks check for dependencies via exporting the different rocktrees in temporary config
247+
248+### Lua Contributing guidelines {#lua-contributing-guidelines}
249+
250+Following rules should be respected:
251+
252+* Make sure libraries build for all Lua interpreters.
253+* Commit names of Lua libraries should reflect that they are Lua libraries, so write for example `luaPackages.luafilesystem: 1.11 -> 1.12`.
doc/languages-frameworks/lua.xmldeleted−48
@@ -1,48 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-lua">
4− <title>Lua</title>
5−
6− <para>
7− Lua packages are built by the <varname>buildLuaPackage</varname> function.
8− This function is implemented in
9− <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix">
10− <filename>pkgs/development/lua-modules/generic/default.nix</filename></link>
11− and works similarly to <varname>buildPerlPackage</varname>. (See
12− <xref linkend="sec-language-perl"/> for details.)
13− </para>
14−
15− <para>
16− Lua packages are defined in
17− <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>.
18− Most of them are simple. For example:
19−<programlisting>
20−fileSystem = buildLuaPackage {
21− name = "filesystem-1.6.2";
22− src = fetchurl {
23− url = "https://github.com/keplerproject/luafilesystem/archive/v1_6_2.tar.gz";
24− sha256 = "1n8qdwa20ypbrny99vhkmx8q04zd2jjycdb5196xdhgvqzk10abz";
25− };
26− meta = {
27− homepage = "https://github.com/keplerproject/luafilesystem";
28− hydraPlatforms = stdenv.lib.platforms.linux;
29− maintainers = with maintainers; [ flosse ];
30− };
31−};
32− </programlisting>
33− </para>
34−
35− <para>
36− Though, more complicated package should be placed in a seperate file in
37− <link
38− xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules"><filename>pkgs/development/lua-modules</filename></link>.
39− </para>
40−
41− <para>
42− Lua packages accept additional parameter <varname>disabled</varname>, which
43− defines the condition of disabling package from luaPackages. For example, if
44− package has <varname>disabled</varname> assigned to <literal>lua.luaversion
45− != "5.1"</literal>, it will not be included in any luaPackages except
46− lua51Packages, making it only be built for lua 5.1.
47− </para>
48−</section>
doc/languages-frameworks/maven.section.mdnew file+351
@@ -0,0 +1,351 @@
1+# Maven {#maven}
2+
3+Maven is a well-known build tool for the Java ecosystem however it has some challenges when integrating into the Nix build system.
4+
5+The following provides a list of common patterns with how to package a Maven project (or any JVM language that can export to Maven) as a Nix package.
6+
7+For the purposes of this example let's consider a very basic Maven project with the following `pom.xml` with a single dependency on [emoji-java](https://github.com/vdurmont/emoji-java).
8+
9+```xml
10+<?xml version="1.0" encoding="UTF-8"?>
11+<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
12+ xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
13+ <modelVersion>4.0.0</modelVersion>
14+ <groupId>io.github.fzakaria</groupId>
15+ <artifactId>maven-demo</artifactId>
16+ <version>1.0</version>
17+ <packaging>jar</packaging>
18+ <name>NixOS Maven Demo</name>
19+
20+ <dependencies>
21+ <dependency>
22+ <groupId>com.vdurmont</groupId>
23+ <artifactId>emoji-java</artifactId>
24+ <version>5.1.1</version>
25+ </dependency>
26+ </dependencies>
27+</project>
28+```
29+
30+Our main class file will be very simple:
31+
32+```java
33+import com.vdurmont.emoji.EmojiParser;
34+
35+public class Main {
36+ public static void main(String[] args) {
37+ String str = "NixOS :grinning: is super cool :smiley:!";
38+ String result = EmojiParser.parseToUnicode(str);
39+ System.out.println(result);
40+ }
41+}
42+```
43+
44+You find this demo project at https://github.com/fzakaria/nixos-maven-example
45+
46+## Solving for dependencies {#solving-for-dependencies}
47+
48+### buildMaven with NixOS/mvn2nix-maven-plugin {#buildmaven-with-nixosmvn2nix-maven-plugin}
49+
50+> ⚠️ Although `buildMaven` is the "blessed" way within nixpkgs, as of 2020, it hasn't seen much activity in quite a while.
51+
52+`buildMaven` is an alternative method that tries to follow similar patterns of other programming languages by generating a lock file. It relies on the maven plugin [mvn2nix-maven-plugin](https://github.com/NixOS/mvn2nix-maven-plugin).
53+
54+First you generate a `project-info.json` file using the maven plugin.
55+
56+> This should be executed in the project's source repository or be told which `pom.xml` to execute with.
57+
58+```bash
59+# run this step within the project's source repository
60+❯ mvn org.nixos.mvn2nix:mvn2nix-maven-plugin:mvn2nix
61+
62+❯ cat project-info.json | jq | head
63+{
64+ "project": {
65+ "artifactId": "maven-demo",
66+ "groupId": "org.nixos",
67+ "version": "1.0",
68+ "classifier": "",
69+ "extension": "jar",
70+ "dependencies": [
71+ {
72+ "artifactId": "maven-resources-plugin",
73+```
74+
75+This file is then given to the `buildMaven` function, and it returns 2 attributes.
76+
77+**`repo`**:
78+ A Maven repository that is a symlink farm of all the dependencies found in the `project-info.json`
79+
80+
81+**`build`**:
82+ A simple derivation that runs through `mvn compile` & `mvn package` to build the JAR. You may use this as inspiration for more complicated derivations.
83+
84+Here is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/build-maven-repository.nix) of building the Maven repository
85+
86+```nix
87+{ pkgs ? import <nixpkgs> { } }:
88+with pkgs;
89+(buildMaven ./project-info.json).repo
90+```
91+
92+The benefit over the _double invocation_ as we will see below, is that the _/nix/store_ entry is a _linkFarm_ of every package, so that changes to your dependency set doesn't involve downloading everything from scratch.
93+
94+```bash
95+❯ tree $(nix-build --no-out-link build-maven-repository.nix) | head
96+/nix/store/g87va52nkc8jzbmi1aqdcf2f109r4dvn-maven-repository
97+├── antlr
98+│ └── antlr
99+│ └── 2.7.2
100+│ ├── antlr-2.7.2.jar -> /nix/store/d027c8f2cnmj5yrynpbq2s6wmc9cb559-antlr-2.7.2.jar
101+│ └── antlr-2.7.2.pom -> /nix/store/mv42fc5gizl8h5g5vpywz1nfiynmzgp2-antlr-2.7.2.pom
102+├── avalon-framework
103+│ └── avalon-framework
104+│ └── 4.1.3
105+│ ├── avalon-framework-4.1.3.jar -> /nix/store/iv5fp3955w3nq28ff9xfz86wvxbiw6n9-avalon-framework-4.1.3.jar
106+```
107+
108+### Double Invocation {#double-invocation}
109+
110+> ⚠️ This pattern is the simplest but may cause unnecessary rebuilds due to the output hash changing.
111+
112+The double invocation is a _simple_ way to get around the problem that `nix-build` may be sandboxed and have no Internet connectivity.
113+
114+It treats the entire Maven repository as a single source to be downloaded, relying on Maven's dependency resolution to satisfy the output hash. This is similar to fetchers like `fetchgit`, except it has to run a Maven build to determine what to download.
115+
116+The first step will be to build the Maven project as a fixed-output derivation in order to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
117+
118+> Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
119+
120+```nix
121+{ lib, stdenv, maven }:
122+stdenv.mkDerivation {
123+ name = "maven-repository";
124+ buildInputs = [ maven ];
125+ src = ./.; # or fetchFromGitHub, cleanSourceWith, etc
126+ buildPhase = ''
127+ mvn package -Dmaven.repo.local=$out
128+ '';
129+
130+ # keep only *.{pom,jar,sha1,nbm} and delete all ephemeral files with lastModified timestamps inside
131+ installPhase = ''
132+ find $out -type f \
133+ -name \*.lastUpdated -or \
134+ -name resolver-status.properties -or \
135+ -name _remote.repositories \
136+ -delete
137+ '';
138+
139+ # don't do any fixup
140+ dontFixup = true;
141+ outputHashAlgo = "sha256";
142+ outputHashMode = "recursive";
143+ # replace this with the correct SHA256
144+ outputHash = lib.fakeSha256;
145+}
146+```
147+
148+The build will fail, and tell you the expected `outputHash` to place. When you've set the hash, the build will return with a `/nix/store` entry whose contents are the full Maven repository.
149+
150+> Some additional files are deleted that would cause the output hash to change potentially on subsequent runs.
151+
152+```bash
153+❯ tree $(nix-build --no-out-link double-invocation-repository.nix) | head
154+/nix/store/8kicxzp98j68xyi9gl6jda67hp3c54fq-maven-repository
155+├── backport-util-concurrent
156+│ └── backport-util-concurrent
157+│ └── 3.1
158+│ ├── backport-util-concurrent-3.1.pom
159+│ └── backport-util-concurrent-3.1.pom.sha1
160+├── classworlds
161+│ └── classworlds
162+│ ├── 1.1
163+│ │ ├── classworlds-1.1.jar
164+```
165+
166+If your package uses _SNAPSHOT_ dependencies or _version ranges_; there is a strong likelihood that over-time your output hash will change since the resolved dependencies may change. Hence this method is less recommended then using `buildMaven`.
167+
168+## Building a JAR {#building-a-jar}
169+
170+Regardless of which strategy is chosen above, the step to build the derivation is the same.
171+
172+```nix
173+{ stdenv, maven, callPackage }:
174+# pick a repository derivation, here we will use buildMaven
175+let repository = callPackage ./build-maven-repository.nix { };
176+in stdenv.mkDerivation rec {
177+ pname = "maven-demo";
178+ version = "1.0";
179+
180+ src = builtins.fetchTarball "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
181+ buildInputs = [ maven ];
182+
183+ buildPhase = ''
184+ echo "Using repository ${repository}"
185+ mvn --offline -Dmaven.repo.local=${repository} package;
186+ '';
187+
188+ installPhase = ''
189+ install -Dm644 target/${pname}-${version}.jar $out/share/java
190+ '';
191+}
192+```
193+
194+> We place the library in `$out/share/java` since JDK package has a _stdenv setup hook_ that adds any JARs in the `share/java` directories of the build inputs to the CLASSPATH environment.
195+
196+```bash
197+❯ tree $(nix-build --no-out-link build-jar.nix)
198+/nix/store/7jw3xdfagkc2vw8wrsdv68qpsnrxgvky-maven-demo-1.0
199+└── share
200+ └── java
201+ └── maven-demo-1.0.jar
202+
203+2 directories, 1 file
204+```
205+
206+## Runnable JAR {#runnable-jar}
207+
208+The previous example builds a `jar` file but that's not a file one can run.
209+
210+You need to use it with `java -jar $out/share/java/output.jar` and make sure to provide the required dependencies on the classpath.
211+
212+The following explains how to use `makeWrapper` in order to make the derivation produce an executable that will run the JAR file you created.
213+
214+We will use the same repository we built above (either _double invocation_ or _buildMaven_) to setup a CLASSPATH for our JAR.
215+
216+The following two methods are more suited to Nix then building an [UberJar](https://imagej.net/Uber-JAR) which may be the more traditional approach.
217+
218+### CLASSPATH {#classpath}
219+
220+> This is ideal if you are providing a derivation for _nixpkgs_ and don't want to patch the project's `pom.xml`.
221+
222+We will read the Maven repository and flatten it to a single list. This list will then be concatenated with the _CLASSPATH_ separator to create the full classpath.
223+
224+We make sure to provide this classpath to the `makeWrapper`.
225+
226+```nix
227+{ stdenv, maven, callPackage, makeWrapper, jre }:
228+let
229+ repository = callPackage ./build-maven-repository.nix { };
230+in stdenv.mkDerivation rec {
231+ pname = "maven-demo";
232+ version = "1.0";
233+
234+ src = builtins.fetchTarball
235+ "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
236+ buildInputs = [ maven makeWrapper ];
237+
238+ buildPhase = ''
239+ echo "Using repository ${repository}"
240+ mvn --offline -Dmaven.repo.local=${repository} package;
241+ '';
242+
243+ installPhase = ''
244+ mkdir -p $out/bin
245+
246+ classpath=$(find ${repository} -name "*.jar" -printf ':%h/%f');
247+ install -Dm644 target/${pname}-${version}.jar $out/share/java
248+ # create a wrapper that will automatically set the classpath
249+ # this should be the paths from the dependency derivation
250+ makeWrapper ${jre}/bin/java $out/bin/${pname} \
251+ --add-flags "-classpath $out/share/java/${pname}-${version}.jar:''${classpath#:}" \
252+ --add-flags "Main"
253+ '';
254+}
255+```
256+
257+### MANIFEST file via Maven Plugin {#manifest-file-via-maven-plugin}
258+
259+> This is ideal if you are the project owner and want to change your `pom.xml` to set the CLASSPATH within it.
260+
261+Augment the `pom.xml` to create a JAR with the following manifest:
262+
263+```xml
264+<build>
265+ <plugins>
266+ <plugin>
267+ <artifactId>maven-jar-plugin</artifactId>
268+ <configuration>
269+ <archive>
270+ <manifest>
271+ <addClasspath>true</addClasspath>
272+ <classpathPrefix>../../repository/</classpathPrefix>
273+ <classpathLayoutType>repository</classpathLayoutType>
274+ <mainClass>Main</mainClass>
275+ </manifest>
276+ <manifestEntries>
277+ <Class-Path>.</Class-Path>
278+ </manifestEntries>
279+ </archive>
280+ </configuration>
281+ </plugin>
282+ </plugins>
283+</build>
284+```
285+
286+The above plugin instructs the JAR to look for the necessary dependencies in the `lib/` relative folder. The layout of the folder is also in the _maven repository_ style.
287+
288+```bash
289+❯ unzip -q -c $(nix-build --no-out-link runnable-jar.nix)/share/java/maven-demo-1.0.jar META-INF/MANIFEST.MF
290+
291+Manifest-Version: 1.0
292+Archiver-Version: Plexus Archiver
293+Built-By: nixbld
294+Class-Path: . ../../repository/com/vdurmont/emoji-java/5.1.1/emoji-jav
295+ a-5.1.1.jar ../../repository/org/json/json/20170516/json-20170516.jar
296+Created-By: Apache Maven 3.6.3
297+Build-Jdk: 1.8.0_265
298+Main-Class: Main
299+```
300+
301+We will modify the derivation above to add a symlink to our repository so that it's accessible to our JAR during the `installPhase`.
302+
303+```nix
304+{ stdenv, maven, callPackage, makeWrapper, jre }:
305+# pick a repository derivation, here we will use buildMaven
306+let repository = callPackage ./build-maven-repository.nix { };
307+in stdenv.mkDerivation rec {
308+ pname = "maven-demo";
309+ version = "1.0";
310+
311+ src = builtins.fetchTarball
312+ "https://github.com/fzakaria/nixos-maven-example/archive/main.tar.gz";
313+ buildInputs = [ maven makeWrapper ];
314+
315+ buildPhase = ''
316+ echo "Using repository ${repository}"
317+ mvn --offline -Dmaven.repo.local=${repository} package;
318+ '';
319+
320+ installPhase = ''
321+ mkdir -p $out/bin
322+
323+ # create a symbolic link for the repository directory
324+ ln -s ${repository} $out/repository
325+
326+ install -Dm644 target/${pname}-${version}.jar $out/share/java
327+ # create a wrapper that will automatically set the classpath
328+ # this should be the paths from the dependency derivation
329+ makeWrapper ${jre}/bin/java $out/bin/${pname} \
330+ --add-flags "-jar $out/share/java/${pname}-${version}.jar"
331+ '';
332+}
333+```
334+
335+> Our script produces a dependency on `jre` rather than `jdk` to restrict the runtime closure necessary to run the application.
336+
337+This will give you an executable shell-script that launches your JAR with all the dependencies available.
338+
339+```bash
340+❯ tree $(nix-build --no-out-link runnable-jar.nix)
341+/nix/store/8d4c3ibw8ynsn01ibhyqmc1zhzz75s26-maven-demo-1.0
342+├── bin
343+│ └── maven-demo
344+├── repository -> /nix/store/g87va52nkc8jzbmi1aqdcf2f109r4dvn-maven-repository
345+└── share
346+ └── java
347+ └── maven-demo-1.0.jar
348+
349+❯ $(nix-build --no-out-link --option tarball-ttl 1 runnable-jar.nix)/bin/maven-demo
350+NixOS 😀 is super cool 😃!
351+```
doc/languages-frameworks/nim.section.mdnew file+91
@@ -0,0 +1,91 @@
1+# Nim {#nim}
2+
3+## Overview {#nim-overview}
4+
5+The Nim compiler, a builder function, and some packaged libraries are available
6+in Nixpkgs. Until now each compiler release has been effectively backwards
7+compatible so only the latest version is available.
8+
9+## Nim program packages in Nixpkgs {#nim-program-packages-in-nixpkgs}
10+
11+Nim programs can be built using `nimPackages.buildNimPackage`. In the
12+case of packages not containing exported library code the attribute
13+`nimBinOnly` should be set to `true`.
14+
15+The following example shows a Nim program that depends only on Nim libraries:
16+
17+```nix
18+{ lib, nimPackages, fetchurl }:
19+
20+nimPackages.buildNimPackage rec {
21+ pname = "hottext";
22+ version = "1.4";
23+
24+ nimBinOnly = true;
25+
26+ src = fetchurl {
27+ url = "https://git.sr.ht/~ehmry/hottext/archive/v${version}.tar.gz";
28+ sha256 = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
29+ };
30+
31+ buildInputs = with nimPackages; [
32+ bumpy
33+ chroma
34+ flatty
35+ nimsimd
36+ pixie
37+ sdl2
38+ typography
39+ vmath
40+ zippy
41+ ];
42+}
43+
44+```
45+
46+## Nim library packages in Nixpkgs {#nim-library-packages-in-nixpkgs}
47+
48+
49+Nim libraries can also be built using `nimPackages.buildNimPackage`, but
50+often the product of a fetcher is sufficient to satisfy a dependency.
51+The `fetchgit`, `fetchFromGitHub`, and `fetchNimble` functions yield an
52+output that can be discovered during the `configurePhase` of `buildNimPackage`.
53+
54+Nim library packages are listed in
55+[pkgs/top-level/nim-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/nim-packages.nix) and implemented at
56+[pkgs/development/nim-packages](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/nim-packages).
57+
58+The following example shows a Nim library that propagates a dependency on a
59+non-Nim package:
60+```nix
61+{ lib, buildNimPackage, fetchNimble, SDL2 }:
62+
63+buildNimPackage rec {
64+ pname = "sdl2";
65+ version = "2.0.4";
66+ src = fetchNimble {
67+ inherit pname version;
68+ hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
69+ };
70+ propagatedBuildInputs = [ SDL2 ];
71+}
72+```
73+
74+## `buildNimPackage` parameters {#buildnimpackage-parameters}
75+
76+All parameters from `stdenv.mkDerivation` function are still supported. The
77+following are specific to `buildNimPackage`:
78+
79+* `nimBinOnly ? false`: If `true` then build only the programs listed in
80+ the Nimble file in the packages sources.
81+* `nimbleFile`: Specify the Nimble file location of the package being built
82+ rather than discover the file at build-time.
83+* `nimRelease ? true`: Build the package in *release* mode.
84+* `nimDefines ? []`: A list of Nim defines. Key-value tuples are not supported.
85+* `nimFlags ? []`: A list of command line arguments to pass to the Nim compiler.
86+ Use this to specify defines with arguments in the form of `-d:${name}=${value}`.
87+* `nimDoc` ? false`: Build and install HTML documentation.
88+
89+* `buildInputs` ? []: The packages listed here will be searched for `*.nimble`
90+ files which are used to populate the Nim library path. Otherwise the standard
91+ behavior is in effect.
doc/languages-frameworks/node.section.mddeleted−51
@@ -1,51 +0,0 @@
1−Node.js packages
2−================
3−The `pkgs/development/node-packages` folder contains a generated collection of
4−[NPM packages](https://npmjs.com/) that can be installed with the Nix package
5−manager.
6−
7−As a rule of thumb, the package set should only provide *end user* software
8−packages, such as command-line utilities. Libraries should only be added to the
9−package set if there is a non-NPM package that requires it.
10−
11−When it is desired to use NPM libraries in a development project, use the
12−`node2nix` generator directly on the `package.json` configuration file of the
13−project.
14−
15−The package set also provides support for multiple Node.js versions. The policy
16−is that a new package should be added to the collection for the latest stable LTS
17−release (which is currently 10.x), unless there is an explicit reason to support
18−a different release.
19−
20−If your package uses native addons, you need to examine what kind of native
21−build system it uses. Here are some examples:
22−
23−* `node-gyp`
24−* `node-gyp-builder`
25−* `node-pre-gyp`
26−
27−After you have identified the correct system, you need to override your package
28−expression while adding in build system as a build input. For example, `dat`
29−requires `node-gyp-build`, so we override its expression in `default-v10.nix`:
30−
31−```nix
32−dat = nodePackages.dat.override (oldAttrs: {
33− buildInputs = oldAttrs.buildInputs ++ [ nodePackages.node-gyp-build ];
34−});
35−```
36−
37−To add a package from NPM to nixpkgs:
38−
39− 1. Modify `pkgs/development/node-packages/node-packages-v10.json` to add, update
40− or remove package entries. (Or `pkgs/development/node-packages/node-packages-v8.json`
41− for packages depending on Node.js 8.x)
42− 2. Run the script: `(cd pkgs/development/node-packages && ./generate.sh)`.
43− 3. Build your new package to test your changes:
44− `cd /path/to/nixpkgs && nix-build -A nodePackages.<new-or-updated-package>`.
45− To build against a specific Node.js version (e.g. 10.x):
46− `nix-build -A nodePackages_10_x.<new-or-updated-package>`
47− 4. Add and commit all modified and generated files.
48−
49−For more information about the generation process, consult the
50−[README.md](https://github.com/svanderburg/node2nix) file of the `node2nix`
51−tool.
doc/languages-frameworks/ocaml.section.mdnew file+131
@@ -0,0 +1,131 @@
1+# OCaml {#sec-language-ocaml}
2+
3+## User guide {#sec-language-ocaml-user-guide}
4+
5+OCaml libraries are available in attribute sets of the form `ocaml-ng.ocamlPackages_X_XX` where X is to be replaced with the desired compiler version. For example, ocamlgraph compiled with OCaml 4.12 can be found in `ocaml-ng.ocamlPackages_4_12.ocamlgraph`. The compiler itself is also located in this set, under the name `ocaml`.
6+
7+If you don't care about the exact compiler version, `ocamlPackages` is a top-level alias pointing to a recent version of OCaml.
8+
9+OCaml applications are usually available top-level, and not inside `ocamlPackages`. Notable exceptions are build tools that must be built with the same compiler version as the compiler you intend to use like `dune` or `ocaml-lsp`.
10+
11+To open a shell able to build a typical OCaml project, put the dependencies in `buildInputs` and add `ocamlPackages.ocaml` and `ocamlPackages.findlib` to `nativeBuildInputs` at least.
12+For example:
13+```nix
14+let
15+ pkgs = import <nixpkgs> {};
16+ # choose the ocaml version you want to use
17+ ocamlPackages = pkgs.ocaml-ng.ocamlPackages_4_12;
18+in
19+pkgs.mkShell {
20+ # build tools
21+ nativeBuildInputs = with ocamlPackages; [ ocaml findlib dune_2 ocaml-lsp ];
22+ # dependencies
23+ buildInputs = with ocamlPackages; [ ocamlgraph ];
24+}
25+```
26+
27+## Packaging guide {#sec-language-ocaml-packaging}
28+
29+OCaml libraries should be installed in `$(out)/lib/ocaml/${ocaml.version}/site-lib/`. Such directories are automatically added to the `$OCAMLPATH` environment variable when building another package that depends on them or when opening a `nix-shell`.
30+
31+Given that most of the OCaml ecosystem is now built with dune, nixpkgs includes a convenience build support function called `buildDunePackage` that will build an OCaml package using dune, OCaml and findlib and any additional dependencies provided as `buildInputs` or `propagatedBuildInputs`.
32+
33+Here is a simple package example.
34+
35+- It defines an (optional) attribute `minimalOCamlVersion` (see note below)
36+ that will be used to throw a descriptive evaluation error if building with
37+ an older OCaml is attempted.
38+
39+- It uses the `fetchFromGitHub` fetcher to get its source.
40+
41+- `duneVersion = "2"` ensures that Dune version 2 is used for the
42+ build (this is the default; valid values are `"1"`, `"2"`, and `"3"`);
43+ note that there is also a legacy `useDune2` boolean attribute:
44+ set to `false` it corresponds to `duneVersion = "1"`; set to `true` it
45+ corresponds to `duneVersion = "2"`. If both arguments (`duneVersion` and
46+ `useDune2`) are given, the second one (`useDune2`) is silently ignored.
47+
48+- It sets the optional `doCheck` attribute such that tests will be run with
49+ `dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
50+ complete, but only if the Ocaml version is at at least `"4.05"`.
51+
52+- It uses the package `ocaml-syntax-shims` as a build input, `alcotest` and
53+ `ppx_let` as check inputs (because they are needed to run the tests), and
54+ `bigstringaf` and `result` as propagated build inputs (thus they will also be
55+ available to libraries depending on this library).
56+
57+- The library will be installed using the `angstrom.install` file that dune
58+ generates.
59+
60+```nix
61+{ lib,
62+ fetchFromGitHub,
63+ buildDunePackage,
64+ ocaml,
65+ ocaml-syntax-shims,
66+ alcotest,
67+ result,
68+ bigstringaf,
69+ ppx_let }:
70+
71+buildDunePackage rec {
72+ pname = "angstrom";
73+ version = "0.15.0";
74+ duneVersion = "2";
75+
76+ minimalOCamlVersion = "4.04";
77+
78+ src = fetchFromGitHub {
79+ owner = "inhabitedtype";
80+ repo = pname;
81+ rev = version;
82+ sha256 = "1hmrkdcdlkwy7rxhngf3cv3sa61cznnd9p5lmqhx20664gx2ibrh";
83+ };
84+
85+ checkInputs = [ alcotest ppx_let ];
86+ buildInputs = [ ocaml-syntax-shims ];
87+ propagatedBuildInputs = [ bigstringaf result ];
88+ doCheck = lib.versionAtLeast ocaml.version "4.05";
89+
90+ meta = {
91+ homepage = "https://github.com/inhabitedtype/angstrom";
92+ description = "OCaml parser combinators built for speed and memory efficiency";
93+ license = lib.licenses.bsd3;
94+ maintainers = with lib.maintainers; [ sternenseemann ];
95+ };
96+```
97+
98+Here is a second example, this time using a source archive generated with `dune-release`. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a `%%VERSION%%` field. This library does not depend on any other OCaml library and no tests are run after building it.
99+
100+```nix
101+{ lib, fetchurl, buildDunePackage }:
102+
103+buildDunePackage rec {
104+ pname = "wtf8";
105+ version = "1.0.2";
106+
107+ useDune2 = true;
108+
109+ minimalOCamlVersion = "4.02";
110+
111+ src = fetchurl {
112+ url = "https://github.com/flowtype/ocaml-${pname}/releases/download/v${version}/${pname}-v${version}.tbz";
113+ sha256 = "09ygcxxd5warkdzz17rgpidrd0pg14cy2svvnvy1hna080lzg7vp";
114+ };
115+
116+ meta = with lib; {
117+ homepage = "https://github.com/flowtype/ocaml-wtf8";
118+ description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
119+ license = licenses.mit;
120+ maintainers = [ maintainers.eqyiel ];
121+ };
122+}
123+```
124+
125+Note about `minimalOCamlVersion`. A deprecated version of this argument was
126+spelled `minimumOCamlVersion`; setting the old attribute wrongly modifies the
127+derivation hash and is therefore inappropriate. As a technical dept, currently
128+packaged libraries may still use the old spelling: maintainers are invited to
129+fix this when updating packages. Massive renaming is strongly discouraged as it
130+would be challenging to review, difficult to test, and will cause unnecessary
131+rebuild.
doc/languages-frameworks/ocaml.xmldeleted−99
@@ -1,99 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-ocaml">
4− <title>OCaml</title>
5−
6− <para>
7− OCaml libraries should be installed in
8− <literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such
9− directories are automatically added to the <literal>$OCAMLPATH</literal>
10− environment variable when building another package that depends on them
11− or when opening a <literal>nix-shell</literal>.
12− </para>
13−
14− <para>
15− Given that most of the OCaml ecosystem is now built with dune,
16− nixpkgs includes a convenience build support function called
17− <literal>buildDunePackage</literal> that will build an OCaml package
18− using dune, OCaml and findlib and any additional dependencies provided
19− as <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
20− </para>
21−
22− <para>
23− Here is a simple package example. It defines an (optional) attribute
24− <literal>minimumOCamlVersion</literal> that will be used to throw a
25− descriptive evaluation error if building with an older OCaml is attempted.
26− It uses the <literal>fetchFromGitHub</literal> fetcher to get its source.
27− It sets the <literal>doCheck</literal> (optional) attribute to
28− <literal>true</literal> which means that tests will be run with
29− <literal>dune runtest -p angstrom</literal> after the build
30− (<literal>dune build -p angstrom</literal>) is complete.
31− It uses <literal>alcotest</literal> as a build input (because it is needed
32− to run the tests) and <literal>bigstringaf</literal> and
33− <literal>result</literal> as propagated build inputs (thus they will also
34− be available to libraries depending on this library).
35− The library will be installed using the <literal>angstrom.install</literal>
36− file that dune generates.
37− </para>
38−
39− <programlisting>
40−{ stdenv, fetchFromGitHub, buildDunePackage, alcotest, result, bigstringaf }:
41−
42−buildDunePackage rec {
43− pname = "angstrom";
44− version = "0.10.0";
45−
46− minimumOCamlVersion = "4.03";
47−
48− src = fetchFromGitHub {
49− owner = "inhabitedtype";
50− repo = pname;
51− rev = version;
52− sha256 = "0lh6024yf9ds0nh9i93r9m6p5psi8nvrqxl5x7jwl13zb0r9xfpw";
53− };
54−
55− buildInputs = [ alcotest ];
56− propagatedBuildInputs = [ bigstringaf result ];
57− doCheck = true;
58−
59− meta = {
60− homepage = https://github.com/inhabitedtype/angstrom;
61− description = "OCaml parser combinators built for speed and memory efficiency";
62− license = stdenv.lib.licenses.bsd3;
63− maintainers = with stdenv.lib.maintainers; [ sternenseemann ];
64− };
65−}
66− </programlisting>
67−
68− <para>
69− Here is a second example, this time using a source archive generated with
70− <literal>dune-release</literal>. It is a good idea to use this archive when
71− it is available as it will usually contain substituted variables such as a
72− <literal>%%VERSION%%</literal> field. This library does not depend
73− on any other OCaml library and no tests are run after building it.
74− </para>
75−
76− <programlisting>
77−{ stdenv, fetchurl, buildDunePackage }:
78−
79−buildDunePackage rec {
80− pname = "wtf8";
81− version = "1.0.1";
82−
83− minimumOCamlVersion = "4.01";
84−
85− src = fetchurl {
86− url = "https://github.com/flowtype/ocaml-${pname}/releases/download/v${version}/${pname}-${version}.tbz";
87− sha256 = "1msg3vycd3k8qqj61sc23qks541cxpb97vrnrvrhjnqxsqnh6ygq";
88− };
89−
90− meta = with stdenv.lib; {
91− homepage = https://github.com/flowtype/ocaml-wtf8;
92− description = "WTF-8 is a superset of UTF-8 that allows unpaired surrogates.";
93− license = licenses.mit;
94− maintainers = [ maintainers.eqyiel ];
95− };
96−}
97− </programlisting>
98−
99−</section>
doc/languages-frameworks/octave.section.mdnew file+92
@@ -0,0 +1,92 @@
1+# Octave {#sec-octave}
2+
3+## Introduction {#ssec-octave-introduction}
4+
5+Octave is a modular scientific programming language and environment.
6+A majority of the packages supported by Octave from their [website](https://octave.sourceforge.io/packages.php) are packaged in nixpkgs.
7+
8+## Structure {#ssec-octave-structure}
9+
10+All Octave add-on packages are available in two ways:
11+1. Under the top-level `Octave` attribute, `octave.pkgs`.
12+2. As a top-level attribute, `octavePackages`.
13+
14+## Packaging Octave Packages {#ssec-octave-packaging}
15+
16+Nixpkgs provides a function `buildOctavePackage`, a generic package builder function for any Octave package that complies with the Octave's current packaging format.
17+
18+All Octave packages are defined in [pkgs/top-level/octave-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/octave-packages.nix) rather than `pkgs/all-packages.nix`.
19+Each package is defined in their own file in the [pkgs/development/octave-modules](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules) directory.
20+Octave packages are made available through `all-packages.nix` through both the attribute `octavePackages` and `octave.pkgs`.
21+You can test building an Octave package as follows:
22+
23+```ShellSession
24+$ nix-build -A octavePackages.symbolic
25+```
26+
27+To install it into your user profile, run this command from the root of the repository:
28+
29+```ShellSession
30+$ nix-env -f. -iA octavePackages.symbolic
31+```
32+
33+You can build Octave with packages by using the `withPackages` passed-through function.
34+
35+```ShellSession
36+$ nix-shell -p 'octave.withPackages (ps: with ps; [ symbolic ])'
37+```
38+
39+This will also work in a `shell.nix` file.
40+
41+```nix
42+{ pkgs ? import <nixpkgs> { }}:
43+
44+pkgs.mkShell {
45+ nativeBuildInputs = with pkgs; [
46+ (octave.withPackages (opkgs: with opkgs; [ symbolic ]))
47+ ];
48+}
49+```
50+
51+### `buildOctavePackage` Steps {#sssec-buildOctavePackage-steps}
52+
53+The `buildOctavePackage` does several things to make sure things work properly.
54+
55+1. Sets the environment variable `OCTAVE_HISTFILE` to `/dev/null` during package compilation so that the commands run through the Octave interpreter directly are not logged.
56+2. Skips the configuration step, because the packages are stored as gzipped tarballs, which Octave itself handles directly.
57+3. Change the hierarchy of the tarball so that only a single directory is at the top-most level of the tarball.
58+4. Use Octave itself to run the `pkg build` command, which unzips the tarball, extracts the necessary files written in Octave, and compiles any code written in C++ or Fortran, and places the fully compiled artifact in `$out`.
59+
60+`buildOctavePackage` is built on top of `stdenv` in a standard way, allowing most things to be customized.
61+
62+### Handling Dependencies {#sssec-octave-handling-dependencies}
63+
64+In Octave packages, there are four sets of dependencies that can be specified:
65+
66+`nativeBuildInputs`
67+: Just like other packages, `nativeBuildInputs` is intended for architecture-dependent build-time-only dependencies.
68+
69+`buildInputs`
70+: Like other packages, `buildInputs` is intended for architecture-independent build-time-only dependencies.
71+
72+`propagatedBuildInputs`
73+: Similar to other packages, `propagatedBuildInputs` is intended for packages that are required for both building and running of the package.
74+See [Symbolic](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/octave-modules/symbolic/default.nix) for how this works and why it is needed.
75+
76+`requiredOctavePackages`
77+: This is a special dependency that ensures the specified Octave packages are dependent on others, and are made available simultaneously when loading them in Octave.
78+
79+### Installing Octave Packages {#sssec-installing-octave-packages}
80+
81+By default, the `buildOctavePackage` function does _not_ install the requested package into Octave for use.
82+The function will only build the requested package.
83+This is due to Octave maintaining an text-based database about which packages are installed where.
84+To this end, when all the requested packages have been built, the Octave package and all its add-on packages are put together into an environment, similar to Python.
85+
86+1. First, all the Octave binaries are wrapped with the environment variable `OCTAVE_SITE_INITFILE` set to a file in `$out`, which is required for Octave to be able to find the non-standard package database location.
87+2. Because of the way `buildEnv` works, all tarballs that are present (which should be all Octave packages to install) should be removed.
88+3. The path down to the default install location of Octave packages is recreated so that Nix-operated Octave can install the packages.
89+4. Install the packages into the `$out` environment while writing package entries to the database file.
90+This database file is unique for each different (according to Nix) environment invocation.
91+5. Rewrite the Octave-wide startup file to read from the list of packages installed in that particular environment.
92+6. Wrap any programs that are required by the Octave packages so that they work with all the paths defined within the environment.
doc/languages-frameworks/perl.section.mdnew file+159
@@ -0,0 +1,159 @@
1+# Perl {#sec-language-perl}
2+
3+## Running perl programs on the shell {#ssec-perl-running}
4+
5+When executing a Perl script, it is possible you get an error such as `./myscript.pl: bad interpreter: /usr/bin/perl: no such file or directory`. This happens when the script expects Perl to be installed at `/usr/bin/perl`, which is not the case when using Perl from nixpkgs. You can fix the script by changing the first line to:
6+
7+```perl
8+#!/usr/bin/env perl
9+```
10+
11+to take the Perl installation from the `PATH` environment variable, or invoke Perl directly with:
12+
13+```ShellSession
14+$ perl ./myscript.pl
15+```
16+
17+When the script is using a Perl library that is not installed globally, you might get an error such as `Can't locate DB_File.pm in @INC (you may need to install the DB_File module)`. In that case, you can use `nix-shell` to start an ad-hoc shell with that library installed, for instance:
18+
19+```ShellSession
20+$ nix-shell -p perl perlPackages.DBFile --run ./myscript.pl
21+```
22+
23+If you are always using the script in places where `nix-shell` is available, you can embed the `nix-shell` invocation in the shebang like this:
24+
25+```perl
26+#!/usr/bin/env nix-shell
27+#! nix-shell -i perl -p perl perlPackages.DBFile
28+```
29+
30+## Packaging Perl programs {#ssec-perl-packaging}
31+
32+Nixpkgs provides a function `buildPerlPackage`, a generic package builder function for any Perl package that has a standard `Makefile.PL`. It’s implemented in [pkgs/development/perl-modules/generic](https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/perl-modules/generic).
33+
34+Perl packages from CPAN are defined in [pkgs/top-level/perl-packages.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix) rather than `pkgs/all-packages.nix`. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from `perl-packages.nix`. However, more complicated packages should be put in a separate file, typically in `pkgs/development/perl-modules`. Here is an example of the former:
35+
36+```nix
37+ClassC3 = buildPerlPackage rec {
38+ name = "Class-C3-0.21";
39+ src = fetchurl {
40+ url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
41+ sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
42+ };
43+};
44+```
45+
46+Note the use of `mirror://cpan/`, and the `${name}` in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in `all-packages.nix` through the variable `perlPackages`. For instance, if you have a package that needs `ClassC3`, you would typically write
47+
48+```nix
49+foo = import ../path/to/foo.nix {
50+ inherit stdenv fetchurl ...;
51+ inherit (perlPackages) ClassC3;
52+};
53+```
54+
55+in `all-packages.nix`. You can test building a Perl package as follows:
56+
57+```ShellSession
58+$ nix-build -A perlPackages.ClassC3
59+```
60+
61+To install it with `nix-env` instead: `nix-env -f. -iA perlPackages.ClassC3`.
62+
63+So what does `buildPerlPackage` do? It does the following:
64+
65+1. In the configure phase, it calls `perl Makefile.PL` to generate a Makefile. You can set the variable `makeMakerFlags` to pass flags to `Makefile.PL`
66+2. It adds the contents of the `PERL5LIB` environment variable to `#! .../bin/perl` line of Perl scripts as `-Idir` flags. This ensures that a script can find its dependencies. (This can cause this shebang line to become too long for Darwin to handle; see the note below.)
67+3. In the fixup phase, it writes the propagated build inputs (`propagatedBuildInputs`) to the file `$out/nix-support/propagated-user-env-packages`. `nix-env` recursively installs all packages listed in this file when you install a package that has it. This ensures that a Perl package can find its dependencies.
68+
69+`buildPerlPackage` is built on top of `stdenv`, so everything can be customised in the usual way. For instance, the `BerkeleyDB` module has a `preConfigure` hook to generate a configuration file used by `Makefile.PL`:
70+
71+```nix
72+{ buildPerlPackage, fetchurl, db }:
73+
74+buildPerlPackage rec {
75+ name = "BerkeleyDB-0.36";
76+
77+ src = fetchurl {
78+ url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
79+ sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
80+ };
81+
82+ preConfigure = ''
83+ echo "LIB = ${db.out}/lib" > config.in
84+ echo "INCLUDE = ${db.dev}/include" >> config.in
85+ '';
86+}
87+```
88+
89+Dependencies on other Perl packages can be specified in the `buildInputs` and `propagatedBuildInputs` attributes. If something is exclusively a build-time dependency, use `buildInputs`; if it’s (also) a runtime dependency, use `propagatedBuildInputs`. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
90+
91+```nix
92+ClassC3Componentised = buildPerlPackage rec {
93+ name = "Class-C3-Componentised-1.0004";
94+ src = fetchurl {
95+ url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
96+ sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
97+ };
98+ propagatedBuildInputs = [
99+ ClassC3 ClassInspector TestException MROCompat
100+ ];
101+};
102+```
103+
104+On Darwin, if a script has too many `-Idir` flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the `shortenPerlShebang` function from the `postInstall` phase:
105+
106+```nix
107+{ lib, stdenv, buildPerlPackage, fetchurl, shortenPerlShebang }:
108+
109+ImageExifTool = buildPerlPackage {
110+ pname = "Image-ExifTool";
111+ version = "11.50";
112+
113+ src = fetchurl {
114+ url = "https://www.sno.phy.queensu.ca/~phil/exiftool/Image-ExifTool-11.50.tar.gz";
115+ sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
116+ };
117+
118+ buildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
119+ postInstall = lib.optionalString stdenv.isDarwin ''
120+ shortenPerlShebang $out/bin/exiftool
121+ '';
122+};
123+```
124+
125+This will remove the `-I` flags from the shebang line, rewrite them in the `use lib` form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
126+
127+### Generation from CPAN {#ssec-generation-from-CPAN}
128+
129+Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program `nix-generate-from-cpan`, which can be installed as follows:
130+
131+```ShellSession
132+$ nix-env -f "<nixpkgs>" -iA nix-generate-from-cpan
133+```
134+
135+Substitute `<nixpkgs>` by the path of a nixpkgs clone to use the latest version.
136+
137+This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
138+
139+```ShellSession
140+$ nix-generate-from-cpan XML::Simple
141+ XMLSimple = buildPerlPackage rec {
142+ name = "XML-Simple-2.22";
143+ src = fetchurl {
144+ url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
145+ sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
146+ };
147+ propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
148+ meta = {
149+ description = "An API for simple XML files";
150+ license = with lib.licenses; [ artistic1 gpl1Plus ];
151+ };
152+ };
153+```
154+
155+The output can be pasted into `pkgs/top-level/perl-packages.nix` or wherever else you need it.
156+
157+### Cross-compiling modules {#ssec-perl-cross-compilation}
158+
159+Nixpkgs has experimental support for cross-compiling Perl modules. In many cases, it will just work out of the box, even for modules with native extensions. Sometimes, however, the Makefile.PL for a module may (indirectly) import a native module. In that case, you will need to make a stub for that module that will satisfy the Makefile.PL and install it into `lib/perl5/site_perl/cross_perl/${perl.version}`. See the `postInstall` for `DBI` for an example.
doc/languages-frameworks/perl.xmldeleted−192
@@ -1,192 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-perl">
4− <title>Perl</title>
5−
6− <para>
7− Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic
8− package builder function for any Perl package that has a standard
9− <varname>Makefile.PL</varname>. It’s implemented in
10− <link
11−xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/perl-modules/generic"><filename>pkgs/development/perl-modules/generic</filename></link>.
12− </para>
13−
14− <para>
15− Perl packages from CPAN are defined in
16− <link
17−xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>,
18− rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages
19− are so straight-forward to build that they are defined here directly, rather
20− than having a separate function for each package called from
21− <filename>perl-packages.nix</filename>. However, more complicated packages
22− should be put in a separate file, typically in
23− <filename>pkgs/development/perl-modules</filename>. Here is an example of the
24− former:
25−<programlisting>
26−ClassC3 = buildPerlPackage rec {
27− name = "Class-C3-0.21";
28− src = fetchurl {
29− url = "mirror://cpan/authors/id/F/FL/FLORA/${name}.tar.gz";
30− sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
31− };
32−};
33−</programlisting>
34− Note the use of <literal>mirror://cpan/</literal>, and the
35− <literal>${name}</literal> in the URL definition to ensure that the name
36− attribute is consistent with the source that we’re actually downloading.
37− Perl packages are made available in <filename>all-packages.nix</filename>
38− through the variable <varname>perlPackages</varname>. For instance, if you
39− have a package that needs <varname>ClassC3</varname>, you would typically
40− write
41−<programlisting>
42−foo = import ../path/to/foo.nix {
43− inherit stdenv fetchurl ...;
44− inherit (perlPackages) ClassC3;
45−};
46−</programlisting>
47− in <filename>all-packages.nix</filename>. You can test building a Perl
48− package as follows:
49−<screen>
50−$ nix-build -A perlPackages.ClassC3
51−</screen>
52− <varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the
53− start of the name attribute, so the package above is actually called
54− <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
55−<screen>
56−$ nix-env -i perl-Class-C3
57−</screen>
58− (Of course you can also install using the attribute name: <literal>nix-env -i
59− -A perlPackages.ClassC3</literal>.)
60− </para>
61−
62− <para>
63− So what does <varname>buildPerlPackage</varname> do? It does the following:
64− <orderedlist>
65− <listitem>
66− <para>
67− In the configure phase, it calls <literal>perl Makefile.PL</literal> to
68− generate a Makefile. You can set the variable
69− <varname>makeMakerFlags</varname> to pass flags to
70− <filename>Makefile.PL</filename>
71− </para>
72− </listitem>
73− <listitem>
74− <para>
75− It adds the contents of the <envar>PERL5LIB</envar> environment variable
76− to <literal>#! .../bin/perl</literal> line of Perl scripts as
77− <literal>-I<replaceable>dir</replaceable></literal> flags. This ensures
78− that a script can find its dependencies.
79− </para>
80− </listitem>
81− <listitem>
82− <para>
83− In the fixup phase, it writes the propagated build inputs
84− (<varname>propagatedBuildInputs</varname>) to the file
85− <filename>$out/nix-support/propagated-user-env-packages</filename>.
86− <command>nix-env</command> recursively installs all packages listed in
87− this file when you install a package that has it. This ensures that a Perl
88− package can find its dependencies.
89− </para>
90− </listitem>
91− </orderedlist>
92− </para>
93−
94− <para>
95− <varname>buildPerlPackage</varname> is built on top of
96− <varname>stdenv</varname>, so everything can be customised in the usual way.
97− For instance, the <literal>BerkeleyDB</literal> module has a
98− <varname>preConfigure</varname> hook to generate a configuration file used by
99− <filename>Makefile.PL</filename>:
100−<programlisting>
101−{ buildPerlPackage, fetchurl, db }:
102−
103−buildPerlPackage rec {
104− name = "BerkeleyDB-0.36";
105−
106− src = fetchurl {
107− url = "mirror://cpan/authors/id/P/PM/PMQS/${name}.tar.gz";
108− sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
109− };
110−
111− preConfigure = ''
112− echo "LIB = ${db.out}/lib" > config.in
113− echo "INCLUDE = ${db.dev}/include" >> config.in
114− '';
115−}
116−</programlisting>
117− </para>
118−
119− <para>
120− Dependencies on other Perl packages can be specified in the
121− <varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname>
122− attributes. If something is exclusively a build-time dependency, use
123− <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use
124− <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl
125− module that has runtime dependencies on a bunch of other modules:
126−<programlisting>
127−ClassC3Componentised = buildPerlPackage rec {
128− name = "Class-C3-Componentised-1.0004";
129− src = fetchurl {
130− url = "mirror://cpan/authors/id/A/AS/ASH/${name}.tar.gz";
131− sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
132− };
133− propagatedBuildInputs = [
134− ClassC3 ClassInspector TestException MROCompat
135− ];
136−};
137−</programlisting>
138− </para>
139−
140− <section xml:id="ssec-generation-from-CPAN">
141− <title>Generation from CPAN</title>
142−
143− <para>
144− Nix expressions for Perl packages can be generated (almost) automatically
145− from CPAN. This is done by the program
146− <command>nix-generate-from-cpan</command>, which can be installed as
147− follows:
148− </para>
149−
150−<screen>
151−$ nix-env -i nix-generate-from-cpan
152−</screen>
153−
154− <para>
155− This program takes a Perl module name, looks it up on CPAN, fetches and
156− unpacks the corresponding package, and prints a Nix expression on standard
157− output. For example:
158−<screen>
159−$ nix-generate-from-cpan XML::Simple
160− XMLSimple = buildPerlPackage rec {
161− name = "XML-Simple-2.22";
162− src = fetchurl {
163− url = "mirror://cpan/authors/id/G/GR/GRANTM/${name}.tar.gz";
164− sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
165− };
166− propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
167− meta = {
168− description = "An API for simple XML files";
169− license = with stdenv.lib.licenses; [ artistic1 gpl1Plus ];
170− };
171− };
172−</screen>
173− The output can be pasted into
174− <filename>pkgs/top-level/perl-packages.nix</filename> or wherever else you
175− need it.
176− </para>
177− </section>
178−
179− <section xml:id="ssec-perl-cross-compilation">
180− <title>Cross-compiling modules</title>
181−
182− <para>
183− Nixpkgs has experimental support for cross-compiling Perl modules. In many
184− cases, it will just work out of the box, even for modules with native
185− extensions. Sometimes, however, the Makefile.PL for a module may
186− (indirectly) import a native module. In that case, you will need to make a
187− stub for that module that will satisfy the Makefile.PL and install it into
188− <filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the
189− <varname>postInstall</varname> for <varname>DBI</varname> for an example.
190− </para>
191− </section>
192−</section>
doc/languages-frameworks/php.section.mdnew file+155
@@ -0,0 +1,155 @@
1+# PHP {#sec-php}
2+
3+## User Guide {#ssec-php-user-guide}
4+
5+### Overview {#ssec-php-user-guide-overview}
6+
7+Several versions of PHP are available on Nix, each of which having a
8+wide variety of extensions and libraries available.
9+
10+The different versions of PHP that nixpkgs provides are located under
11+attributes named based on major and minor version number; e.g.,
12+`php74` is PHP 7.4.
13+
14+Only versions of PHP that are supported by upstream for the entirety
15+of a given NixOS release will be included in that release of
16+NixOS. See [PHP Supported
17+Versions](https://www.php.net/supported-versions.php).
18+
19+The attribute `php` refers to the version of PHP considered most
20+stable and thoroughly tested in nixpkgs for any given release of
21+NixOS - not necessarily the latest major release from upstream.
22+
23+All available PHP attributes are wrappers around their respective
24+binary PHP package and provide commonly used extensions this way. The
25+real PHP 7.4 package, i.e. the unwrapped one, is available as
26+`php74.unwrapped`; see the next section for more details.
27+
28+Interactive tools built on PHP are put in `php.packages`; composer is
29+for example available at `php.packages.composer`.
30+
31+Most extensions that come with PHP, as well as some popular
32+third-party ones, are available in `php.extensions`; for example, the
33+opcache extension shipped with PHP is available at
34+`php.extensions.opcache` and the third-party ImageMagick extension at
35+`php.extensions.imagick`.
36+
37+### Installing PHP with extensions {#ssec-php-user-guide-installing-with-extensions}
38+
39+A PHP package with specific extensions enabled can be built using
40+`php.withExtensions`. This is a function which accepts an anonymous
41+function as its only argument; the function should accept two named
42+parameters: `enabled` - a list of currently enabled extensions and
43+`all` - the set of all extensions, and return a list of wanted
44+extensions. For example, a PHP package with all default extensions and
45+ImageMagick enabled:
46+
47+```nix
48+php.withExtensions ({ enabled, all }:
49+ enabled ++ [ all.imagick ])
50+```
51+
52+To exclude some, but not all, of the default extensions, you can
53+filter the `enabled` list like this:
54+
55+```nix
56+php.withExtensions ({ enabled, all }:
57+ (lib.filter (e: e != php.extensions.opcache) enabled)
58+ ++ [ all.imagick ])
59+```
60+
61+To build your list of extensions from the ground up, you can simply
62+ignore `enabled`:
63+
64+```nix
65+php.withExtensions ({ all, ... }: with all; [ imagick opcache ])
66+```
67+
68+`php.withExtensions` provides extensions by wrapping a minimal php
69+base package, providing a `php.ini` file listing all extensions to be
70+loaded. You can access this package through the `php.unwrapped`
71+attribute; useful if you, for example, need access to the `dev`
72+output. The generated `php.ini` file can be accessed through the
73+`php.phpIni` attribute.
74+
75+If you want a PHP build with extra configuration in the `php.ini`
76+file, you can use `php.buildEnv`. This function takes two named and
77+optional parameters: `extensions` and `extraConfig`. `extensions`
78+takes an extension specification equivalent to that of
79+`php.withExtensions`, `extraConfig` a string of additional `php.ini`
80+configuration parameters. For example, a PHP package with the opcache
81+and ImageMagick extensions enabled, and `memory_limit` set to `256M`:
82+
83+```nix
84+php.buildEnv {
85+ extensions = { all, ... }: with all; [ imagick opcache ];
86+ extraConfig = "memory_limit=256M";
87+}
88+```
89+
90+#### Example setup for `phpfpm` {#ssec-php-user-guide-installing-with-extensions-phpfpm}
91+
92+You can use the previous examples in a `phpfpm` pool called `foo` as
93+follows:
94+
95+```nix
96+let
97+ myPhp = php.withExtensions ({ all, ... }: with all; [ imagick opcache ]);
98+in {
99+ services.phpfpm.pools."foo".phpPackage = myPhp;
100+};
101+```
102+
103+```nix
104+let
105+ myPhp = php.buildEnv {
106+ extensions = { all, ... }: with all; [ imagick opcache ];
107+ extraConfig = "memory_limit=256M";
108+ };
109+in {
110+ services.phpfpm.pools."foo".phpPackage = myPhp;
111+};
112+```
113+
114+#### Example usage with `nix-shell` {#ssec-php-user-guide-installing-with-extensions-nix-shell}
115+
116+This brings up a temporary environment that contains a PHP interpreter
117+with the extensions `imagick` and `opcache` enabled:
118+
119+```sh
120+nix-shell -p 'php.withExtensions ({ all, ... }: with all; [ imagick opcache ])'
121+```
122+
123+### Installing PHP packages with extensions {#ssec-php-user-guide-installing-packages-with-extensions}
124+
125+All interactive tools use the PHP package you get them from, so all
126+packages at `php.packages.*` use the `php` package with its default
127+extensions. Sometimes this default set of extensions isn't enough and
128+you may want to extend it. A common case of this is the `composer`
129+package: a project may depend on certain extensions and `composer`
130+won't work with that project unless those extensions are loaded.
131+
132+Example of building `composer` with additional extensions:
133+```nix
134+(php.withExtensions ({ all, enabled }:
135+ enabled ++ (with all; [ imagick redis ]))
136+).packages.composer
137+```
138+
139+### Overriding PHP packages {#ssec-php-user-guide-overriding-packages}
140+
141+`php-packages.nix` form a scope, allowing us to override the packages defined within. For example, to apply a patch to a `mysqlnd` extension, you can simply pass an overlay-style function to `php`’s `packageOverrides` argument:
142+
143+```nix
144+php.override {
145+ packageOverrides = final: prev: {
146+ extensions = prev.extensions // {
147+ mysqlnd = prev.extensions.mysqlnd.overrideAttrs (attrs: {
148+ patches = attrs.patches or [] ++ [
149+ …
150+ ];
151+ });
152+ };
153+ };
154+}
155+```
doc/languages-frameworks/python.section.md+981−426
@@ -1,15 +1,16 @@
1−# Python
1+# Python {#python}
22
3−## User Guide
3+## User Guide {#user-guide}
44
5−### Using Python
5+### Using Python {#using-python}
66
7−#### Overview
7+#### Overview {#overview}
88
99Several versions of the Python interpreter are available on Nix, as well as a
10−high amount of packages. The attribute `python` refers to the default
11−interpreter, which is currently CPython 2.7. It is also possible to refer to
12−specific versions, e.g. `python35` refers to CPython 3.5, and `pypy` refers to
10+high amount of packages. The attribute `python3` refers to the default
11+interpreter, which is currently CPython 3.9. The attribute `python` refers to
12+CPython 2.7 for backwards-compatibility. It is also possible to refer to
13+specific versions, e.g. `python38` refers to CPython 3.8, and `pypy` refers to
1314the default PyPy interpreter.
1415
1516Python is used a lot, and in different ways. This affects also how it is
@@ -25,161 +26,319 @@ however, are in separate sets, with one set per interpreter version.
2526The interpreters have several common attributes. One of these attributes is
2627`pkgs`, which is a package set of Python libraries for this specific
2728interpreter. E.g., the `toolz` package corresponding to the default interpreter
28−is `python.pkgs.toolz`, and the CPython 3.5 version is `python35.pkgs.toolz`.
29+is `python.pkgs.toolz`, and the CPython 3.8 version is `python38.pkgs.toolz`.
2930The main package set contains aliases to these package sets, e.g.
30−`pythonPackages` refers to `python.pkgs` and `python35Packages` to
31−`python35.pkgs`.
31+`pythonPackages` refers to `python.pkgs` and `python38Packages` to
32+`python38.pkgs`.
3233
33−#### Installing Python and packages
34+#### Installing Python and packages {#installing-python-and-packages}
3435
3536The Nix and NixOS manuals explain how packages are generally installed. In the
3637case of Python and Nix, it is important to make a distinction between whether the
3738package is considered an application or a library.
3839
39−Applications on Nix are typically installed into your user
40−profile imperatively using `nix-env -i`, and on NixOS declaratively by adding the
41−package name to `environment.systemPackages` in `/etc/nixos/configuration.nix`.
42−Dependencies such as libraries are automatically installed and should not be
43−installed explicitly.
40+Applications on Nix are typically installed into your user profile imperatively
41+using `nix-env -i`, and on NixOS declaratively by adding the package name to
42+`environment.systemPackages` in `/etc/nixos/configuration.nix`. Dependencies
43+such as libraries are automatically installed and should not be installed
44+explicitly.
4445
45−The same goes for Python applications and libraries. Python applications can be
46−installed in your profile. But Python libraries you would like to use for
47−development cannot be installed, at least not individually, because they won't
48−be able to find each other resulting in import errors. Instead, it is possible
49−to create an environment with `python.buildEnv` or `python.withPackages` where
50−the interpreter and other executables are able to find each other and all of the
51−modules.
46+The same goes for Python applications. Python applications can be installed in
47+your profile, and will be wrapped to find their exact library dependencies,
48+without impacting other applications or polluting your user environment.
5249
53−In the following examples we create an environment with Python 3.5, `numpy` and
54−`toolz`. As you may imagine, there is one limitation here, and that's that
55−you can install only one environment at a time. You will notice the complaints
56−about collisions when you try to install a second environment.
50+But Python libraries you would like to use for development cannot be installed,
51+at least not individually, because they won't be able to find each other
52+resulting in import errors. Instead, it is possible to create an environment
53+with `python.buildEnv` or `python.withPackages` where the interpreter and other
54+executables are wrapped to be able to find each other and all of the modules.
5755
58−##### Environment defined in separate `.nix` file
56+In the following examples we will start by creating a simple, ad-hoc environment
57+with a nix-shell that has `numpy` and `toolz` in Python 3.8; then we will create
58+a re-usable environment in a single-file Python script; then we will create a
59+full Python environment for development with this same environment.
5960
60−Create a file, e.g. `build.nix`, with the following expression
61−```nix
62−with import <nixpkgs> {};
61+Philosphically, this should be familiar to users who are used to a `venv` style
62+of development: individual projects create their own Python environments without
63+impacting the global environment or each other.
6364
64−python35.withPackages (ps: with ps; [ numpy toolz ])
65−```
66−and install it in your profile with
67−```shell
68−nix-env -if build.nix
69−```
70−Now you can use the Python interpreter, as well as the extra packages (`numpy`,
71−`toolz`) that you added to the environment.
65+#### Ad-hoc temporary Python environment with `nix-shell` {#ad-hoc-temporary-python-environment-with-nix-shell}
7266
73−##### Environment defined in `~/.config/nixpkgs/config.nix`
67+The simplest way to start playing with the way nix wraps and sets up Python
68+environments is with `nix-shell` at the cmdline. These environments create a
69+temporary shell session with a Python and a *precise* list of packages (plus
70+their runtime dependencies), with no other Python packages in the Python
71+interpreter's scope.
7472
75−If you prefer to, you could also add the environment as a package override to the Nixpkgs set, e.g.
76−using `config.nix`,
77−```nix
78−{ # ...
73+To create a Python 3.8 session with `numpy` and `toolz` available, run:
7974
80− packageOverrides = pkgs: with pkgs; {
81− myEnv = python35.withPackages (ps: with ps; [ numpy toolz ]);
82− };
83−}
75+```sh
76+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz ])'
8477```
85−and install it in your profile with
86−```shell
87−nix-env -iA nixpkgs.myEnv
78+
79+By default `nix-shell` will start a `bash` session with this interpreter in our
80+`PATH`, so if we then run:
81+
82+```Python console
83+[nix-shell:~/src/nixpkgs]$ python3
84+Python 3.8.1 (default, Dec 18 2019, 19:06:26)
85+[GCC 9.2.0] on linux
86+Type "help", "copyright", "credits" or "license" for more information.
87+>>> import numpy; import toolz
8888```
89−The environment is is installed by referring to the attribute, and considering
90−the `nixpkgs` channel was used.
9189
92−##### Environment defined in `/etc/nixos/configuration.nix`
90+Note that no other modules are in scope, even if they were imperatively
91+installed into our user environment as a dependency of a Python application:
9392
94−For the sake of completeness, here's another example how to install the environment system-wide.
93+```Python console
94+>>> import requests
95+Traceback (most recent call last):
96+ File "<stdin>", line 1, in <module>
97+ModuleNotFoundError: No module named 'requests'
98+```
9599
96−```nix
97−{ # ...
100+We can add as many additional modules onto the `nix-shell` as we need, and we
101+will still get 1 wrapped Python interpreter. We can start the interpreter
102+directly like so:
98103
99− environment.systemPackages = with pkgs; [
100− (python35.withPackages(ps: with ps; [ numpy toolz ]))
101− ];
102−}
104+```sh
105+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy toolz requests ])' --run python3
106+these derivations will be built:
107+ /nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv
108+building '/nix/store/xbdsrqrsfa1yva5s7pzsra8k08gxlbz1-python3-3.8.1-env.drv'...
109+created 277 symlinks in user environment
110+Python 3.8.1 (default, Dec 18 2019, 19:06:26)
111+[GCC 9.2.0] on linux
112+Type "help", "copyright", "credits" or "license" for more information.
113+>>> import requests
114+>>>
103115```
104116
105−#### Temporary Python environment with `nix-shell`
117+Notice that this time it built a new Python environment, which now includes
118+`requests`. Building an environment just creates wrapper scripts that expose the
119+selected dependencies to the interpreter while re-using the actual modules. This
120+means if any other env has installed `requests` or `numpy` in a different
121+context, we don't need to recompile them -- we just recompile the wrapper script
122+that sets up an interpreter pointing to them. This matters much more for "big"
123+modules like `pytorch` or `tensorflow`.
124+
125+Module names usually match their names on [pypi.org](https://pypi.org/), but
126+you can use the [Nixpkgs search website](https://nixos.org/nixos/packages.html)
127+to find them as well (along with non-python packages).
128+
129+At this point we can create throwaway experimental Python environments with
130+arbitrary dependencies. This is a good way to get a feel for how the Python
131+interpreter and dependencies work in Nix and NixOS, but to do some actual
132+development, we'll want to make it a bit more persistent.
133+
134+##### Running Python scripts and using `nix-shell` as shebang {#running-python-scripts-and-using-nix-shell-as-shebang}
135+
136+Sometimes, we have a script whose header looks like this:
137+
138+```python
139+#!/usr/bin/env python3
140+import numpy as np
141+a = np.array([1,2])
142+b = np.array([3,4])
143+print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
144+```
106145
107−The examples in the previous section showed how to install a Python environment
108−into a profile. For development you may need to use multiple environments.
109−`nix-shell` gives the possibility to temporarily load another environment, akin
110−to `virtualenv`.
146+Executing this script requires a `python3` that has `numpy`. Using what we learned
147+in the previous section, we could startup a shell and just run it like so:
111148
112−There are two methods for loading a shell with Python packages. The first and recommended method
113−is to create an environment with `python.buildEnv` or `python.withPackages` and load that. E.g.
114−```sh
115−$ nix-shell -p 'python35.withPackages(ps: with ps; [ numpy toolz ])'
149+```ShellSession
150+$ nix-shell -p 'python38.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
151+The dot product of [1 2] and [3 4] is: 11
116152```
117−opens a shell from which you can launch the interpreter
118−```sh
119−[nix-shell:~] python3
153+
154+But if we maintain the script ourselves, and if there are more dependencies, it
155+may be nice to encode those dependencies in source to make the script re-usable
156+without that bit of knowledge. That can be done by using `nix-shell` as a
157+[shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)), like so:
158+
159+```python
160+#!/usr/bin/env nix-shell
161+#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.numpy ])"
162+import numpy as np
163+a = np.array([1,2])
164+b = np.array([3,4])
165+print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
120166```
121−The other method, which is not recommended, does not create an environment and requires you to list the packages directly,
167+
168+Then we simply execute it, without requiring any environment setup at all!
122169
123170```sh
124−$ nix-shell -p python35.pkgs.numpy python35.pkgs.toolz
171+$ ./foo.py
172+The dot product of [1 2] and [3 4] is: 11
173+```
174+
175+If the dependencies are not available on the host where `foo.py` is executed, it
176+will build or download them from a Nix binary cache prior to starting up, prior
177+that it is executed on a machine with a multi-user nix installation.
178+
179+This provides a way to ship a self bootstrapping Python script, akin to a
180+statically linked binary, where it can be run on any machine (provided nix is
181+installed) without having to assume that `numpy` is installed globally on the
182+system.
183+
184+By default it is pulling the import checkout of Nixpkgs itself from our nix
185+channel, which is nice as it cache aligns with our other package builds, but we
186+can make it fully reproducible by pinning the `nixpkgs` import:
187+
188+```python
189+#!/usr/bin/env nix-shell
190+#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.numpy ])"
191+#!nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/d373d80b1207d52621961b16aa4a3438e4f98167.tar.gz
192+import numpy as np
193+a = np.array([1,2])
194+b = np.array([3,4])
195+print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
125196```
126−Again, it is possible to launch the interpreter from the shell.
127−The Python interpreter has the attribute `pkgs` which contains all Python libraries for that specific interpreter.
128197
129−##### Load environment from `.nix` expression
130−As explained in the Nix manual, `nix-shell` can also load an
131−expression from a `.nix` file. Say we want to have Python 3.5, `numpy`
132−and `toolz`, like before, in an environment. Consider a `shell.nix` file
133−with
198+This will execute with the exact same versions of Python 3.8, numpy, and system
199+dependencies a year from now as it does today, because it will always use
200+exactly git commit `d373d80b1207d52621961b16aa4a3438e4f98167` of Nixpkgs for all
201+of the package versions.
202+
203+This is also a great way to ensure the script executes identically on different
204+servers.
205+
206+##### Load environment from `.nix` expression {#load-environment-from-.nix-expression}
207+
208+We've now seen how to create an ad-hoc temporary shell session, and how to
209+create a single script with Python dependencies, but in the course of normal
210+development we're usually working in an entire package repository.
211+
212+As explained in the Nix manual, `nix-shell` can also load an expression from a
213+`.nix` file. Say we want to have Python 3.8, `numpy` and `toolz`, like before,
214+in an environment. We can add a `shell.nix` file describing our dependencies:
215+
134216```nix
135217with import <nixpkgs> {};
136−
137−(python35.withPackages (ps: [ps.numpy ps.toolz])).env
218+(python38.withPackages (ps: [ps.numpy ps.toolz])).env
138219```
139−Executing `nix-shell` gives you again a Nix shell from which you can run Python.
220+
221+And then at the command line, just typing `nix-shell` produces the same
222+environment as before. In a normal project, we'll likely have many more
223+dependencies; this can provide a way for developers to share the environments
224+with each other and with CI builders.
140225
141226What's happening here?
142227
143−1. We begin with importing the Nix Packages collections. `import <nixpkgs>` imports the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. These attributes form the main package set.
144−2. Then we create a Python 3.5 environment with the `withPackages` function.
145−3. The `withPackages` function expects us to provide a function as an argument that takes the set of all python packages and returns a list of packages to include in the environment. Here, we select the packages `numpy` and `toolz` from the package set.
228+1. We begin with importing the Nix Packages collections. `import <nixpkgs>`
229+ imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
230+ brings all attributes of `nixpkgs` in the local scope. These attributes form
231+ the main package set.
232+2. Then we create a Python 3.8 environment with the `withPackages` function, as before.
233+3. The `withPackages` function expects us to provide a function as an argument
234+ that takes the set of all Python packages and returns a list of packages to
235+ include in the environment. Here, we select the packages `numpy` and `toolz`
236+ from the package set.
146237
147−##### Execute command with `--run`
148−A convenient option with `nix-shell` is the `--run`
149−option, with which you can execute a command in the `nix-shell`. We can
150−e.g. directly open a Python shell
151−```sh
152−$ nix-shell -p python35Packages.numpy python35Packages.toolz --run "python3"
238+To combine this with `mkShell` you can:
239+
240+```nix
241+with import <nixpkgs> {};
242+let
243+ pythonEnv = python38.withPackages (ps: [
244+ ps.numpy
245+ ps.toolz
246+ ]);
247+in mkShell {
248+ packages = [
249+ pythonEnv
250+
251+ black
252+ mypy
253+
254+ libffi
255+ openssl
256+ ];
257+}
258+```
259+
260+This will create a unified environment that has not just our Python interpreter
261+and its Python dependencies, but also tools like `black` or `mypy` and libraries
262+like `libffi` the `openssl` in scope. This is generic and can span any number of
263+tools or languages across the Nixpkgs ecosystem.
264+
265+##### Installing environments globally on the system {#installing-environments-globally-on-the-system}
266+
267+Up to now, we've been creating environments scoped to an ad-hoc shell session,
268+or a single script, or a single project. This is generally advisable, as it
269+avoids pollution across contexts.
270+
271+However, sometimes we know we will often want a Python with some basic packages,
272+and want this available without having to enter into a shell or build context.
273+This can be useful to have things like vim/emacs editors and plugins or shell
274+tools "just work" without having to set them up, or when running other software
275+that expects packages to be installed globally.
276+
277+To create your own custom environment, create a file in `~/.config/nixpkgs/overlays/`
278+that looks like this:
279+
280+```nix
281+# ~/.config/nixpkgs/overlays/myEnv.nix
282+self: super: {
283+ myEnv = super.buildEnv {
284+ name = "myEnv";
285+ paths = [
286+ # A Python 3 interpreter with some packages
287+ (self.python3.withPackages (
288+ ps: with ps; [
289+ pyflakes
290+ pytest
291+ python-language-server
292+ ]
293+ ))
294+
295+ # Some other packages we'd like as part of this env
296+ self.mypy
297+ self.black
298+ self.ripgrep
299+ self.tmux
300+ ];
301+ };
302+}
153303```
154−or run a script
304+
305+You can then build and install this to your profile with:
306+
155307```sh
156−$ nix-shell -p python35Packages.numpy python35Packages.toolz --run "python3 myscript.py"
308+nix-env -iA myEnv
157309```
158310
159−##### `nix-shell` as shebang
160−In fact, for the second use case, there is a more convenient method. You can
161−add a [shebang](https://en.wikipedia.org/wiki/Shebang_(Unix)) to your script
162−specifying which dependencies `nix-shell` needs. With the following shebang, you
163−can just execute `./myscript.py`, and it will make available all dependencies and
164−run the script in the `python3` shell.
311+One limitation of this is that you can only have 1 Python env installed
312+globally, since they conflict on the `python` to load out of your `PATH`.
313+
314+If you get a conflict or prefer to keep the setup clean, you can have `nix-env`
315+atomically *uninstall* all other imperatively installed packages and replace
316+your profile with just `myEnv` by using the `--replace` flag.
165317
166−```py
167−#! /usr/bin/env nix-shell
168−#! nix-shell -i python3 -p "python3.withPackages(ps: [ps.numpy])"
318+##### Environment defined in `/etc/nixos/configuration.nix` {#environment-defined-in-etcnixosconfiguration.nix}
169319
170−import numpy
320+For the sake of completeness, here's how to install the environment system-wide
321+on NixOS.
171322
172−print(numpy.__version__)
323+```nix
324+{ # ...
325+
326+ environment.systemPackages = with pkgs; [
327+ (python38.withPackages(ps: with ps; [ numpy toolz ]))
328+ ];
329+}
173330```
174331
175−### Developing with Python
332+### Developing with Python {#developing-with-python}
333+
334+Above, we were mostly just focused on use cases and what to do to get started
335+creating working Python environments in nix.
176336
177−Now that you know how to get a working Python environment with Nix, it is time
178−to go forward and start actually developing with Python. We will first have a
179−look at how Python packages are packaged on Nix. Then, we will look at how you
180−can use development mode with your code.
337+Now that you know the basics to be up and running, it is time to take a step
338+back and take a deeper look at how Python packages are packaged on Nix. Then,
339+we will look at how you can use development mode with your code.
181340
182−#### Packaging a library
341+#### Python library packages in Nixpkgs {#python-library-packages-in-nixpkgs}
183342
184343With Nix all packages are built by functions. The main function in Nix for
185344building Python libraries is `buildPythonPackage`. Let's see how we can build the
@@ -188,23 +347,22 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
188347```nix
189348{ lib, buildPythonPackage, fetchPypi }:
190349
191− toolz = buildPythonPackage rec {
192− pname = "toolz";
193− version = "0.7.4";
350+buildPythonPackage rec {
351+ pname = "toolz";
352+ version = "0.10.0";
194353
195− src = fetchPypi {
196− inherit pname version;
197− sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
198− };
354+ src = fetchPypi {
355+ inherit pname version;
356+ sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
357+ };
199358
200− doCheck = false;
359+ doCheck = false;
201360
202− meta = with lib; {
203− homepage = https://github.com/pytoolz/toolz;
204− description = "List processing tools and functional utilities";
205− license = licenses.bsd3;
206− maintainers = with maintainers; [ fridh ];
207− };
361+ meta = with lib; {
362+ homepage = "https://github.com/pytoolz/toolz";
363+ description = "List processing tools and functional utilities";
364+ license = licenses.bsd3;
365+ maintainers = with maintainers; [ fridh ];
208366 };
209367}
210368```
@@ -220,8 +378,9 @@ information. The output of the function is a derivation.
220378
221379An expression for `toolz` can be found in the Nixpkgs repository. As explained
222380in the introduction of this Python section, a derivation of `toolz` is available
223−for each interpreter version, e.g. `python35.pkgs.toolz` refers to the `toolz`
224−derivation corresponding to the CPython 3.5 interpreter.
381+for each interpreter version, e.g. `python38.pkgs.toolz` refers to the `toolz`
382+derivation corresponding to the CPython 3.8 interpreter.
383+
225384The above example works when you're directly working on
226385`pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though,
227386you will want to test a Nix expression outside of the Nixpkgs tree.
@@ -233,13 +392,13 @@ and adds it along with a `numpy` package to a Python environment.
233392with import <nixpkgs> {};
234393
235394( let
236− my_toolz = python35.pkgs.buildPythonPackage rec {
395+ my_toolz = python38.pkgs.buildPythonPackage rec {
237396 pname = "toolz";
238− version = "0.7.4";
397+ version = "0.10.0";
239398
240− src = python35.pkgs.fetchPypi {
399+ src = python38.pkgs.fetchPypi {
241400 inherit pname version;
242− sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
401+ sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
243402 };
244403
245404 doCheck = false;
@@ -250,11 +409,12 @@ with import <nixpkgs> {};
250409 };
251410 };
252411
253− in python35.withPackages (ps: [ps.numpy my_toolz])
412+ in python38.withPackages (ps: [ps.numpy my_toolz])
254413).env
255414```
415+
256416Executing `nix-shell` will result in an environment in which you can use
257−Python 3.5 and the `toolz` package. As you can see we had to explicitly mention
417+Python 3.8 and the `toolz` package. As you can see we had to explicitly mention
258418for which Python version we want to build a package.
259419
260420So, what did we do here? Well, we took the Nix expression that we used earlier
@@ -265,13 +425,13 @@ of `withPackages` we used a `let` expression. You can see that we used
265425`toolz` from the Nixpkgs package set this time, but instead took our own version
266426that we introduced with the `let` expression.
267427
268−#### Handling dependencies
428+#### Handling dependencies {#handling-dependencies}
269429
270430Our example, `toolz`, does not have any dependencies on other Python packages or
271431system libraries. According to the manual, `buildPythonPackage` uses the
272432arguments `buildInputs` and `propagatedBuildInputs` to specify dependencies. If
273433something is exclusively a build-time dependency, then the dependency should be
274−included as a `buildInput`, but if it is (also) a runtime dependency, then it
434+included in `buildInputs`, but if it is (also) a runtime dependency, then it
275435should be added to `propagatedBuildInputs`. Test dependencies are considered
276436build-time dependencies and passed to `checkInputs`.
277437
@@ -279,32 +439,31 @@ The following example shows which arguments are given to `buildPythonPackage` in
279439order to build [`datashape`](https://github.com/blaze/datashape).
280440
281441```nix
282−{ # ...
442+{ lib, buildPythonPackage, fetchPypi, numpy, multipledispatch, python-dateutil, pytest }:
283443
284− datashape = buildPythonPackage rec {
285− pname = "datashape";
286− version = "0.4.7";
444+buildPythonPackage rec {
445+ pname = "datashape";
446+ version = "0.4.7";
287447
288− src = fetchPypi {
289− inherit pname version;
290− sha256 = "14b2ef766d4c9652ab813182e866f493475e65e558bed0822e38bf07bba1a278";
291− };
448+ src = fetchPypi {
449+ inherit pname version;
450+ sha256 = "14b2ef766d4c9652ab813182e866f493475e65e558bed0822e38bf07bba1a278";
451+ };
292452
293− checkInputs = with self; [ pytest ];
294− propagatedBuildInputs = with self; [ numpy multipledispatch dateutil ];
453+ checkInputs = [ pytest ];
454+ propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];
295455
296− meta = with lib; {
297− homepage = https://github.com/ContinuumIO/datashape;
298− description = "A data description language";
299− license = licenses.bsd2;
300− maintainers = with maintainers; [ fridh ];
301− };
456+ meta = with lib; {
457+ homepage = "https://github.com/ContinuumIO/datashape";
458+ description = "A data description language";
459+ license = licenses.bsd2;
460+ maintainers = with maintainers; [ fridh ];
302461 };
303462}
304463```
305464
306465We can see several runtime dependencies, `numpy`, `multipledispatch`, and
307−`dateutil`. Furthermore, we have one `buildInput`, i.e. `pytest`. `pytest` is a
466+`python-dateutil`. Furthermore, we have one `checkInputs`, i.e. `pytest`. `pytest` is a
308467test runner and is only used during the `checkPhase` and is therefore not added
309468to `propagatedBuildInputs`.
310469
@@ -314,25 +473,24 @@ Python bindings to `libxml2` and `libxslt`. These libraries are only required
314473when building the bindings and are therefore added as `buildInputs`.
315474
316475```nix
317−{ # ...
476+{ lib, pkgs, buildPythonPackage, fetchPypi }:
318477
319− lxml = buildPythonPackage rec {
320− pname = "lxml";
321− version = "3.4.4";
478+buildPythonPackage rec {
479+ pname = "lxml";
480+ version = "3.4.4";
322481
323− src = fetchPypi {
324− inherit pname version;
325− sha256 = "16a0fa97hym9ysdk3rmqz32xdjqmy4w34ld3rm3jf5viqjx65lxk";
326− };
482+ src = fetchPypi {
483+ inherit pname version;
484+ sha256 = "16a0fa97hym9ysdk3rmqz32xdjqmy4w34ld3rm3jf5viqjx65lxk";
485+ };
327486
328− buildInputs = with self; [ pkgs.libxml2 pkgs.libxslt ];
487+ buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
329488
330− meta = with lib; {
331− description = "Pythonic binding for the libxml2 and libxslt libraries";
332− homepage = https://lxml.de;
333− license = licenses.bsd3;
334− maintainers = with maintainers; [ sjourdois ];
335− };
489+ meta = with lib; {
490+ description = "Pythonic binding for the libxml2 and libxslt libraries";
491+ homepage = "https://lxml.de";
492+ license = licenses.bsd3;
493+ maintainers = with maintainers; [ sjourdois ];
336494 };
337495}
338496```
@@ -340,71 +498,195 @@ when building the bindings and are therefore added as `buildInputs`.
340498In this example `lxml` and Nix are able to work out exactly where the relevant
341499files of the dependencies are. This is not always the case.
342500
343−The example below shows bindings to The Fastest Fourier Transform in the West, commonly known as
344−FFTW. On Nix we have separate packages of FFTW for the different types of floats
345−(`"single"`, `"double"`, `"long-double"`). The bindings need all three types,
346−and therefore we add all three as `buildInputs`. The bindings don't expect to
347−find each of them in a different folder, and therefore we have to set `LDFLAGS`
348−and `CFLAGS`.
501+The example below shows bindings to The Fastest Fourier Transform in the West,
502+commonly known as FFTW. On Nix we have separate packages of FFTW for the
503+different types of floats (`"single"`, `"double"`, `"long-double"`). The
504+bindings need all three types, and therefore we add all three as `buildInputs`.
505+The bindings don't expect to find each of them in a different folder, and
506+therefore we have to set `LDFLAGS` and `CFLAGS`.
349507
350508```nix
351−{ # ...
509+{ lib, pkgs, buildPythonPackage, fetchPypi, numpy, scipy }:
352510
353− pyfftw = buildPythonPackage rec {
354− pname = "pyFFTW";
355− version = "0.9.2";
511+buildPythonPackage rec {
512+ pname = "pyFFTW";
513+ version = "0.9.2";
356514
357− src = fetchPypi {
358− inherit pname version;
359− sha256 = "f6bbb6afa93085409ab24885a1a3cdb8909f095a142f4d49e346f2bd1b789074";
360− };
515+ src = fetchPypi {
516+ inherit pname version;
517+ sha256 = "f6bbb6afa93085409ab24885a1a3cdb8909f095a142f4d49e346f2bd1b789074";
518+ };
361519
362− buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
520+ buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
363521
364− propagatedBuildInputs = with self; [ numpy scipy ];
522+ propagatedBuildInputs = [ numpy scipy ];
365523
366− # Tests cannot import pyfftw. pyfftw works fine though.
367− doCheck = false;
524+ # Tests cannot import pyfftw. pyfftw works fine though.
525+ doCheck = false;
368526
369− preConfigure = ''
370− export LDFLAGS="-L${pkgs.fftw.dev}/lib -L${pkgs.fftwFloat.out}/lib -L${pkgs.fftwLongDouble.out}/lib"
371− export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
372− '';
527+ preConfigure = ''
528+ export LDFLAGS="-L${pkgs.fftw.dev}/lib -L${pkgs.fftwFloat.out}/lib -L${pkgs.fftwLongDouble.out}/lib"
529+ export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
530+ '';
373531
374− meta = with lib; {
375− description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
376− homepage = http://hgomersall.github.com/pyFFTW;
377− license = with licenses; [ bsd2 bsd3 ];
378− maintainers = with maintainers; [ fridh ];
379− };
532+ meta = with lib; {
533+ description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
534+ homepage = "http://hgomersall.github.com/pyFFTW";
535+ license = with licenses; [ bsd2 bsd3 ];
536+ maintainers = with maintainers; [ fridh ];
380537 };
381538}
382539```
540+
383541Note also the line `doCheck = false;`, we explicitly disabled running the test-suite.
384542
543+#### Testing Python Packages {#testing-python-packages}
544+
545+It is highly encouraged to have testing as part of the package build. This
546+helps to avoid situations where the package was able to build and install,
547+but is not usable at runtime. Currently, all packages will use the `test`
548+command provided by the setup.py (i.e. `python setup.py test`). However,
549+this is currently deprecated https://github.com/pypa/setuptools/pull/1878
550+and your package should provide its own checkPhase.
551+
552+*NOTE:* The `checkPhase` for python maps to the `installCheckPhase` on a
553+normal derivation. This is due to many python packages not behaving well
554+to the pre-installed version of the package. Version info, and natively
555+compiled extensions generally only exist in the install directory, and
556+thus can cause issues when a test suite asserts on that behavior.
557+
558+*NOTE:* Tests should only be disabled if they don't agree with nix
559+(e.g. external dependencies, network access, flakey tests), however,
560+as many tests should be enabled as possible. Failing tests can still be
561+a good indication that the package is not in a valid state.
562+
563+#### Using pytest {#using-pytest}
564+
565+Pytest is the most common test runner for python repositories. A trivial
566+test run would be:
567+
568+```
569+ checkInputs = [ pytest ];
570+ checkPhase = "pytest";
571+```
572+
573+However, many repositories' test suites do not translate well to nix's build
574+sandbox, and will generally need many tests to be disabled.
575+
576+To filter tests using pytest, one can do the following:
577+
578+```
579+ checkInputs = [ pytest ];
580+ # avoid tests which need additional data or touch network
581+ checkPhase = ''
582+ pytest tests/ --ignore=tests/integration -k 'not download and not update'
583+ '';
584+```
585+
586+`--ignore` will tell pytest to ignore that file or directory from being
587+collected as part of a test run. This is useful is a file uses a package
588+which is not available in nixpkgs, thus skipping that test file is much
589+easier than having to create a new package.
590+
591+`-k` is used to define a predicate for test names. In this example, we are
592+filtering out tests which contain `download` or `update` in their test case name.
593+Only one `-k` argument is allowed, and thus a long predicate should be concatenated
594+with “\\” and wrapped to the next line.
385595
386−#### Develop local package
596+*NOTE:* In pytest==6.0.1, the use of “\\” to continue a line (e.g. `-k 'not download \'`) has
597+been removed, in this case, it's recommended to use `pytestCheckHook`.
387598
388−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`);
389−instead of installing the package this command creates a special link to the project code.
390−That way, you can run updated code without having to reinstall after each and every change you make.
391−Development mode is also available. Let's see how you can use it.
599+#### Using pytestCheckHook {#using-pytestcheckhook}
392600
393−In the previous Nix expression the source was fetched from an url. We can also refer to a local source instead using
394−`src = ./path/to/source/tree;`
601+`pytestCheckHook` is a convenient hook which will substitute the setuptools
602+`test` command for a checkPhase which runs `pytest`. This is also beneficial
603+when a package may need many items disabled to run the test suite.
604+
605+Using the example above, the analagous pytestCheckHook usage would be:
606+
607+```
608+ checkInputs = [ pytestCheckHook ];
609+
610+ # requires additional data
611+ pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
612+
613+ disabledTests = [
614+ # touches network
615+ "download"
616+ "update"
617+ ];
618+
619+ disabledTestPaths = [
620+ "tests/test_failing.py"
621+ ];
622+```
623+
624+This is expecially useful when tests need to be conditionallydisabled,
625+for example:
626+
627+```
628+ disabledTests = [
629+ # touches network
630+ "download"
631+ "update"
632+ ] ++ lib.optionals (pythonAtLeast "3.8") [
633+ # broken due to python3.8 async changes
634+ "async"
635+ ] ++ lib.optionals stdenv.isDarwin [
636+ # can fail when building with other packages
637+ "socket"
638+ ];
639+```
640+Trying to concatenate the related strings to disable tests in a regular checkPhase
641+would be much harder to read. This also enables us to comment on why specific tests
642+are disabled.
643+
644+#### Using pythonImportsCheck {#using-pythonimportscheck}
645+
646+Although unit tests are highly prefered to validate correctness of a package, not
647+all packages have test suites that can be ran easily, and some have none at all.
648+To help ensure the package still works, `pythonImportsCheck` can attempt to import
649+the listed modules.
650+
651+```
652+ pythonImportsCheck = [ "requests" "urllib" ];
653+```
654+roughly translates to:
655+```
656+ postCheck = ''
657+ PYTHONPATH=$out/${python.sitePackages}:$PYTHONPATH
658+ python -c "import requests; import urllib"
659+ '';
660+```
661+However, this is done in it's own phase, and not dependent on whether `doCheck = true;`
662+
663+This can also be useful in verifying that the package doesn't assume commonly
664+present packages (e.g. `setuptools`)
665+
666+### Develop local package {#develop-local-package}
667+
668+As a Python developer you're likely aware of [development mode](http://setuptools.readthedocs.io/en/latest/setuptools.html#development-mode)
669+(`python setup.py develop`); instead of installing the package this command
670+creates a special link to the project code. That way, you can run updated code
671+without having to reinstall after each and every change you make. Development
672+mode is also available. Let's see how you can use it.
673+
674+In the previous Nix expression the source was fetched from an url. We can also
675+refer to a local source instead using `src = ./path/to/source/tree;`
395676
396677If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
397678is a local source, and if the local source has a `setup.py`, then development
398679mode is activated.
399680
400−In the following example we create a simple environment that
401−has a Python 3.5 version of our package in it, as well as its dependencies and
402−other packages we like to have in the environment, all specified with `propagatedBuildInputs`.
403−Indeed, we can just add any package we like to have in our environment to `propagatedBuildInputs`.
681+In the following example we create a simple environment that has a Python 3.8
682+version of our package in it, as well as its dependencies and other packages we
683+like to have in the environment, all specified with `propagatedBuildInputs`.
684+Indeed, we can just add any package we like to have in our environment to
685+`propagatedBuildInputs`.
404686
405687```nix
406688with import <nixpkgs> {};
407−with pkgs.python35Packages;
689+with python38Packages;
408690
409691buildPythonPackage rec {
410692 name = "mypackage";
@@ -413,10 +695,10 @@ buildPythonPackage rec {
413695}
414696```
415697
416−It is important to note that due to how development mode is implemented on Nix it is not possible to have multiple packages simultaneously in development mode.
698+It is important to note that due to how development mode is implemented on Nix
699+it is not possible to have multiple packages simultaneously in development mode.
417700
418−
419−### Organising your packages
701+### Organising your packages {#organising-your-packages}
420702
421703So far we discussed how you can use Python on Nix, and how you can develop with
422704it. We've looked at how you write expressions to package Python packages, and we
@@ -428,7 +710,7 @@ like to be able to use in different projects. In order to minimise unnecessary
428710duplication we now look at how you can maintain a repository with your
429711own packages. The important functions here are `import` and `callPackage`.
430712
431−### Including a derivation using `callPackage`
713+### Including a derivation using `callPackage` {#including-a-derivation-using-callpackage}
432714
433715Earlier we created a Python environment using `withPackages`, and included the
434716`toolz` package via a `let` expression.
@@ -437,19 +719,19 @@ Let's split the package definition from the environment definition.
437719We first create a function that builds `toolz` in `~/path/to/toolz/release.nix`
438720
439721```nix
440−{ lib, pkgs, buildPythonPackage }:
722+{ lib, buildPythonPackage }:
441723
442724buildPythonPackage rec {
443725 pname = "toolz";
444− version = "0.7.4";
726+ version = "0.10.0";
445727
446728 src = fetchPypi {
447729 inherit pname version;
448− sha256 = "43c2c9e5e7a16b6c88ba3088a9bfc82f7db8e13378be7c78d6c14a5f8ed05afd";
730+ sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
449731 };
450732
451733 meta = with lib; {
452− homepage = "http://github.com/pytoolz/toolz/";
734+ homepage = "https://github.com/pytoolz/toolz/";
453735 description = "List processing tools and functional utilities";
454736 license = licenses.bsd3;
455737 maintainers = with maintainers; [ fridh ];
@@ -457,18 +739,17 @@ buildPythonPackage rec {
457739}
458740```
459741
460−It takes two arguments, `pkgs` and `buildPythonPackage`.
461−We now call this function using `callPackage` in the definition of our environment
742+It takes an argument `buildPythonPackage`. We now call this function using
743+`callPackage` in the definition of our environment
462744
463745```nix
464746with import <nixpkgs> {};
465747
466748( let
467− toolz = pkgs.callPackage /path/to/toolz/release.nix {
468− pkgs = pkgs;
469− buildPythonPackage = pkgs.python35Packages.buildPythonPackage;
749+ toolz = callPackage /path/to/toolz/release.nix {
750+ buildPythonPackage = python38Packages.buildPythonPackage;
470751 };
471− in pkgs.python35.withPackages (ps: [ ps.numpy toolz ])
752+ in python38.withPackages (ps: [ ps.numpy toolz ])
472753).env
473754```
474755
@@ -476,29 +757,31 @@ Important to remember is that the Python version for which the package is made
476757depends on the `python` derivation that is passed to `buildPythonPackage`. Nix
477758tries to automatically pass arguments when possible, which is why generally you
478759don't explicitly define which `python` derivation should be used. In the above
479−example we use `buildPythonPackage` that is part of the set `python35Packages`,
480−and in this case the `python35` interpreter is automatically used.
760+example we use `buildPythonPackage` that is part of the set `python38Packages`,
761+and in this case the `python38` interpreter is automatically used.
481762
482−## Reference
763+## Reference {#reference}
483764
484−### Interpreters
765+### Interpreters {#interpreters}
485766
486−Versions 2.7, 3.5, 3.6 and 3.7 of the CPython interpreter are available as
487−respectively `python27`, `python35`, `python36`, and `python37`. The PyPy
488−interpreter is available as `pypy`. The aliases `python2` and `python3`
489−correspond to respectively `python27` and `python37`. The default interpreter,
490−`python`, maps to `python2`. The Nix expressions for the interpreters can be
491−found in `pkgs/development/interpreters/python`.
767+Versions 2.7, 3.7, 3.8 and 3.9 of the CPython interpreter are available as
768+respectively `python27`, `python37`, `python38` and `python39`. The
769+aliases `python2` and `python3` correspond to respectively `python27` and
770+`python39`. The attribute `python` maps to `python2`. The PyPy interpreters
771+compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
772+aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix
773+expressions for the interpreters can be found in
774+`pkgs/development/interpreters/python`.
492775
493776All packages depending on any Python interpreter get appended
494777`out/{python.sitePackages}` to `$PYTHONPATH` if such directory
495778exists.
496779
497−#### Missing `tkinter` module standard library
780+#### Missing `tkinter` module standard library {#missing-tkinter-module-standard-library}
498781
499782To reduce closure size the `Tkinter`/`tkinter` is available as a separate package, `pythonPackages.tkinter`.
500783
501−#### Attributes on interpreters packages
784+#### Attributes on interpreters packages {#attributes-on-interpreters-packages}
502785
503786Each interpreter has the following attributes:
504787
@@ -507,19 +790,37 @@ Each interpreter has the following attributes:
507790- `buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
508791- `withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
509792- `sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
510−- `executable`. Name of the interpreter executable, e.g. `python3.7`.
793+- `executable`. Name of the interpreter executable, e.g. `python3.8`.
511794- `pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
512795
513−### Building packages and applications
796+### Optimizations {#optimizations}
797+
798+The Python interpreters are by default not build with optimizations enabled, because
799+the builds are in that case not reproducible. To enable optimizations, override the
800+interpreter of interest, e.g using
801+
802+```
803+let
804+ pkgs = import ./. {};
805+ mypython = pkgs.python3.override {
806+ enableOptimizations = true;
807+ reproducibleBuild = false;
808+ self = mypython;
809+ };
810+in mypython
811+```
812+
813+### Building packages and applications {#building-packages-and-applications}
514814
515815Python libraries and applications that use `setuptools` or
516−`distutils` are typically build with respectively the `buildPythonPackage` and
816+`distutils` are typically built with respectively the `buildPythonPackage` and
517817`buildPythonApplication` functions. These two functions also support installing a `wheel`.
518818
519819All Python packages reside in `pkgs/top-level/python-packages.nix` and all
520−applications elsewhere. In case a package is used as both a library and an application,
521−then the package should be in `pkgs/top-level/python-packages.nix` since only those packages are made
522−available for all interpreter versions. The preferred location for library expressions is in
820+applications elsewhere. In case a package is used as both a library and an
821+application, then the package should be in `pkgs/top-level/python-packages.nix`
822+since only those packages are made available for all interpreter versions. The
823+preferred location for library expressions is in
523824`pkgs/development/python-modules`. It is important that these packages are
524825called from `pkgs/top-level/python-packages.nix` and not elsewhere, to guarantee
525826the right version of the package is built.
@@ -529,25 +830,29 @@ attribute set is created for each available Python interpreter. The available
529830sets are
530831
531832* `pkgs.python27Packages`
532−* `pkgs.python35Packages`
533−* `pkgs.python36Packages`
534833* `pkgs.python37Packages`
834+* `pkgs.python38Packages`
835+* `pkgs.python39Packages`
836+* `pkgs.python310Packages`
837+* `pkgs.python311Packages`
535838* `pkgs.pypyPackages`
536839
537840and the aliases
538841
539842* `pkgs.python2Packages` pointing to `pkgs.python27Packages`
540−* `pkgs.python3Packages` pointing to `pkgs.python37Packages`
843+* `pkgs.python3Packages` pointing to `pkgs.python39Packages`
541844* `pkgs.pythonPackages` pointing to `pkgs.python2Packages`
542845
543−#### `buildPythonPackage` function
846+#### `buildPythonPackage` function {#buildpythonpackage-function}
544847
545848The `buildPythonPackage` function is implemented in
546−`pkgs/development/interpreters/python/build-python-package.nix`
849+`pkgs/development/interpreters/python/mk-python-derivation`
850+using setup hooks.
547851
548852The following is an example:
853+
549854```nix
550−{ lib, buildPythonPackage, fetchPypi, hypothesis, setuptools_scm, attrs, py, setuptools, six, pluggy }:
855+{ lib, buildPythonPackage, fetchPypi, hypothesis, setuptools-scm, attrs, py, setuptools, six, pluggy }:
551856
552857buildPythonPackage rec {
553858 pname = "pytest";
@@ -564,7 +869,7 @@ buildPythonPackage rec {
564869 '';
565870
566871 checkInputs = [ hypothesis ];
567− buildInputs = [ setuptools_scm ];
872+ nativeBuildInputs = [ setuptools-scm ];
568873 propagatedBuildInputs = [ attrs py setuptools six pluggy ];
569874
570875 meta = with lib; {
@@ -584,42 +889,75 @@ The `buildPythonPackage` mainly does four things:
584889 environment variable and add dependent libraries to script's `sys.path`.
585890* In the `installCheck` phase, `${python.interpreter} setup.py test` is ran.
586891
587−As in Perl, dependencies on other Python packages can be specified in the
588−`buildInputs` and `propagatedBuildInputs` attributes. If something is
589−exclusively a build-time dependency, use `buildInputs`; if it is (also) a runtime
590−dependency, use `propagatedBuildInputs`.
591−
592892By default tests are run because `doCheck = true`. Test dependencies, like
593893e.g. the test runner, should be added to `checkInputs`.
594894
595895By default `meta.platforms` is set to the same value
596896as the interpreter unless overridden otherwise.
597897
598−##### `buildPythonPackage` parameters
599−
600−All parameters from `stdenv.mkDerivation` function are still supported. The following are specific to `buildPythonPackage`:
601−
602−* `catchConflicts ? true`: If `true`, abort package build if a package name appears more than once in dependency tree. Default is `true`.
603−* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These are added to `buildInputs` when `doCheck = true`.
604−* `disabled` ? false: If `true`, package is not build for the particular Python interpreter version.
605−* `dontWrapPythonPrograms ? false`: Skip wrapping of python programs.
606−* `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'"].
607−* `format ? "setuptools"`: Format of the source. Valid options are `"setuptools"`, `"flit"`, `"wheel"`, and `"other"`. `"setuptools"` is for when the source has a `setup.py` and `setuptools` is used to build a wheel, `flit`, in case `flit` should be used to build a wheel, and `wheel` in case a wheel is provided. Use `other` when a custom `buildPhase` and/or `installPhase` is needed.
608−* `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"]`.
609−* `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this defaults to `"python3.5-"` for Python 3.5, etc., and in case of applications to `""`.
610−* `pythonPath ? []`: List of packages to be added into `$PYTHONPATH`. Packages in `pythonPath` are not propagated (contrary to `propagatedBuildInputs`).
898+##### `buildPythonPackage` parameters {#buildpythonpackage-parameters}
899+
900+All parameters from `stdenv.mkDerivation` function are still supported. The
901+following are specific to `buildPythonPackage`:
902+
903+* `catchConflicts ? true`: If `true`, abort package build if a package name
904+ appears more than once in dependency tree. Default is `true`.
905+* `disabled` ? false: If `true`, package is not built for the particular Python
906+ interpreter version.
907+* `dontWrapPythonPrograms ? false`: Skip wrapping of Python programs.
908+* `permitUserSite ? false`: Skip setting the `PYTHONNOUSERSITE` environment
909+ variable in wrapped programs.
910+* `format ? "setuptools"`: Format of the source. Valid options are
911+ `"setuptools"`, `"pyproject"`, `"flit"`, `"wheel"`, and `"other"`.
912+ `"setuptools"` is for when the source has a `setup.py` and `setuptools` is
913+ used to build a wheel, `flit`, in case `flit` should be used to build a wheel,
914+ and `wheel` in case a wheel is provided. Use `other` when a custom
915+ `buildPhase` and/or `installPhase` is needed.
916+* `makeWrapperArgs ? []`: A list of strings. Arguments to be passed to
917+ `makeWrapper`, which wraps generated binaries. By default, the arguments to
918+ `makeWrapper` set `PATH` and `PYTHONPATH` environment variables before calling
919+ the binary. Additional arguments here can allow a developer to set environment
920+ variables which will be available when the binary is run. For example,
921+ `makeWrapperArgs = ["--set FOO BAR" "--set BAZ QUX"]`.
922+* `namePrefix`: Prepends text to `${name}` parameter. In case of libraries, this
923+ defaults to `"python3.8-"` for Python 3.8, etc., and in case of applications
924+ to `""`.
925+* `pipInstallFlags ? []`: A list of strings. Arguments to be passed to `pip
926+ install`. To pass options to `python setup.py install`, use
927+ `--install-option`. E.g., `pipInstallFlags=["--install-option='--cpp_implementation'"]`.
928+* `pythonPath ? []`: List of packages to be added into `$PYTHONPATH`. Packages
929+ in `pythonPath` are not propagated (contrary to `propagatedBuildInputs`).
611930* `preShellHook`: Hook to execute commands before `shellHook`.
612931* `postShellHook`: Hook to execute commands after `shellHook`.
613−* `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only created when the filenames end with `.py`.
932+* `removeBinByteCode ? true`: Remove bytecode from `/bin`. Bytecode is only
933+ created when the filenames end with `.py`.
934+* `setupPyGlobalFlags ? []`: List of flags passed to `setup.py` command.
614935* `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command.
615936
616−##### Overriding Python packages
617−
618−The `buildPythonPackage` function has a `overridePythonAttrs` method that
619−can be used to override the package. In the following example we create an
620−environment where we have the `blaze` package using an older version of `pandas`.
621−We override first the Python interpreter and pass
622−`packageOverrides` which contains the overrides for packages in the package set.
937+The `stdenv.mkDerivation` function accepts various parameters for describing
938+build inputs (see "Specifying dependencies"). The following are of special
939+interest for Python packages, either because these are primarily used, or
940+because their behaviour is different:
941+
942+* `nativeBuildInputs ? []`: Build-time only dependencies. Typically executables
943+ as well as the items listed in `setup_requires`.
944+* `buildInputs ? []`: Build and/or run-time dependencies that need to be
945+ compiled for the host machine. Typically non-Python libraries which are being
946+ linked.
947+* `checkInputs ? []`: Dependencies needed for running the `checkPhase`. These
948+ are added to `nativeBuildInputs` when `doCheck = true`. Items listed in
949+ `tests_require` go here.
950+* `propagatedBuildInputs ? []`: Aside from propagating dependencies,
951+ `buildPythonPackage` also injects code into and wraps executables with the
952+ paths included in this list. Items listed in `install_requires` go here.
953+
954+##### Overriding Python packages {#overriding-python-packages}
955+
956+The `buildPythonPackage` function has a `overridePythonAttrs` method that can be
957+used to override the package. In the following example we create an environment
958+where we have the `blaze` package using an older version of `pandas`. We
959+override first the Python interpreter and pass `packageOverrides` which contains
960+the overrides for packages in the package set.
623961
624962```nix
625963with import <nixpkgs> {};
@@ -636,12 +974,37 @@ with import <nixpkgs> {};
636974 };
637975 });
638976 };
639− in pkgs.python3.override {inherit packageOverrides;};
977+ in pkgs.python3.override {inherit packageOverrides; self = python;};
640978
641979in python.withPackages(ps: [ps.blaze])).env
642980```
643981
644−#### `buildPythonApplication` function
982+#### Optional extra dependencies
983+
984+Some packages define optional dependencies for additional features. With
985+`setuptools` this is called `extras_require` and `flit` calls it `extras-require`. A
986+method for supporting this is by declaring the extras of a package in its
987+`passthru`, e.g. in case of the package `dask`
988+
989+```nix
990+passthru.extras-require = {
991+ complete = [ distributed ];
992+};
993+```
994+
995+and letting the package requiring the extra add the list to its dependencies
996+
997+```nix
998+propagatedBuildInputs = [
999+ ...
1000+] ++ dask.extras-require.complete;
1001+```
1002+
1003+Note this method is preferred over adding parameters to builders, as that can
1004+result in packages depending on different variants and thereby causing
1005+collisions.
1006+
1007+#### `buildPythonApplication` function {#buildpythonapplication-function}
6451008
6461009The `buildPythonApplication` function is practically the same as
6471010`buildPythonPackage`. The main purpose of this function is to build a Python
@@ -653,23 +1016,23 @@ Another difference is that `buildPythonPackage` by default prefixes the names of
6531016the packages with the version of the interpreter. Because this is irrelevant for
6541017applications, the prefix is omitted.
6551018
656−When packaging a python application with `buildPythonApplication`, it should be
1019+When packaging a Python application with `buildPythonApplication`, it should be
6571020called with `callPackage` and passed `python` or `pythonPackages` (possibly
6581021specifying an interpreter version), like this:
6591022
6601023```nix
661−{ lib, python3Packages }:
1024+{ lib, python3 }:
6621025
663−python3Packages.buildPythonApplication rec {
1026+python3.pkgs.buildPythonApplication rec {
6641027 pname = "luigi";
6651028 version = "2.7.9";
6661029
667− src = python3Packages.fetchPypi {
1030+ src = python3.pkgs.fetchPypi {
6681031 inherit pname version;
6691032 sha256 = "035w8gqql36zlan0xjrzz9j4lh9hs0qrsgnbyw07qs7lnkvbdv9x";
6701033 };
6711034
672− propagatedBuildInputs = with python3Packages; [ tornado_4 python-daemon ];
1035+ propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
6731036
6741037 meta = with lib; {
6751038 ...
@@ -684,9 +1047,9 @@ luigi = callPackage ../applications/networking/cluster/luigi { };
6841047```
6851048
6861049Since the package is an application, a consumer doesn't need to care about
687−python versions or modules, which is why they don't go in `pythonPackages`.
1050+Python versions or modules, which is why they don't go in `pythonPackages`.
6881051
689−#### `toPythonApplication` function
1052+#### `toPythonApplication` function {#topythonapplication-function}
6901053
6911054A distinction is made between applications and libraries, however, sometimes a
6921055package is used as both. In this case the package is added as a library to
@@ -698,39 +1061,45 @@ The Nix expression shall use `buildPythonPackage` and be called from
6981061`python-packages.nix`. A reference shall be created from `all-packages.nix` to
6991062the attribute in `python-packages.nix`, and the `toPythonApplication` shall be
7001063applied to the reference:
1064+
7011065```nix
7021066youtube-dl = with pythonPackages; toPythonApplication youtube-dl;
7031067```
7041068
705−#### `toPythonModule` function
1069+#### `toPythonModule` function {#topythonmodule-function}
7061070
7071071In some cases, such as bindings, a package is created using
708−`stdenv.mkDerivation` and added as attribute in `all-packages.nix`.
709−The Python bindings should be made available from `python-packages.nix`.
710−The `toPythonModule` function takes a derivation and makes certain Python-specific modifications.
1072+`stdenv.mkDerivation` and added as attribute in `all-packages.nix`. The Python
1073+bindings should be made available from `python-packages.nix`. The
1074+`toPythonModule` function takes a derivation and makes certain Python-specific
1075+modifications.
1076+
7111077```nix
7121078opencv = toPythonModule (pkgs.opencv.override {
7131079 enablePython = true;
7141080 pythonPackages = self;
7151081});
7161082```
1083+
7171084Do pay attention to passing in the right Python version!
7181085
719−#### `python.buildEnv` function
1086+#### `python.buildEnv` function {#python.buildenv-function}
7201087
7211088Python environments can be created using the low-level `pkgs.buildEnv` function.
7221089This example shows how to create an environment that has the Pyramid Web Framework.
7231090Saving the following as `default.nix`
1091+
7241092```nix
7251093with import <nixpkgs> {};
7261094
7271095python.buildEnv.override {
728− extraLibs = [ pkgs.pythonPackages.pyramid ];
1096+ extraLibs = [ pythonPackages.pyramid ];
7291097 ignoreCollisions = true;
7301098}
7311099```
7321100
7331101and running `nix-build` will create
1102+
7341103```
7351104/nix/store/cf1xhjwzmdki7fasgr4kz6di72ykicl5-python-2.7.8-env
7361105```
@@ -740,6 +1109,7 @@ with wrapped binaries in `bin/`.
7401109You can also use the `env` attribute to create local environments with needed
7411110packages installed. This is somewhat comparable to `virtualenv`. For example,
7421111running `nix-shell` with the following `shell.nix`
1112+
7431113```nix
7441114with import <nixpkgs> {};
7451115
@@ -751,28 +1121,32 @@ with import <nixpkgs> {};
7511121will drop you into a shell where Python will have the
7521122specified packages in its path.
7531123
1124+##### `python.buildEnv` arguments {#python.buildenv-arguments}
7541125
755−##### `python.buildEnv` arguments
7561126
7571127* `extraLibs`: List of packages installed inside the environment.
7581128* `postBuild`: Shell command executed after the build of environment.
7591129* `ignoreCollisions`: Ignore file collisions inside the environment (default is `false`).
1130+* `permitUserSite`: Skip setting the `PYTHONNOUSERSITE` environment variable in
1131+ wrapped binaries in the environment.
7601132
761−#### `python.withPackages` function
1133+#### `python.withPackages` function {#python.withpackages-function}
7621134
7631135The `python.withPackages` function provides a simpler interface to the `python.buildEnv` functionality.
7641136It takes a function as an argument that is passed the set of python packages and returns the list
7651137of the packages to be included in the environment. Using the `withPackages` function, the previous
7661138example for the Pyramid Web Framework environment can be written like this:
1139+
7671140```nix
7681141with import <nixpkgs> {};
7691142
7701143python.withPackages (ps: [ps.pyramid])
7711144```
7721145
773−`withPackages` passes the correct package set for the specific interpreter version as an
774−argument to the function. In the above example, `ps` equals `pythonPackages`.
775−But you can also easily switch to using python3:
1146+`withPackages` passes the correct package set for the specific interpreter
1147+version as an argument to the function. In the above example, `ps` equals
1148+`pythonPackages`. But you can also easily switch to using python3:
1149+
7761150```nix
7771151with import <nixpkgs> {};
7781152
@@ -781,21 +1155,49 @@ python3.withPackages (ps: [ps.pyramid])
7811155
7821156Now, `ps` is set to `python3Packages`, matching the version of the interpreter.
7831157
784−As `python.withPackages` simply uses `python.buildEnv` under the hood, it also supports the `env`
785−attribute. The `shell.nix` file from the previous section can thus be also written like this:
1158+As `python.withPackages` simply uses `python.buildEnv` under the hood, it also
1159+supports the `env` attribute. The `shell.nix` file from the previous section can
1160+thus be also written like this:
1161+
7861162```nix
7871163with import <nixpkgs> {};
7881164
789−(python36.withPackages (ps: [ps.numpy ps.requests])).env
1165+(python38.withPackages (ps: [ps.numpy ps.requests])).env
7901166```
7911167
792−In contrast to `python.buildEnv`, `python.withPackages` does not support the more advanced options
793−such as `ignoreCollisions = true` or `postBuild`. If you need them, you have to use `python.buildEnv`.
794−
795−Python 2 namespace packages may provide `__init__.py` that collide. In that case `python.buildEnv`
796−should be used with `ignoreCollisions = true`.
797−
798−### Development mode
1168+In contrast to `python.buildEnv`, `python.withPackages` does not support the
1169+more advanced options such as `ignoreCollisions = true` or `postBuild`. If you
1170+need them, you have to use `python.buildEnv`.
1171+
1172+Python 2 namespace packages may provide `__init__.py` that collide. In that case
1173+`python.buildEnv` should be used with `ignoreCollisions = true`.
1174+
1175+#### Setup hooks {#setup-hooks}
1176+
1177+The following are setup hooks specifically for Python packages. Most of these
1178+are used in `buildPythonPackage`.
1179+
1180+- `eggUnpackhook` to move an egg to the correct folder so it can be installed
1181+ with the `eggInstallHook`
1182+- `eggBuildHook` to skip building for eggs.
1183+- `eggInstallHook` to install eggs.
1184+- `flitBuildHook` to build a wheel using `flit`.
1185+- `pipBuildHook` to build a wheel using `pip` and PEP 517. Note a build system
1186+ (e.g. `setuptools` or `flit`) should still be added as `nativeBuildInput`.
1187+- `pipInstallHook` to install wheels.
1188+- `pytestCheckHook` to run tests with `pytest`. See [example usage](#using-pytestcheckhook).
1189+- `pythonCatchConflictsHook` to check whether a Python package is not already existing.
1190+- `pythonImportsCheckHook` to check whether importing the listed modules works.
1191+- `pythonRemoveBinBytecode` to remove bytecode from the `/bin` folder.
1192+- `setuptoolsBuildHook` to build a wheel using `setuptools`.
1193+- `setuptoolsCheckHook` to run tests with `python setup.py test`.
1194+- `venvShellHook` to source a Python 3 `venv` at the `venvDir` location. A
1195+ `venv` is created if it does not yet exist. `postVenvCreation` can be used to
1196+ to run commands only after venv is first created.
1197+- `wheelUnpackHook` to move a wheel to the correct folder so it can be installed
1198+ with the `pipInstallHook`.
1199+
1200+### Development mode {#development-mode}
7991201
8001202Development or editable mode is supported. To develop Python packages
8011203`buildPythonPackage` has additional logic inside `shellPhase` to run `pip
@@ -804,50 +1206,54 @@ install -e . --prefix $TMPDIR/`for the package.
8041206Warning: `shellPhase` is executed only if `setup.py` exists.
8051207
8061208Given a `default.nix`:
1209+
8071210```nix
8081211with import <nixpkgs> {};
8091212
810−buildPythonPackage { name = "myproject";
1213+pythonPackages.buildPythonPackage {
1214+ name = "myproject";
1215+ buildInputs = with pythonPackages; [ pyramid ];
8111216
812−buildInputs = with pkgs.pythonPackages; [ pyramid ];
813−
814−src = ./.; }
1217+ src = ./.;
1218+}
8151219```
8161220
817−Running `nix-shell` with no arguments should give you
818−the environment in which the package would be built with
819−`nix-build`.
1221+Running `nix-shell` with no arguments should give you the environment in which
1222+the package would be built with `nix-build`.
1223+
1224+Shortcut to setup environments with C headers/libraries and Python packages:
8201225
821−Shortcut to setup environments with C headers/libraries and python packages:
8221226```shell
8231227nix-shell -p pythonPackages.pyramid zlib libjpeg git
8241228```
8251229
8261230Note: There is a boolean value `lib.inNixShell` set to `true` if nix-shell is invoked.
8271231
828−### Tools
1232+### Tools {#tools}
8291233
8301234Packages inside nixpkgs are written by hand. However many tools exist in
8311235community to help save time. No tool is preferred at the moment.
8321236
833−- [python2nix](https://github.com/proger/python2nix) by Vladimir Kirillov
834−- [pypi2nix](https://github.com/garbas/pypi2nix) by Rok Garbas
835−- [pypi2nix](https://github.com/offlinehacker/pypi2nix) by Jaka Hudoklin
1237+- [pypi2nix](https://github.com/nix-community/pypi2nix): Generate Nix
1238+ expressions for your Python project. Note that [sharing derivations from
1239+ pypi2nix with nixpkgs is possible but not
1240+ encouraged](https://github.com/nix-community/pypi2nix/issues/222#issuecomment-443497376).
1241+- [nixpkgs-pytools](https://github.com/nix-community/nixpkgs-pytools)
1242+- [poetry2nix](https://github.com/nix-community/poetry2nix)
8361243
837−### Deterministic builds
1244+### Deterministic builds {#deterministic-builds}
8381245
839−The Python interpreters are now built deterministically.
840−Minor modifications had to be made to the interpreters in order to generate
841−deterministic bytecode. This has security implications and is relevant for
842−those using Python in a `nix-shell`.
1246+The Python interpreters are now built deterministically. Minor modifications had
1247+to be made to the interpreters in order to generate deterministic bytecode. This
1248+has security implications and is relevant for those using Python in a
1249+`nix-shell`.
8431250
844−When the environment variable `DETERMINISTIC_BUILD` is set, all bytecode will have timestamp 1.
845−The `buildPythonPackage` function sets `DETERMINISTIC_BUILD=1` and
846−[PYTHONHASHSEED=0](https://docs.python.org/3.5/using/cmdline.html#envvar-PYTHONHASHSEED).
1251+When the environment variable `DETERMINISTIC_BUILD` is set, all bytecode will
1252+have timestamp 1. The `buildPythonPackage` function sets `DETERMINISTIC_BUILD=1`
1253+and [PYTHONHASHSEED=0](https://docs.python.org/3.8/using/cmdline.html#envvar-PYTHONHASHSEED).
8471254Both are also exported in `nix-shell`.
8481255
849−
850−### Automatic tests
1256+### Automatic tests {#automatic-tests}
8511257
8521258It is recommended to test packages as part of the build process.
8531259Source distributions (`sdist`) often include test files, but not always.
@@ -856,11 +1262,12 @@ By default the command `python setup.py test` is run as part of the
8561262`checkPhase`, but often it is necessary to pass a custom `checkPhase`. An
8571263example of such a situation is when `py.test` is used.
8581264
859−#### Common issues
1265+#### Common issues {#common-issues}
8601266
861−- Non-working tests can often be deselected. By default `buildPythonPackage` runs `python setup.py test`.
862− Most python modules follows the standard test protocol where the pytest runner can be used instead.
863− `py.test` supports a `-k` parameter to ignore test methods or classes:
1267+* Non-working tests can often be deselected. By default `buildPythonPackage`
1268+ runs `python setup.py test`. Most Python modules follows the standard test
1269+ protocol where the pytest runner can be used instead. `py.test` supports a
1270+ `-k` parameter to ignore test methods or classes:
8641271
8651272 ```nix
8661273 buildPythonPackage {
@@ -872,21 +1279,23 @@ example of such a situation is when `py.test` is used.
8721279 '';
8731280 }
8741281 ```
875−- Unicode issues can typically be fixed by including `glibcLocales` in `buildInputs` and exporting `LC_ALL=en_US.utf-8`.
876−- Tests that attempt to access `$HOME` can be fixed by using the following work-around before running tests (e.g. `preCheck`): `export HOME=$(mktemp -d)`
8771282
878−## FAQ
1283+* Tests that attempt to access `$HOME` can be fixed by using the following
1284+ work-around before running tests (e.g. `preCheck`): `export HOME=$(mktemp -d)`
8791285
880−### How to solve circular dependencies?
1286+## FAQ {#faq}
1287+
1288+### How to solve circular dependencies? {#how-to-solve-circular-dependencies}
8811289
8821290Consider the packages `A` and `B` that depend on each other. When packaging `B`,
8831291a solution is to override package `A` not to depend on `B` as an input. The same
8841292should also be done when packaging `A`.
8851293
886−### How to override a Python package?
1294+### How to override a Python package? {#how-to-override-a-python-package}
1295+
1296+We can override the interpreter and pass `packageOverrides`. In the following
1297+example we rename the `pandas` package and build it.
8871298
888−We can override the interpreter and pass `packageOverrides`.
889−In the following example we rename the `pandas` package and build it.
8901299```nix
8911300with import <nixpkgs> {};
8921301
@@ -895,18 +1304,20 @@ with import <nixpkgs> {};
8951304 packageOverrides = self: super: {
8961305 pandas = super.pandas.overridePythonAttrs(old: {name="foo";});
8971306 };
898− in pkgs.python35.override {inherit packageOverrides;};
1307+ in pkgs.python38.override {inherit packageOverrides;};
8991308
9001309in python.withPackages(ps: [ps.pandas])).env
9011310```
1311+
9021312Using `nix-build` on this expression will build an environment that contains the
9031313package `pandas` but with the new name `foo`.
9041314
905−All packages in the package set will use the renamed package.
906−A typical use case is to switch to another version of a certain package.
907−For example, in the Nixpkgs repository we have multiple versions of `django` and `scipy`.
908−In the following example we use a different version of `scipy` and create an environment that uses it.
909−All packages in the Python package set will now use the updated `scipy` version.
1315+All packages in the package set will use the renamed package. A typical use case
1316+is to switch to another version of a certain package. For example, in the
1317+Nixpkgs repository we have multiple versions of `django` and `scipy`. In the
1318+following example we use a different version of `scipy` and create an
1319+environment that uses it. All packages in the Python package set will now use
1320+the updated `scipy` version.
9101321
9111322```nix
9121323with import <nixpkgs> {};
@@ -915,66 +1326,83 @@ with import <nixpkgs> {};
9151326 packageOverrides = self: super: {
9161327 scipy = super.scipy_0_17;
9171328 };
918− in (pkgs.python35.override {inherit packageOverrides;}).withPackages (ps: [ps.blaze])
1329+ in (pkgs.python38.override {inherit packageOverrides;}).withPackages (ps: [ps.blaze])
9191330).env
9201331```
1332+
9211333The requested package `blaze` depends on `pandas` which itself depends on `scipy`.
9221334
923−If you want the whole of Nixpkgs to use your modifications, then you can use `overlays`
924−as explained in this manual. In the following example we build a `inkscape` using a different version of `numpy`.
1335+If you want the whole of Nixpkgs to use your modifications, then you can use
1336+`overlays` as explained in this manual. In the following example we build a
1337+`inkscape` using a different version of `numpy`.
1338+
9251339```nix
9261340let
9271341 pkgs = import <nixpkgs> {};
928− newpkgs = import pkgs.path { overlays = [ (pkgsself: pkgssuper: {
929− python27 = let
930− packageOverrides = self: super: {
931− numpy = super.numpy_1_10;
1342+ newpkgs = import pkgs.path { overlays = [ (self: super: {
1343+ python38 = let
1344+ packageOverrides = python-self: python-super: {
1345+ numpy = python-super.numpy_1_18;
9321346 };
933− in pkgssuper.python27.override {inherit packageOverrides;};
1347+ in super.python38.override {inherit packageOverrides;};
9341348 } ) ]; };
9351349in newpkgs.inkscape
9361350```
9371351
938−### `python setup.py bdist_wheel` cannot create .whl
1352+### `python setup.py bdist_wheel` cannot create .whl {#python-setup.py-bdist_wheel-cannot-create-.whl}
9391353
9401354Executing `python setup.py bdist_wheel` in a `nix-shell `fails with
9411355```
9421356ValueError: ZIP does not support timestamps before 1980
9431357```
9441358
945−This is because files from the Nix store (which have a timestamp of the UNIX epoch of January 1, 1970) are included in the .ZIP, but .ZIP archives follow the DOS convention of counting timestamps from 1980.
1359+This is because files from the Nix store (which have a timestamp of the UNIX
1360+epoch of January 1, 1970) are included in the .ZIP, but .ZIP archives follow the
1361+DOS convention of counting timestamps from 1980.
9461362
947−The command `bdist_wheel` reads the `SOURCE_DATE_EPOCH` environment variable, which `nix-shell` sets to 1. Unsetting this variable or giving it a value corresponding to 1980 or later enables building wheels.
1363+The command `bdist_wheel` reads the `SOURCE_DATE_EPOCH` environment variable,
1364+which `nix-shell` sets to 1. Unsetting this variable or giving it a value
1365+corresponding to 1980 or later enables building wheels.
9481366
9491367Use 1980 as timestamp:
1368+
9501369```shell
9511370nix-shell --run "SOURCE_DATE_EPOCH=315532800 python3 setup.py bdist_wheel"
9521371```
1372+
9531373or the current time:
1374+
9541375```shell
9551376nix-shell --run "SOURCE_DATE_EPOCH=$(date +%s) python3 setup.py bdist_wheel"
9561377```
1378+
9571379or unset `SOURCE_DATE_EPOCH`:
1380+
9581381```shell
9591382nix-shell --run "unset SOURCE_DATE_EPOCH; python3 setup.py bdist_wheel"
9601383```
9611384
962−### `install_data` / `data_files` problems
1385+### `install_data` / `data_files` problems {#install_data-data_files-problems}
9631386
9641387If you get the following error:
1388+
9651389```
9661390could not create '/nix/store/6l1bvljpy8gazlsw2aw9skwwp4pmvyxw-python-2.7.8/etc':
9671391Permission denied
9681392```
969−This is a [known bug](https://github.com/pypa/setuptools/issues/130) in `setuptools`.
970−Setuptools `install_data` does not respect `--prefix`. An example of such package using the feature is `pkgs/tools/X11/xpra/default.nix`.
1393+
1394+This is a [known bug](https://github.com/pypa/setuptools/issues/130) in
1395+`setuptools`. Setuptools `install_data` does not respect `--prefix`. An example
1396+of such package using the feature is `pkgs/tools/X11/xpra/default.nix`.
1397+
9711398As workaround install it as an extra `preInstall` step:
1399+
9721400```shell
9731401${python.interpreter} setup.py install_data --install-dir=$out --root=$out
9741402sed -i '/ = data\_files/d' setup.py
9751403```
9761404
977−### Rationale of non-existent global site-packages
1405+### Rationale of non-existent global site-packages {#rationale-of-non-existent-global-site-packages}
9781406
9791407On most operating systems a global `site-packages` is maintained. This however
9801408becomes problematic if you want to run multiple Python versions or have multiple
@@ -989,56 +1417,120 @@ If you want to create a Python environment for development, then the recommended
9891417method is to use `nix-shell`, either with or without the `python.buildEnv`
9901418function.
9911419
992−### How to consume python modules using pip in a virtualenv like I am used to on other Operating Systems ?
1420+### How to consume Python modules using pip in a virtual environment like I am used to on other Operating Systems? {#how-to-consume-python-modules-using-pip-in-a-virtual-environment-like-i-am-used-to-on-other-operating-systems}
9931421
994−This is an example of a `default.nix` for a `nix-shell`, which allows to consume a `virtualenv` environment,
995−and install python modules through `pip` the traditional way.
1422+While this approach is not very idiomatic from Nix perspective, it can still be
1423+useful when dealing with pre-existing projects or in situations where it's not
1424+feasible or desired to write derivations for all required dependencies.
9961425
997−Create this `default.nix` file, together with a `requirements.txt` and simply execute `nix-shell`.
1426+This is an example of a `default.nix` for a `nix-shell`, which allows to consume
1427+a virtual environment created by `venv`, and install Python modules through
1428+`pip` the traditional way.
1429+
1430+Create this `default.nix` file, together with a `requirements.txt` and simply
1431+execute `nix-shell`.
9981432
9991433```nix
1000−with import <nixpkgs> {};
1001−with pkgs.python27Packages;
1434+with import <nixpkgs> { };
10021435
1003−stdenv.mkDerivation {
1436+let
1437+ pythonPackages = python3Packages;
1438+in pkgs.mkShell rec {
10041439 name = "impurePythonEnv";
1440+ venvDir = "./.venv";
10051441 buildInputs = [
1006− # these packages are required for virtualenv and pip to work:
1007− #
1008− python27Full
1009− python27Packages.virtualenv
1010− python27Packages.pip
1011− # the following packages are related to the dependencies of your python
1012− # project.
1013− # In this particular example the python modules listed in the
1014− # requirements.txt require the following packages to be installed locally
1015− # in order to compile any binary extensions they may require.
1016− #
1442+ # A Python interpreter including the 'venv' module is required to bootstrap
1443+ # the environment.
1444+ pythonPackages.python
1445+
1446+ # This execute some shell code to initialize a venv in $venvDir before
1447+ # dropping into the shell
1448+ pythonPackages.venvShellHook
1449+
1450+ # Those are dependencies that we would like to use from nixpkgs, which will
1451+ # add them to PYTHONPATH and thus make them accessible from within the venv.
1452+ pythonPackages.numpy
1453+ pythonPackages.requests
1454+
1455+ # In this particular example, in order to compile any binary extensions they may
1456+ # require, the Python modules listed in the hypothetical requirements.txt need
1457+ # the following packages to be installed locally:
10171458 taglib
10181459 openssl
10191460 git
10201461 libxml2
10211462 libxslt
10221463 libzip
1023− stdenv
1024− zlib ];
1025− src = null;
1464+ zlib
1465+ ];
1466+
1467+ # Run this command, only after creating the virtual environment
1468+ postVenvCreation = ''
1469+ unset SOURCE_DATE_EPOCH
1470+ pip install -r requirements.txt
1471+ '';
1472+
1473+ # Now we can execute any commands within the virtual environment.
1474+ # This is optional and can be left out to run pip manually.
1475+ postShellHook = ''
1476+ # allow pip to install wheels
1477+ unset SOURCE_DATE_EPOCH
1478+ '';
1479+
1480+}
1481+```
1482+
1483+In case the supplied venvShellHook is insufficient, or when Python 2 support is
1484+needed, you can define your own shell hook and adapt to your needs like in the
1485+following example:
1486+
1487+```nix
1488+with import <nixpkgs> { };
1489+
1490+let
1491+ venvDir = "./.venv";
1492+ pythonPackages = python3Packages;
1493+in pkgs.mkShell rec {
1494+ name = "impurePythonEnv";
1495+ buildInputs = [
1496+ pythonPackages.python
1497+ # Needed when using python 2.7
1498+ # pythonPackages.virtualenv
1499+ # ...
1500+ ];
1501+
1502+ # This is very close to how venvShellHook is implemented, but
1503+ # adapted to use 'virtualenv'
10261504 shellHook = ''
1027− # set SOURCE_DATE_EPOCH so that we can use python wheels
1028− SOURCE_DATE_EPOCH=$(date +%s)
1029− virtualenv --no-setuptools venv
1030− export PATH=$PWD/venv/bin:$PATH
1031− pip install -r requirements.txt
1505+ SOURCE_DATE_EPOCH=$(date +%s)
1506+
1507+ if [ -d "${venvDir}" ]; then
1508+ echo "Skipping venv creation, '${venvDir}' already exists"
1509+ else
1510+ echo "Creating new venv environment in path: '${venvDir}'"
1511+ # Note that the module venv was only introduced in python 3, so for 2.7
1512+ # this needs to be replaced with a call to virtualenv
1513+ ${pythonPackages.python.interpreter} -m venv "${venvDir}"
1514+ fi
1515+
1516+ # Under some circumstances it might be necessary to add your virtual
1517+ # environment to PYTHONPATH, which you can do here too;
1518+ # PYTHONPATH=$PWD/${venvDir}/${pythonPackages.python.sitePackages}/:$PYTHONPATH
1519+
1520+ source "${venvDir}/bin/activate"
1521+
1522+ # As in the previous example, this is optional.
1523+ pip install -r requirements.txt
10321524 '';
10331525}
10341526```
10351527
10361528Note that the `pip install` is an imperative action. So every time `nix-shell`
1037−is executed it will attempt to download the python modules listed in
1529+is executed it will attempt to download the Python modules listed in
10381530requirements.txt. However these will be cached locally within the `virtualenv`
10391531folder and not downloaded again.
10401532
1041−### How to override a Python package from `configuration.nix`?
1533+### How to override a Python package from `configuration.nix`? {#how-to-override-a-python-package-from-configuration.nix}
10421534
10431535If you need to change a package's attribute(s) from `configuration.nix` you could do:
10441536
@@ -1046,11 +1538,12 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
10461538 nixpkgs.config.packageOverrides = super: {
10471539 python = super.python.override {
10481540 packageOverrides = python-self: python-super: {
1049− zerobin = python-super.zerobin.overrideAttrs (oldAttrs: {
1050− src = super.fetchgit {
1051− url = "https://github.com/sametmax/0bin";
1052− rev = "a344dbb18fe7a855d0742b9a1cede7ce423b34ec";
1053− sha256 = "16d769kmnrpbdr0ph0whyf4yff5df6zi4kmwx7sz1d3r6c8p6xji";
1541+ twisted = python-super.twisted.overrideAttrs (oldAttrs: {
1542+ src = super.fetchPypi {
1543+ pname = "twisted";
1544+ version = "19.10.0";
1545+ sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
1546+ extension = "tar.bz2";
10541547 };
10551548 });
10561549 };
@@ -1058,22 +1551,24 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
10581551 };
10591552```
10601553
1061−`pythonPackages.zerobin` is now globally overridden. All packages and also the
1062−`zerobin` NixOS service use the new definition.
1554+`pythonPackages.twisted` is now globally overridden.
1555+All packages and also all NixOS services that reference `twisted`
1556+(such as `services.buildbot-worker`) now use the new definition.
10631557Note that `python-super` refers to the old package set and `python-self`
10641558to the new, overridden version.
10651559
1066−To modify only a Python package set instead of a whole Python derivation, use this snippet:
1560+To modify only a Python package set instead of a whole Python derivation, use
1561+this snippet:
10671562
10681563```nix
10691564 myPythonPackages = pythonPackages.override {
10701565 overrides = self: super: {
1071− zerobin = ...;
1566+ twisted = ...;
10721567 };
10731568 }
10741569```
10751570
1076−### How to override a Python package using overlays?
1571+### How to override a Python package using overlays? {#how-to-override-a-python-package-using-overlays}
10771572
10781573Use the following overlay template:
10791574
@@ -1081,11 +1576,12 @@ Use the following overlay template:
10811576self: super: {
10821577 python = super.python.override {
10831578 packageOverrides = python-self: python-super: {
1084− zerobin = python-super.zerobin.overrideAttrs (oldAttrs: {
1085− src = super.fetchgit {
1086− url = "https://github.com/sametmax/0bin";
1087− rev = "a344dbb18fe7a855d0742b9a1cede7ce423b34ec";
1088− sha256 = "16d769kmnrpbdr0ph0whyf4yff5df6zi4kmwx7sz1d3r6c8p6xji";
1579+ twisted = python-super.twisted.overrideAttrs (oldAttrs: {
1580+ src = super.fetchPypi {
1581+ pname = "twisted";
1582+ version = "19.10.0";
1583+ sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
1584+ extension = "tar.bz2";
10891585 };
10901586 });
10911587 };
@@ -1093,35 +1589,94 @@ self: super: {
10931589}
10941590```
10951591
1096−### How to use Intel's MKL with numpy and scipy?
1592+### How to use Intel’s MKL with numpy and scipy? {#how-to-use-intels-mkl-with-numpy-and-scipy}
10971593
1098−A `site.cfg` is created that configures BLAS based on the `blas` parameter
1099−of the `numpy` derivation. By passing in `mkl`, `numpy` and packages depending
1100−on `numpy` will be built with `mkl`.
1594+MKL can be configured using an overlay. See the section "[Using overlays to
1595+configure alternatives](#sec-overlays-alternatives-blas-lapack)".
11011596
1102−The following is an overlay that configures `numpy` to use `mkl`:
1103−```nix
1104−self: super: {
1105− python36 = super.python36.override {
1106− packageOverrides = python-self: python-super: {
1107− numpy = python-super.numpy.override {
1108− blas = super.pkgs.mkl;
1109− };
1110− };
1111− };
1112−}
1113−```
1597+### What inputs do `setup_requires`, `install_requires` and `tests_require` map to? {#what-inputs-do-setup_requires-install_requires-and-tests_require-map-to}
1598+
1599+In a `setup.py` or `setup.cfg` it is common to declare dependencies:
11141600
1115−## Contributing
1601+* `setup_requires` corresponds to `nativeBuildInputs`
1602+* `install_requires` corresponds to `propagatedBuildInputs`
1603+* `tests_require` corresponds to `checkInputs`
11161604
1117−### Contributing guidelines
1605+## Contributing {#contributing}
11181606
1119−Following rules are desired to be respected:
1607+### Contributing guidelines {#contributing-guidelines}
11201608
1121−* Python libraries are called from `python-packages.nix` and packaged with `buildPythonPackage`. The expression of a library should be in `pkgs/development/python-modules/<name>/default.nix`. Libraries in `pkgs/top-level/python-packages.nix` are sorted quasi-alphabetically to avoid merge conflicts.
1122−* Python applications live outside of `python-packages.nix` and are packaged with `buildPythonApplication`.
1609+The following rules are desired to be respected:
1610+
1611+* Python libraries are called from `python-packages.nix` and packaged with
1612+ `buildPythonPackage`. The expression of a library should be in
1613+ `pkgs/development/python-modules/<name>/default.nix`.
1614+* Python applications live outside of `python-packages.nix` and are packaged
1615+ with `buildPythonApplication`.
11231616* Make sure libraries build for all Python interpreters.
1124−* By default we enable tests. Make sure the tests are found and, in the case of libraries, are passing for all interpreters. If certain tests fail they can be disabled individually. Try to avoid disabling the tests altogether. In any case, when you disable tests, leave a comment explaining why.
1125−* Commit names of Python libraries should reflect that they are Python libraries, so write for example `pythonPackages.numpy: 1.11 -> 1.12`.
1126−* Attribute names in `python-packages.nix` should be normalized according to [PEP 0503](https://www.python.org/dev/peps/pep-0503/#normalized-names).
1127− This means that characters should be converted to lowercase and `.` and `_` should be replaced by a single `-` (foo-bar-baz instead of Foo__Bar.baz )
1617+* By default we enable tests. Make sure the tests are found and, in the case of
1618+ libraries, are passing for all interpreters. If certain tests fail they can be
1619+ disabled individually. Try to avoid disabling the tests altogether. In any
1620+ case, when you disable tests, leave a comment explaining why.
1621+* Commit names of Python libraries should reflect that they are Python
1622+ libraries, so write for example `pythonPackages.numpy: 1.11 -> 1.12`.
1623+* Attribute names in `python-packages.nix` as well as `pname`s should match the
1624+ library's name on PyPI, but be normalized according to [PEP
1625+ 0503](https://www.python.org/dev/peps/pep-0503/#normalized-names). This means
1626+ that characters should be converted to lowercase and `.` and `_` should be
1627+ replaced by a single `-` (foo-bar-baz instead of Foo__Bar.baz).
1628+ If necessary, `pname` has to be given a different value within `fetchPypi`.
1629+* Attribute names in `python-packages.nix` should be sorted alphanumerically to
1630+ avoid merge conflicts and ease locating attributes.
1631+
1632+## Package set maintenance
1633+
1634+The whole Python package set has a lot of packages that do not see regular
1635+updates, because they either are a very fragile component in the Python
1636+ecosystem, like for example the `hypothesis` package, or packages that have
1637+no maintainer, so maintenance falls back to the package set maintainers.
1638+
1639+### Updating packages in bulk
1640+
1641+There is a tool to update alot of python libraries in bulk, it exists at
1642+`maintainers/scripts/update-python-libraries` with this repository.
1643+
1644+It can quickly update minor or major versions for all packages selected
1645+and create update commits, and supports the `fetchPypi`, `fetchurl` and
1646+`fetchFromGitHub` fetchers. When updating lots of packages that are
1647+hosted on GitHub, exporting a `GITHUB_API_TOKEN` is highly recommended.
1648+
1649+Updating packages in bulk leads to lots of breakages, which is why a
1650+stabilization period on the `python-unstable` branch is required.
1651+
1652+Once the branch is sufficiently stable it should normally be merged
1653+into the `staging` branch.
1654+
1655+An exemplary call to update all python libraries between minor versions
1656+would be:
1657+
1658+```ShellSession
1659+$ maintainers/scripts/update-python-libraries --target minor --commit --use-pkgs-prefix pkgs/development/python-modules/**/default.nix
1660+```
1661+
1662+## CPython Update Schedule
1663+
1664+With [PEP 602](https://www.python.org/dev/peps/pep-0602/), CPython now
1665+follows a yearly release cadence. In nixpkgs, all supported interpreters
1666+are made available, but only the most recent two
1667+interpreters package sets are built; this is a compromise between being
1668+the latest interpreter, and what the majority of the Python packages support.
1669+
1670+New CPython interpreters are released in October. Generally, it takes some
1671+time for the majority of active Python projects to support the latest stable
1672+interpreter. To help ease the migration for Nixpkgs users
1673+between Python interpreters the schedule below will be used:
1674+
1675+| When | Event |
1676+| --- | --- |
1677+| After YY.11 Release | Bump CPython package set window. The latest and previous latest stable should now be built. |
1678+| After YY.05 Release | Bump default CPython interpreter to latest stable. |
1679+
1680+In practice, this means that the Python community will have had a stable interpreter
1681+for ~2 months before attempting to update the package set. And this will
1682+allow for ~7 months for Python applications to support the latest interpreter.
doc/languages-frameworks/qt.section.mdnew file+160
@@ -0,0 +1,160 @@
1+# Qt {#sec-language-qt}
2+
3+Writing Nix expressions for Qt libraries and applications is largely similar as for other C++ software.
4+This section assumes some knowledge of the latter.
5+There are two problems that the Nixpkgs Qt infrastructure addresses,
6+which are not shared by other C++ software:
7+
8+1. There are usually multiple supported versions of Qt in Nixpkgs.
9+ All of a package's dependencies must be built with the same version of Qt.
10+ This is similar to the version constraints imposed on interpreted languages like Python.
11+2. Qt makes extensive use of runtime dependency detection.
12+ Runtime dependencies are made into build dependencies through wrappers.
13+
14+## Nix expression for a Qt package (default.nix) {#qt-default-nix}
15+
16+```{=docbook}
17+<programlisting>
18+{ stdenv, lib, qtbase, wrapQtAppsHook }: <co xml:id='qt-default-nix-co-1' />
19+
20+stdenv.mkDerivation {
21+ pname = "myapp";
22+ version = "1.0";
23+
24+ buildInputs = [ qtbase ];
25+ nativeBuildInputs = [ wrapQtAppsHook ]; <co xml:id='qt-default-nix-co-2' />
26+}
27+</programlisting>
28+
29+ <calloutlist>
30+ <callout arearefs='qt-default-nix-co-1'>
31+ <para>
32+ Import Qt modules directly, that is: <literal>qtbase</literal>, <literal>qtdeclarative</literal>, etc.
33+ <emphasis>Do not</emphasis> import Qt package sets such as <literal>qt5</literal>
34+ because the Qt versions of dependencies may not be coherent, causing build and runtime failures.
35+ </para>
36+ </callout>
37+ <callout arearefs='qt-default-nix-co-2'>
38+ <para>
39+ All Qt packages must include <literal>wrapQtAppsHook</literal> in
40+ <literal>nativeBuildInputs</literal>, or you must explicitly set
41+ <literal>dontWrapQtApps</literal>.
42+ </para>
43+ </callout>
44+ </calloutlist>
45+```
46+
47+## Locating runtime dependencies {#qt-runtime-dependencies}
48+
49+Qt applications must be wrapped to find runtime dependencies.
50+Include `wrapQtAppsHook` in `nativeBuildInputs`:
51+
52+```nix
53+{ stdenv, wrapQtAppsHook }:
54+
55+stdenv.mkDerivation {
56+ # ...
57+ nativeBuildInputs = [ wrapQtAppsHook ];
58+}
59+```
60+
61+Add entries to `qtWrapperArgs` are to modify the wrappers created by
62+`wrapQtAppsHook`:
63+
64+```nix
65+{ stdenv, wrapQtAppsHook }:
66+
67+stdenv.mkDerivation {
68+ # ...
69+ nativeBuildInputs = [ wrapQtAppsHook ];
70+ qtWrapperArgs = [ ''--prefix PATH : /path/to/bin'' ];
71+}
72+```
73+
74+The entries are passed as arguments to [wrapProgram](#fun-wrapProgram).
75+
76+Set `dontWrapQtApps` to stop applications from being wrapped automatically.
77+Wrap programs manually with `wrapQtApp`, using the syntax of
78+[wrapProgram](#fun-wrapProgram):
79+
80+```nix
81+{ stdenv, lib, wrapQtAppsHook }:
82+
83+stdenv.mkDerivation {
84+ # ...
85+ nativeBuildInputs = [ wrapQtAppsHook ];
86+ dontWrapQtApps = true;
87+ preFixup = ''
88+ wrapQtApp "$out/bin/myapp" --prefix PATH : /path/to/bin
89+ '';
90+}
91+```
92+
93+::: {.note}
94+`wrapQtAppsHook` ignores files that are non-ELF executables.
95+This means that scripts won't be automatically wrapped so you'll need to manually wrap them as previously mentioned.
96+An example of when you'd always need to do this is with Python applications that use PyQt.
97+:::
98+
99+## Adding a library to Nixpkgs {#adding-a-library-to-nixpkgs}
100+
101+Add Qt libraries to `qt5-packages.nix` to make them available for every
102+supported Qt version.
103+
104+### Example adding a Qt library {#qt-library-all-packages-nix}
105+
106+The following represents the contents of `qt5-packages.nix`.
107+
108+```nix
109+{
110+ # ...
111+
112+ mylib = callPackage ../path/to/mylib {};
113+
114+ # ...
115+}
116+```
117+
118+Libraries are built with every available version of Qt.
119+Use the `meta.broken` attribute to disable the package for unsupported Qt versions:
120+
121+```nix
122+{ stdenv, lib, qtbase }:
123+
124+stdenv.mkDerivation {
125+ # ...
126+ # Disable this library with Qt < 5.9.0
127+ meta.broken = lib.versionOlder qtbase.version "5.9.0";
128+}
129+```
130+
131+## Adding an application to Nixpkgs {#adding-an-application-to-nixpkgs}
132+
133+Add Qt applications to `qt5-packages.nix`. Add an alias to `all-packages.nix`
134+to select the Qt 5 version used for the application.
135+
136+### Example adding a Qt application {#qt-application-all-packages-nix}
137+
138+The following represents the contents of `qt5-packages.nix`.
139+
140+```nix
141+{
142+ # ...
143+
144+ myapp = callPackage ../path/to/myapp {};
145+
146+ # ...
147+}
148+```
149+
150+The following represents the contents of `all-packages.nix`.
151+
152+```nix
153+{
154+ # ...
155+
156+ myapp = libsForQt5.myapp;
157+
158+ # ...
159+}
160+```
doc/languages-frameworks/qt.xmldeleted−74
@@ -1,74 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-qt">
4− <title>Qt</title>
5−
6− <para>
7− Qt is a comprehensive desktop and mobile application development toolkit for
8− C++. Legacy support is available for Qt 3 and Qt 4, but all current
9− development uses Qt 5. The Qt 5 packages in Nixpkgs are updated frequently to
10− take advantage of new features, but older versions are typically retained
11− until their support window ends. The most important consideration in
12− packaging Qt-based software is ensuring that each package and all its
13− dependencies use the same version of Qt 5; this consideration motivates most
14− of the tools described below.
15− </para>
16−
17− <section xml:id="ssec-qt-libraries">
18− <title>Packaging Libraries for Nixpkgs</title>
19−
20− <para>
21− Whenever possible, libraries that use Qt 5 should be built with each
22− available version. Packages providing libraries should be added to the
23− top-level function <varname>mkLibsForQt5</varname>, which is used to build a
24− set of libraries for every Qt 5 version. A special
25− <varname>callPackage</varname> function is used in this scope to ensure that
26− the entire dependency tree uses the same Qt 5 version. Import dependencies
27− unqualified, i.e., <literal>qtbase</literal> not
28− <literal>qt5.qtbase</literal>. <emphasis>Do not</emphasis> import a package
29− set such as <literal>qt5</literal> or <literal>libsForQt5</literal>.
30− </para>
31−
32− <para>
33− If a library does not support a particular version of Qt 5, it is best to
34− mark it as broken by setting its <literal>meta.broken</literal> attribute. A
35− package may be marked broken for certain versions by testing the
36− <literal>qtbase.version</literal> attribute, which will always give the
37− current Qt 5 version.
38− </para>
39− </section>
40−
41− <section xml:id="ssec-qt-applications">
42− <title>Packaging Applications for Nixpkgs</title>
43−
44− <para>
45− Call your application expression using
46− <literal>libsForQt5.callPackage</literal> instead of
47− <literal>callPackage</literal>. Import dependencies unqualified, i.e.,
48− <literal>qtbase</literal> not <literal>qt5.qtbase</literal>. <emphasis>Do
49− not</emphasis> import a package set such as <literal>qt5</literal> or
50− <literal>libsForQt5</literal>.
51− </para>
52−
53− <para>
54− Qt 5 maintains strict backward compatibility, so it is generally best to
55− build an application package against the latest version using the
56− <varname>libsForQt5</varname> library set. In case a package does not build
57− with the latest Qt version, it is possible to pick a set pinned to a
58− particular version, e.g. <varname>libsForQt55</varname> for Qt 5.5, if that
59− is the latest version the package supports. If a package must be pinned to
60− an older Qt version, be sure to file a bug upstream; because Qt is strictly
61− backwards-compatible, any incompatibility is by definition a bug in the
62− application.
63− </para>
64−
65− <para>
66− When testing applications in Nixpkgs, it is a common practice to build the
67− package with <literal>nix-build</literal> and run it using the created
68− symbolic link. This will not work with Qt applications, however, because
69− they have many hard runtime requirements that can only be guaranteed if the
70− package is actually installed. To test a Qt application, install it with
71− <literal>nix-env</literal> or run it inside <literal>nix-shell</literal>.
72− </para>
73− </section>
74−</section>
doc/languages-frameworks/r.section.md+25−18
@@ -1,7 +1,6 @@
1−R packages
2−==========
1+# R {#r}
32
4−## Installation
3+## Installation {#installation}
54
65Define an environment for R that contains all the libraries that you'd like to
76use by adding the following snippet to your $HOME/.config/nixpkgs/config.nix file:
@@ -32,15 +31,14 @@ output is the name that has to be passed to rWrapper in the code snipped above.
3231However, if you'd like to add a file to your project source to make the
3332environment available for other contributors, you can create a `default.nix`
3433file like so:
34+
3535```nix
36−let
37− pkgs = import <nixpkgs> {};
38− stdenv = pkgs.stdenv;
39−in with pkgs; {
36+with import <nixpkgs> {};
37+{
4038 myProject = stdenv.mkDerivation {
4139 name = "myProject";
4240 version = "1";
43− src = if pkgs.lib.inNixShell then null else nix;
41+ src = if lib.inNixShell then null else nix;
4442
4543 buildInputs = with rPackages; [
4644 R
@@ -53,7 +51,7 @@ in with pkgs; {
5351and then run `nix-shell .` to be dropped into a shell with those packages
5452available.
5553
56−## RStudio
54+## RStudio {#rstudio}
5755
5856RStudio uses a standard set of packages and ignores any custom R
5957environments or installed packages you may have. To create a custom
@@ -96,7 +94,12 @@ Executing `nix-shell` will then drop you into an environment equivalent to the
9694one above. If you need additional packages just add them to the list and
9795re-enter the shell.
9896
99−## Updating the package set
97+## Updating the package set {#updating-the-package-set}
98+
99+There is a script and associated environment for regenerating the package
100+sets and synchronising the rPackages tree to the current CRAN and matching
101+BIOC release. These scripts are found in the `pkgs/development/r-modules`
102+directory and executed as follows:
100103
101104```bash
102105nix-shell generate-shell.nix
@@ -106,15 +109,19 @@ mv cran-packages.nix.new cran-packages.nix
106109
107110Rscript generate-r-packages.R bioc > bioc-packages.nix.new
108111mv bioc-packages.nix.new bioc-packages.nix
109−```
110112
111−`generate-r-packages.R <repo>` reads `<repo>-packages.nix`, therefor the renaming.
113+Rscript generate-r-packages.R bioc-annotation > bioc-annotation-packages.nix.new
114+mv bioc-annotation-packages.nix.new bioc-annotation-packages.nix
112115
113−
114−## Testing if the Nix-expression could be evaluated
115−
116−```bash
117−nix-build test-evaluation.nix --dry-run
116+Rscript generate-r-packages.R bioc-experiment > bioc-experiment-packages.nix.new
117+mv bioc-experiment-packages.nix.new bioc-experiment-packages.nix
118118```
119119
120−If this exits fine, the expression is ok. If not, you have to edit `default.nix`
120+`generate-r-packages.R <repo>` reads `<repo>-packages.nix`, therefore
121+the renaming.
122+
123+Some packages require overrides to specify external dependencies or other
124+patches and special requirements. These overrides are specified in the
125+`pkgs/development/r-modules/default.nix` file. As the `*-packages.nix`
126+contents are automatically generated it should not be edited and broken
127+builds should be addressed using overrides.
doc/languages-frameworks/ruby.section.mdnew file+283
@@ -0,0 +1,283 @@
1+# Ruby {#sec-language-ruby}
2+
3+## Using Ruby {#using-ruby}
4+
5+Several versions of Ruby interpreters are available on Nix, as well as over 250 gems and many applications written in Ruby. The attribute `ruby` refers to the default Ruby interpreter, which is currently MRI 2.6. It's also possible to refer to specific versions, e.g. `ruby_2_y`, `jruby`, or `mruby`.
6+
7+In the Nixpkgs tree, Ruby packages can be found throughout, depending on what they do, and are called from the main package set. Ruby gems, however are separate sets, and there's one default set for each interpreter (currently MRI only).
8+
9+There are two main approaches for using Ruby with gems. One is to use a specifically locked `Gemfile` for an application that has very strict dependencies. The other is to depend on the common gems, which we'll explain further down, and rely on them being updated regularly.
10+
11+The interpreters have common attributes, namely `gems`, and `withPackages`. So you can refer to `ruby.gems.nokogiri`, or `ruby_2_7.gems.nokogiri` to get the Nokogiri gem already compiled and ready to use.
12+
13+Since not all gems have executables like `nokogiri`, it's usually more convenient to use the `withPackages` function like this: `ruby.withPackages (p: with p; [ nokogiri ])`. This will also make sure that the Ruby in your environment will be able to find the gem and it can be used in your Ruby code (for example via `ruby` or `irb` executables) via `require "nokogiri"` as usual.
14+
15+### Temporary Ruby environment with `nix-shell` {#temporary-ruby-environment-with-nix-shell}
16+
17+Rather than having a single Ruby environment shared by all Ruby development projects on a system, Nix allows you to create separate environments per project. `nix-shell` gives you the possibility to temporarily load another environment akin to a combined `chruby` or `rvm` and `bundle exec`.
18+
19+There are two methods for loading a shell with Ruby packages. The first and recommended method is to create an environment with `ruby.withPackages` and load that.
20+
21+```ShellSession
22+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])"
23+```
24+
25+The other method, which is not recommended, is to create an environment and list all the packages directly.
26+
27+```ShellSession
28+$ nix-shell -p ruby.gems.nokogiri ruby.gems.pry
29+```
30+
31+Again, it's possible to launch the interpreter from the shell. The Ruby interpreter has the attribute `gems` which contains all Ruby gems for that specific interpreter.
32+
33+#### Load Ruby environment from `.nix` expression {#load-ruby-environment-from-.nix-expression}
34+
35+As explained in the Nix manual, `nix-shell` can also load an expression from a `.nix` file. Say we want to have Ruby 2.6, `nokogori`, and `pry`. Consider a `shell.nix` file with:
36+
37+```nix
38+with import <nixpkgs> {};
39+ruby.withPackages (ps: with ps; [ nokogiri pry ])
40+```
41+
42+What's happening here?
43+
44+1. We begin with importing the Nix Packages collections. `import <nixpkgs>` imports the `<nixpkgs>` function, `{}` calls it and the `with` statement brings all attributes of `nixpkgs` in the local scope. These attributes form the main package set.
45+2. Then we create a Ruby environment with the `withPackages` function.
46+3. The `withPackages` function expects us to provide a function as an argument that takes the set of all ruby gems and returns a list of packages to include in the environment. Here, we select the packages `nokogiri` and `pry` from the package set.
47+
48+#### Execute command with `--run` {#execute-command-with---run}
49+
50+A convenient flag for `nix-shell` is `--run`. It executes a command in the `nix-shell`. We can e.g. directly open a `pry` REPL:
51+
52+```ShellSession
53+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry"
54+```
55+
56+Or immediately require `nokogiri` in pry:
57+
58+```ShellSession
59+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "pry -rnokogiri"
60+```
61+
62+Or run a script using this environment:
63+
64+```ShellSession
65+$ nix-shell -p "ruby.withPackages (ps: with ps; [ nokogiri pry ])" --run "ruby example.rb"
66+```
67+
68+#### Using `nix-shell` as shebang {#using-nix-shell-as-shebang}
69+
70+In fact, for the last case, there is a more convenient method. You can add a [shebang](<https://en.wikipedia.org/wiki/Shebang_(Unix)>) to your script specifying which dependencies `nix-shell` needs. With the following shebang, you can just execute `./example.rb`, and it will run with all dependencies.
71+
72+```ruby
73+#! /usr/bin/env nix-shell
74+#! nix-shell -i ruby -p "ruby.withPackages (ps: with ps; [ nokogiri rest-client ])"
75+
76+require 'nokogiri'
77+require 'rest-client'
78+
79+body = RestClient.get('http://example.com').body
80+puts Nokogiri::HTML(body).at('h1').text
81+```
82+
83+## Developing with Ruby {#developing-with-ruby}
84+
85+### Using an existing Gemfile {#using-an-existing-gemfile}
86+
87+In most cases, you'll already have a `Gemfile.lock` listing all your dependencies. This can be used to generate a `gemset.nix` which is used to fetch the gems and combine them into a single environment. The reason why you need to have a separate file for this, is that Nix requires you to have a checksum for each input to your build. Since the `Gemfile.lock` that `bundler` generates doesn't provide us with checksums, we have to first download each gem, calculate its SHA256, and store it in this separate file.
88+
89+So the steps from having just a `Gemfile` to a `gemset.nix` are:
90+
91+```ShellSession
92+$ bundle lock
93+$ bundix
94+```
95+
96+If you already have a `Gemfile.lock`, you can simply run `bundix` and it will work the same.
97+
98+To update the gems in your `Gemfile.lock`, you may use the `bundix -l` flag, which will create a new `Gemfile.lock` in case the `Gemfile` has a more recent time of modification.
99+
100+Once the `gemset.nix` is generated, it can be used in a `bundlerEnv` derivation. Here is an example you could use for your `shell.nix`:
101+
102+```nix
103+# ...
104+let
105+ gems = bundlerEnv {
106+ name = "gems-for-some-project";
107+ gemdir = ./.;
108+ };
109+in mkShell { packages = [ gems gems.wrappedRuby ]; }
110+```
111+
112+With this file in your directory, you can run `nix-shell` to build and use the gems. The important parts here are `bundlerEnv` and `wrappedRuby`.
113+
114+The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
115+
116+One common issue that you might have is that you have Ruby 2.6, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
117+
118+```nix
119+# ...
120+mkShell { buildInputs = [ gems (lowPrio gems.wrappedRuby) ]; }
121+```
122+
123+### Gem-specific configurations and workarounds {#gem-specific-configurations-and-workarounds}
124+
125+In some cases, especially if the gem has native extensions, you might need to modify the way the gem is built.
126+
127+This is done via a common configuration file that includes all of the workarounds for each gem.
128+
129+This file lives at `/pkgs/development/ruby-modules/gem-config/default.nix`, since it already contains a lot of entries, it should be pretty easy to add the modifications you need for your needs.
130+
131+In the meanwhile, or if the modification is for a private gem, you can also add the configuration to only your own environment.
132+
133+Two places that allow this modification are the `ruby` derivation, or `bundlerEnv`.
134+
135+Here's the `ruby` one:
136+
137+```nix
138+{ pg_version ? "10", pkgs ? import <nixpkgs> { } }:
139+let
140+ myRuby = pkgs.ruby.override {
141+ defaultGemConfig = pkgs.defaultGemConfig // {
142+ pg = attrs: {
143+ buildFlags =
144+ [ "--with-pg-config=${pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
145+ };
146+ };
147+ };
148+in myRuby.withPackages (ps: with ps; [ pg ])
149+```
150+
151+And an example with `bundlerEnv`:
152+
153+```nix
154+{ pg_version ? "10", pkgs ? import <nixpkgs> { } }:
155+let
156+ gems = pkgs.bundlerEnv {
157+ name = "gems-for-some-project";
158+ gemdir = ./.;
159+ gemConfig = pkgs.defaultGemConfig // {
160+ pg = attrs: {
161+ buildFlags =
162+ [ "--with-pg-config=${pkgs."postgresql_${pg_version}"}/bin/pg_config" ];
163+ };
164+ };
165+ };
166+in mkShell { buildInputs = [ gems gems.wrappedRuby ]; }
167+```
168+
169+And finally via overlays:
170+
171+```nix
172+{ pg_version ? "10" }:
173+let
174+ pkgs = import <nixpkgs> {
175+ overlays = [
176+ (self: super: {
177+ defaultGemConfig = super.defaultGemConfig // {
178+ pg = attrs: {
179+ buildFlags = [
180+ "--with-pg-config=${
181+ pkgs."postgresql_${pg_version}"
182+ }/bin/pg_config"
183+ ];
184+ };
185+ };
186+ })
187+ ];
188+ };
189+in pkgs.ruby.withPackages (ps: with ps; [ pg ])
190+```
191+
192+Then we can get whichever postgresql version we desire and the `pg` gem will always reference it correctly:
193+
194+```ShellSession
195+$ nix-shell --argstr pg_version 9_4 --run 'ruby -rpg -e "puts PG.library_version"'
196+90421
197+
198+$ nix-shell --run 'ruby -rpg -e "puts PG.library_version"'
199+100007
200+```
201+
202+Of course for this use-case one could also use overlays since the configuration for `pg` depends on the `postgresql` alias, but for demonstration purposes this has to suffice.
203+
204+### Platform-specific gems
205+
206+Right now, bundix has some issues with pre-built, platform-specific gems: [bundix PR #68](https://github.com/nix-community/bundix/pull/68).
207+Until this is solved, you can tell bundler to not use platform-specific gems and instead build them from source each time:
208+- globally (will be set in `~/.config/.bundle/config`):
209+```shell
210+$ bundle config set force_ruby_platform true
211+```
212+- locally (will be set in `<project-root>/.bundle/config`):
213+```shell
214+$ bundle config set --local force_ruby_platform true
215+```
216+
217+### Adding a gem to the default gemset {#adding-a-gem-to-the-default-gemset}
218+
219+Now that you know how to get a working Ruby environment with Nix, it's time to go forward and start actually developing with Ruby. We will first have a look at how Ruby gems are packaged on Nix. Then, we will look at how you can use development mode with your code.
220+
221+All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible to each other.
222+
223+In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
224+
225+To test that it works, you can then try using the gem with:
226+
227+```shell
228+NIX_PATH=nixpkgs=$PWD nix-shell -p "ruby.withPackages (ps: with ps; [ name-of-your-gem ])"
229+```
230+
231+### Packaging applications {#packaging-applications}
232+
233+A common task is to add a ruby executable to nixpkgs, popular examples would be `chef`, `jekyll`, or `sass`. A good way to do that is to use the `bundlerApp` function, that allows you to make a package that only exposes the listed executables, otherwise the package may cause conflicts through common paths like `bin/rake` or `bin/bundler` that aren't meant to be used.
234+
235+The absolute easiest way to do that is to write a `Gemfile` along these lines:
236+
237+```ruby
238+source 'https://rubygems.org' do
239+ gem 'mdl'
240+end
241+```
242+
243+If you want to package a specific version, you can use the standard Gemfile syntax for that, e.g. `gem 'mdl', '0.5.0'`, but if you want the latest stable version anyway, it's easier to update by simply running the `bundle lock` and `bundix` steps again.
244+
245+Now you can also make a `default.nix` that looks like this:
246+
247+```nix
248+{ bundlerApp }:
249+
250+bundlerApp {
251+ pname = "mdl";
252+ gemdir = ./.;
253+ exes = [ "mdl" ];
254+}
255+```
256+
257+All that's left to do is to generate the corresponding `Gemfile.lock` and `gemset.nix` as described above in the `Using an existing Gemfile` section.
258+
259+#### Packaging executables that require wrapping {#packaging-executables-that-require-wrapping}
260+
261+Sometimes your app will depend on other executables at runtime, and tries to find it through the `PATH` environment variable.
262+
263+In this case, you can provide a `postBuild` hook to `bundlerApp` that wraps the gem in another script that prefixes the `PATH`.
264+
265+Of course you could also make a custom `gemConfig` if you know exactly how to patch it, but it's usually much easier to maintain with a simple wrapper so the patch doesn't have to be adjusted for each version.
266+
267+Here's another example:
268+
269+```nix
270+{ lib, bundlerApp, makeWrapper, git, gnutar, gzip }:
271+
272+bundlerApp {
273+ pname = "r10k";
274+ gemdir = ./.;
275+ exes = [ "r10k" ];
276+
277+ buildInputs = [ makeWrapper ];
278+
279+ postBuild = ''
280+ wrapProgram $out/bin/r10k --prefix PATH : ${lib.makeBinPath [ git gnutar gzip ]}
281+ '';
282+}
283+```
doc/languages-frameworks/ruby.xmldeleted−135
@@ -1,135 +0,0 @@
1−<section xmlns="http://docbook.org/ns/docbook"
2− xmlns:xlink="http://www.w3.org/1999/xlink"
3− xml:id="sec-language-ruby">
4− <title>Ruby</title>
5−
6− <para>
7− There currently is support to bundle applications that are packaged as Ruby
8− gems. The utility "bundix" allows you to write a
9− <filename>Gemfile</filename>, let bundler create a
10− <filename>Gemfile.lock</filename>, and then convert this into a nix
11− expression that contains all Gem dependencies automatically.
12− </para>
13−
14− <para>
15− For example, to package sensu, we did:
16− </para>
17−
18−<screen>
19−<![CDATA[$ cd pkgs/servers/monitoring
20−$ mkdir sensu
21−$ cd sensu
22−$ cat > Gemfile
23−source 'https://rubygems.org'
24−gem 'sensu'
25−$ $(nix-build '<nixpkgs>' -A bundix --no-out-link)/bin/bundix --magic
26−$ cat > default.nix
27−{ lib, bundlerEnv, ruby }:
28−
29−bundlerEnv rec {
30− name = "sensu-${version}";
31−
32− version = (import gemset).sensu.version;
33− inherit ruby;
34− # expects Gemfile, Gemfile.lock and gemset.nix in the same directory
35− gemdir = ./.;
36−
37− meta = with lib; {
38− description = "A monitoring framework that aims to be simple, malleable, and scalable";
39− homepage = http://sensuapp.org/;
40− license = with licenses; mit;
41− maintainers = with maintainers; [ theuni ];
42− platforms = platforms.unix;
43− };
44−}]]>
45−</screen>
46−
47− <para>
48− Please check in the <filename>Gemfile</filename>,
49− <filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so
50− future updates can be run easily.
51− </para>
52−
53− <para>
54− Updating Ruby packages can then be done like this:
55− </para>
56−
57−<screen>
58−<![CDATA[$ cd pkgs/servers/monitoring/sensu
59−$ nix-shell -p bundler --run 'bundle lock --update'
60−$ nix-shell -p bundix --run 'bundix'
61−]]>
62−</screen>
63−
64− <para>
65− For tools written in Ruby - i.e. where the desire is to install a package and
66− then execute e.g. <command>rake</command> at the command line, there is an
67− alternative builder called <literal>bundlerApp</literal>. Set up the
68− <filename>gemset.nix</filename> the same way, and then, for example:
69− </para>
70−
71−<screen>
72−<![CDATA[{ lib, bundlerApp }:
73−
74−bundlerApp {
75− pname = "corundum";
76− gemdir = ./.;
77− exes = [ "corundum-skel" ];
78−
79− meta = with lib; {
80− description = "Tool and libraries for maintaining Ruby gems.";
81− homepage = https://github.com/nyarly/corundum;
82− license = licenses.mit;
83− maintainers = [ maintainers.nyarly ];
84− platforms = platforms.unix;
85− };
86−}]]>
87−</screen>
88−
89− <para>
90− The chief advantage of <literal>bundlerApp</literal> over
91− <literal>bundlerEnv</literal> is the executables introduced in the
92− environment are precisely those selected in the <literal>exes</literal> list,
93− as opposed to <literal>bundlerEnv</literal> which adds all the executables
94− made available by gems in the gemset, which can mean e.g.
95− <command>rspec</command> or <command>rake</command> in unpredictable versions
96− available from various packages.
97− </para>
98−
99− <para>
100− Resulting derivations for both builders also have two helpful attributes,
101− <literal>env</literal> and <literal>wrappedRuby</literal>. The first one
102− allows one to quickly drop into <command>nix-shell</command> with the
103− specified environment present. E.g. <command>nix-shell -A sensu.env</command>
104− would give you an environment with Ruby preset so it has all the libraries
105− necessary for <literal>sensu</literal> in its paths. The second one can be
106− used to make derivations from custom Ruby scripts which have
107− <filename>Gemfile</filename>s with their dependencies specified. It is a
108− derivation with <command>ruby</command> wrapped so it can find all the needed
109− dependencies. For example, to make a derivation <literal>my-script</literal>
110− for a <filename>my-script.rb</filename> (which should be placed in
111− <filename>bin</filename>) you should run <command>bundix</command> as
112− specified above and then use <literal>bundlerEnv</literal> like this:
113− </para>
114−
115−<programlisting>
116−<![CDATA[let env = bundlerEnv {
117− name = "my-script-env";
118−
119− inherit ruby;
120− gemfile = ./Gemfile;
121− lockfile = ./Gemfile.lock;
122− gemset = ./gemset.nix;
123−};
124−
125−in stdenv.mkDerivation {
126− name = "my-script";
127− buildInputs = [ env.wrappedRuby ];
128− script = ./my-script.rb;
129− buildCommand = ''
130− install -D -m755 $script $out/bin/my-script
131− patchShebangs $out/bin/my-script
132− '';
133−}]]>
134−</programlisting>
135−</section>
doc/languages-frameworks/rust.section.md+718−105
This diff is too big to show here.
doc/languages-frameworks/texlive.section.mdnew file+129
This diff is too big to show here.
doc/languages-frameworks/texlive.xmldeleted−99
This diff is too big to show here.
doc/languages-frameworks/titanium.section.mdnew file+110
This diff is too big to show here.
doc/languages-frameworks/vim.section.md+198−82
This diff is too big to show here.
doc/manual.xml+37−17
This diff is too big to show here.
doc/meta.xmldeleted−431
This diff is too big to show here.
doc/multiple-output.xmldeleted−323
This diff is too big to show here.
doc/old/cross.txt+4−4
This diff is too big to show here.
doc/overlays.xmldeleted−195
This diff is too big to show here.
doc/overrides.css+14−1
This diff is too big to show here.
doc/package-notes.xmldeleted−893
This diff is too big to show here.
doc/platform-notes.xmldeleted−105
This diff is too big to show here.
doc/preface.chapter.mdnew file+46
This diff is too big to show here.
doc/quick-start.xmldeleted−219
This diff is too big to show here.
doc/release-notes.xml+57−207
This diff is too big to show here.
doc/reviewing-contributions.xmldeleted−616
This diff is too big to show here.
doc/shell.nix+3−5
This diff is too big to show here.
doc/stdenv.xmldeleted−2851
This diff is too big to show here.
doc/stdenv/cross-compilation.chapter.mdnew file+236
This diff is too big to show here.
doc/stdenv/meta.chapter.mdnew file+251
This diff is too big to show here.
doc/stdenv/multiple-output.chapter.mdnew file+128
This diff is too big to show here.
doc/stdenv/platform-notes.chapter.mdnew file+62
This diff is too big to show here.
doc/stdenv/stdenv.chapter.mdnew file+1323
This diff is too big to show here.
doc/style.css+22−2
This diff is too big to show here.
doc/submitting-changes.xmldeleted−523
This diff is too big to show here.
doc/using/configuration.chapter.mdnew file+356
This diff is too big to show here.
doc/using/overlays.chapter.mdnew file+167
This diff is too big to show here.
doc/using/overrides.chapter.mdnew file+108
This diff is too big to show here.
flake.nixnew file+49
This diff is too big to show here.
lib/asserts.nix+10−12
This diff is too big to show here.
lib/attrsets.nix+191−34
This diff is too big to show here.
lib/cli.nixnew file+83
This diff is too big to show here.
lib/composable-derivation.nixdeleted−113
This diff is too big to show here.
lib/customisation.nix+110−20
This diff is too big to show here.
lib/debug.nix+46−8
This diff is too big to show here.
lib/default.nix+69−47
This diff is too big to show here.
lib/deprecated.nix+12−127
This diff is too big to show here.
lib/filesystem.nix+12
This diff is too big to show here.
lib/fixed-points.nix+27−5
This diff is too big to show here.
lib/flake.nixnew file+5
This diff is too big to show here.
lib/flakes.nixnew file+22
This diff is too big to show here.
lib/generators.nix+208−29
This diff is too big to show here.
lib/kernel.nix+18−49
This diff is too big to show here.
lib/licenses.nix+418−171
This diff is too big to show here.
lib/lists.nix+35−29
This diff is too big to show here.
lib/meta.nix+60−6
This diff is too big to show here.
lib/minver.nix+1−1
This diff is too big to show here.
lib/modules.nix+672−189
This diff is too big to show here.
lib/options.nix+152−29
This diff is too big to show here.
lib/sources.nix+236−56
This diff is too big to show here.
lib/strings-with-deps.nix+9−4
This diff is too big to show here.
lib/strings.nix+380−76
This diff is too big to show here.
lib/systems/architectures.nixnew file+107
This diff is too big to show here.
lib/systems/default.nix+116−10
This diff is too big to show here.
lib/systems/doubles.nix+84−25
This diff is too big to show here.
lib/systems/examples.nix+194−69
This diff is too big to show here.
lib/systems/for-meta.nixdeleted−37
This diff is too big to show here.
lib/systems/inspect.nix+26−7
This diff is too big to show here.
lib/systems/parse.nix+195−48
This diff is too big to show here.
lib/systems/platforms.nix+433−341
This diff is too big to show here.
lib/systems/supported.nixnew file+26
This diff is too big to show here.
lib/tests/flakes/subflakeTest/flake.nixnew file+8
This diff is too big to show here.
lib/tests/flakes/subflakeTest/subflake/flake.nixnew file+5
This diff is too big to show here.
lib/tests/maintainers.nixnew file+80
This diff is too big to show here.
lib/tests/misc.nix+790−40
This diff is too big to show here.
lib/tests/modules.sh+256−74
This diff is too big to show here.
lib/tests/modules/adhoc-freeformType-survives-type-merge.nixnew file+14
This diff is too big to show here.
lib/tests/modules/alias-with-priority-can-override.nixnew file+55
This diff is too big to show here.
lib/tests/modules/alias-with-priority.nixnew file+55
This diff is too big to show here.
lib/tests/modules/attrsOf-conditional-check.nixnew file+7
This diff is too big to show here.
lib/tests/modules/attrsOf-lazy-check.nixnew file+7
This diff is too big to show here.
lib/tests/modules/declare-attrsOf.nixnew file+13
This diff is too big to show here.
lib/tests/modules/declare-attrsOfSub-any-enable.nixnew file+29
This diff is too big to show here.
lib/tests/modules/declare-bare-submodule-deep-option-duplicate.nixnew file+10
This diff is too big to show here.
lib/tests/modules/declare-bare-submodule-deep-option.nixnew file+10
This diff is too big to show here.
lib/tests/modules/declare-bare-submodule-nested-option.nixnew file+19
This diff is too big to show here.
lib/tests/modules/declare-bare-submodule.nixnew file+18
This diff is too big to show here.
lib/tests/modules/declare-either.nixnew file+5
This diff is too big to show here.
lib/tests/modules/declare-enable-nested.nixnew file+14
This diff is too big to show here.
lib/tests/modules/declare-int-positive-value-nested.nixnew file+9
This diff is too big to show here.
lib/tests/modules/declare-lazyAttrsOf.nixnew file+6
This diff is too big to show here.
lib/tests/modules/declare-loaOfSub-any-enable.nixdeleted−29
This diff is too big to show here.
lib/tests/modules/declare-oneOf.nixnew file+9
This diff is too big to show here.
lib/tests/modules/declare-set.nixnew file+12
This diff is too big to show here.
lib/tests/modules/declare-submodule-via-evalModules.nixnew file+28
This diff is too big to show here.
lib/tests/modules/declare-submoduleWith-modules.nixnew file+28
This diff is too big to show here.
lib/tests/modules/declare-submoduleWith-noshorthand.nixnew file+13
This diff is too big to show here.
lib/tests/modules/declare-submoduleWith-path.nixnew file+12
This diff is too big to show here.
lib/tests/modules/declare-submoduleWith-shorthand.nixnew file+14
This diff is too big to show here.
lib/tests/modules/declare-submoduleWith-special.nixnew file+17
This diff is too big to show here.
lib/tests/modules/declare-variants.nixnew file+9
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-bar-enable.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-bar.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo-enable-force.nixnew file+5
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo-enable-if.nixnew file+5
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo-enable.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo-force-enable.nixnew file+7
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo-if-enable.nixnew file+7
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-foo.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-force-foo-enable.nixnew file+7
This diff is too big to show here.
lib/tests/modules/define-attrsOfSub-if-foo-enable.nixnew file+7
This diff is too big to show here.
lib/tests/modules/define-bare-submodule-values.nixnew file+4
This diff is too big to show here.
lib/tests/modules/define-force-attrsOfSub-foo-enable.nixnew file+5
This diff is too big to show here.
lib/tests/modules/define-force-loaOfSub-foo-enable.nixdeleted−5
This diff is too big to show here.
lib/tests/modules/define-if-attrsOfSub-foo-enable.nixnew file+5
This diff is too big to show here.
lib/tests/modules/define-if-loaOfSub-foo-enable.nixdeleted−5
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-bar-enable.nixdeleted−3
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-bar.nixdeleted−3
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo-enable-force.nixdeleted−5
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo-enable-if.nixdeleted−5
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo-enable.nixdeleted−3
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo-force-enable.nixdeleted−7
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo-if-enable.nixdeleted−7
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-foo.nixdeleted−3
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-force-foo-enable.nixdeleted−7
This diff is too big to show here.
lib/tests/modules/define-loaOfSub-if-foo-enable.nixdeleted−7
This diff is too big to show here.
lib/tests/modules/define-option-dependently-nested.nixnew file+16
This diff is too big to show here.
lib/tests/modules/define-option-dependently.nixnew file+16
This diff is too big to show here.
lib/tests/modules/define-shorthandOnlyDefinesConfig-true.nixnew file+1
This diff is too big to show here.
lib/tests/modules/define-submoduleWith-noshorthand.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-submoduleWith-shorthand.nixnew file+3
This diff is too big to show here.
lib/tests/modules/define-value-string-properties.nixnew file+12
This diff is too big to show here.
lib/tests/modules/define-variant.nixnew file+22
This diff is too big to show here.
lib/tests/modules/disable-recursive/bar.nixnew file+5
This diff is too big to show here.
lib/tests/modules/disable-recursive/disable-bar.nixnew file+7
This diff is too big to show here.
lib/tests/modules/disable-recursive/disable-foo.nixnew file+7
This diff is too big to show here.
lib/tests/modules/disable-recursive/foo.nixnew file+5
This diff is too big to show here.
lib/tests/modules/disable-recursive/main.nixnew file+8
This diff is too big to show here.
lib/tests/modules/emptyValues.nixnew file+36
This diff is too big to show here.
lib/tests/modules/extendModules-168767-imports.nixnew file+41
This diff is too big to show here.
lib/tests/modules/freeform-attrsOf.nixnew file+3
This diff is too big to show here.
lib/tests/modules/freeform-lazyAttrsOf.nixnew file+3
This diff is too big to show here.
lib/tests/modules/freeform-nested.nixnew file+14
This diff is too big to show here.
lib/tests/modules/freeform-str-dep-unstr.nixnew file+8
This diff is too big to show here.
lib/tests/modules/freeform-submodules.nixnew file+22
This diff is too big to show here.
lib/tests/modules/freeform-unstr-dep-str.nixnew file+8
This diff is too big to show here.
lib/tests/modules/functionTo/list-order.nixnew file+25
This diff is too big to show here.
lib/tests/modules/functionTo/merging-attrs.nixnew file+27
This diff is too big to show here.
lib/tests/modules/functionTo/merging-list.nixnew file+24
This diff is too big to show here.
lib/tests/modules/functionTo/trivial.nixnew file+17
This diff is too big to show here.
lib/tests/modules/functionTo/wrong-type.nixnew file+18
This diff is too big to show here.
lib/tests/modules/import-from-store.nixnew file+11
This diff is too big to show here.
lib/tests/modules/loaOf-with-long-list.nixdeleted−19
This diff is too big to show here.
lib/tests/modules/loaOf-with-many-list-merges.nixdeleted−19
This diff is too big to show here.
lib/tests/modules/optionTypeFile.nixnew file+28
This diff is too big to show here.
lib/tests/modules/optionTypeMerging.nixnew file+27
This diff is too big to show here.
lib/tests/modules/raw.nixnew file+30
This diff is too big to show here.
lib/tests/modules/types-anything/attrs-coercible.nixnew file+12
This diff is too big to show here.
lib/tests/modules/types-anything/equal-atoms.nixnew file+26
This diff is too big to show here.
lib/tests/modules/types-anything/functions.nixnew file+23
This diff is too big to show here.
lib/tests/modules/types-anything/lists.nixnew file+16
This diff is too big to show here.
lib/tests/modules/types-anything/mk-mods.nixnew file+44
This diff is too big to show here.
lib/tests/modules/types-anything/nested-attrs.nixnew file+22
This diff is too big to show here.
lib/tests/release.nix+24−15
This diff is too big to show here.
lib/tests/sources.shnew file+61
This diff is too big to show here.
lib/tests/systems.nix+17−10
This diff is too big to show here.
lib/trivial.nix+222−6
This diff is too big to show here.
lib/types.nix+405−125
This diff is too big to show here.
lib/versions.nix+7−5
This diff is too big to show here.
maintainers/maintainer-list.nix+9798−252
This diff is too big to show here.
maintainers/scripts/build.nixnew file+55
This diff is too big to show here.
maintainers/scripts/check-hydra-by-maintainer.nixnew file+68
This diff is too big to show here.
maintainers/scripts/check-maintainer-github-handles.sh+9−9
This diff is too big to show here.
maintainers/scripts/copy-tarballs.pl+20−6
This diff is too big to show here.
maintainers/scripts/db-to-md.shnew file+88
This diff is too big to show here.
maintainers/scripts/debian-patches.sh+1−1
This diff is too big to show here.
maintainers/scripts/dep-licenses.sh+1−1
This diff is too big to show here.
maintainers/scripts/doc/escape-code-markup.pynew file+97
This diff is too big to show here.
maintainers/scripts/doc/replace-xrefs-by-empty-links.pynew file+32
This diff is too big to show here.
maintainers/scripts/doc/unknown-code-language.luanew file+12
This diff is too big to show here.
maintainers/scripts/eval-release.shnew file+11
This diff is too big to show here.
maintainers/scripts/feature-freeze-teams.plnew file+98
This diff is too big to show here.
maintainers/scripts/fetch-kde-qt.sh+2−1
This diff is too big to show here.
maintainers/scripts/find-tarballs.nix+2−2
This diff is too big to show here.
maintainers/scripts/haskell/dependencies.nixnew file+10
This diff is too big to show here.
maintainers/scripts/haskell/hydra-report.hsnew file+490
This diff is too big to show here.
maintainers/scripts/haskell/maintained-broken-pkgs.nixnew file+22
This diff is too big to show here.
maintainers/scripts/haskell/maintainer-handles.nixnew file+7
This diff is too big to show here.
maintainers/scripts/haskell/mark-broken.shnew file+47
This diff is too big to show here.
maintainers/scripts/haskell/merge-and-open-pr.shnew file+122
This diff is too big to show here.
maintainers/scripts/haskell/regenerate-hackage-packages.shnew file+46
This diff is too big to show here.
maintainers/scripts/haskell/regenerate-transitive-broken-packages.shnew file+15
This diff is too big to show here.
maintainers/scripts/haskell/test-configurations.nixnew file+136
This diff is too big to show here.
maintainers/scripts/haskell/transitive-broken-packages.nixnew file+16
This diff is too big to show here.
maintainers/scripts/haskell/update-cabal2nix-unstable.shnew file+17
This diff is too big to show here.
maintainers/scripts/haskell/update-hackage.shnew file+35
This diff is too big to show here.
maintainers/scripts/haskell/update-stackage.shnew file+70
This diff is too big to show here.
maintainers/scripts/haskell/upload-nixos-package-list-to-hackage.shnew file+22
This diff is too big to show here.
maintainers/scripts/hydra-eval-failures.py+26−14
This diff is too big to show here.
maintainers/scripts/luarocks-config.luanew file+4
This diff is too big to show here.
maintainers/scripts/luarocks-packages.csvnew file+87
This diff is too big to show here.
maintainers/scripts/nix-generate-from-cpan.nix+4−4
This diff is too big to show here.
maintainers/scripts/nix-generate-from-cpan.pl+14−18
This diff is too big to show here.
maintainers/scripts/nixpkgs-lint.nix+7−6
This diff is too big to show here.
maintainers/scripts/nixpkgs-lint.pl+1−1
This diff is too big to show here.
maintainers/scripts/pluginupdate.pynew file+701
This diff is too big to show here.
maintainers/scripts/rebuild-amount.sh+86−80
This diff is too big to show here.
maintainers/scripts/remove-old-aliases.pynew file+211
This diff is too big to show here.
maintainers/scripts/test-eval-release.shdeleted−7
This diff is too big to show here.
maintainers/scripts/update-luarocks-packagesnew file+218
This diff is too big to show here.
maintainers/scripts/update-luarocks-shell.nixnew file+13
This diff is too big to show here.
maintainers/scripts/update-python-libraries+4−360
This diff is too big to show here.
maintainers/scripts/update-redirected-urls.shnew file+12
This diff is too big to show here.
maintainers/scripts/update-ruby-packagesnew file+16
This diff is too big to show here.
maintainers/scripts/update.nix+136−83
This diff is too big to show here.
maintainers/scripts/update.pynew file+229
This diff is too big to show here.
maintainers/scripts/vanity.sh+19−19
This diff is too big to show here.
maintainers/team-list.nixnew file+669
This diff is too big to show here.
nixos/README+1−1
This diff is too big to show here.
nixos/default.nix+1−19
This diff is too big to show here.
nixos/doc/manual/Makefile+6−5
This diff is too big to show here.
nixos/doc/manual/READMEdeleted−12
This diff is too big to show here.
nixos/doc/manual/README.mdnew file+3
This diff is too big to show here.
nixos/doc/manual/administration/boot-problems.section.mdnew file+41
This diff is too big to show here.
nixos/doc/manual/administration/boot-problems.xmldeleted−90
This diff is too big to show here.
nixos/doc/manual/administration/cleaning-store.chapter.mdnew file+62
This diff is too big to show here.
nixos/doc/manual/administration/cleaning-store.xmldeleted−63
This diff is too big to show here.
nixos/doc/manual/administration/container-networking.section.mdnew file+44
This diff is too big to show here.
nixos/doc/manual/administration/container-networking.xmldeleted−59
This diff is too big to show here.
nixos/doc/manual/administration/containers.chapter.mdnew file+28
This diff is too big to show here.
nixos/doc/manual/administration/containers.xmldeleted−34
This diff is too big to show here.
nixos/doc/manual/administration/control-groups.chapter.mdnew file+59
This diff is too big to show here.
nixos/doc/manual/administration/control-groups.xmldeleted−65
This diff is too big to show here.
nixos/doc/manual/administration/declarative-containers.section.mdnew file+48
This diff is too big to show here.
nixos/doc/manual/administration/declarative-containers.xmldeleted−60
This diff is too big to show here.
nixos/doc/manual/administration/imperative-containers.section.mdnew file+115
This diff is too big to show here.
nixos/doc/manual/administration/imperative-containers.xmldeleted−116
This diff is too big to show here.
nixos/doc/manual/administration/logging.chapter.mdnew file+38
This diff is too big to show here.
nixos/doc/manual/administration/logging.xmldeleted−43
This diff is too big to show here.
nixos/doc/manual/administration/maintenance-mode.section.mdnew file+11
This diff is too big to show here.
nixos/doc/manual/administration/maintenance-mode.xmldeleted−16
This diff is too big to show here.
nixos/doc/manual/administration/network-problems.section.mdnew file+21
This diff is too big to show here.
nixos/doc/manual/administration/network-problems.xmldeleted−27
This diff is too big to show here.
nixos/doc/manual/administration/rebooting.chapter.mdnew file+30
This diff is too big to show here.
nixos/doc/manual/administration/rebooting.xmldeleted−35
This diff is too big to show here.
nixos/doc/manual/administration/rollback.section.mdnew file+38
This diff is too big to show here.
nixos/doc/manual/administration/rollback.xmldeleted−41
This diff is too big to show here.
nixos/doc/manual/administration/running.xml+9−9
This diff is too big to show here.
nixos/doc/manual/administration/service-mgmt.chapter.mdnew file+120
This diff is too big to show here.
nixos/doc/manual/administration/service-mgmt.xmldeleted−72
This diff is too big to show here.
nixos/doc/manual/administration/store-corruption.section.mdnew file+28
This diff is too big to show here.
nixos/doc/manual/administration/store-corruption.xmldeleted−36
This diff is too big to show here.
nixos/doc/manual/administration/troubleshooting.chapter.mdnew file+12
This diff is too big to show here.
nixos/doc/manual/administration/troubleshooting.xmldeleted−16
This diff is too big to show here.
nixos/doc/manual/administration/user-sessions.chapter.mdnew file+43
This diff is too big to show here.
nixos/doc/manual/administration/user-sessions.xmldeleted−45
This diff is too big to show here.
nixos/doc/manual/configuration/abstractions.section.mdnew file+80
This diff is too big to show here.
nixos/doc/manual/configuration/abstractions.xmldeleted−156
This diff is too big to show here.
nixos/doc/manual/configuration/ad-hoc-network-config.section.mdnew file+13
This diff is too big to show here.
nixos/doc/manual/configuration/ad-hoc-network-config.xmldeleted−20
This diff is too big to show here.
nixos/doc/manual/configuration/ad-hoc-packages.section.mdnew file+51
This diff is too big to show here.
nixos/doc/manual/configuration/ad-hoc-packages.xmldeleted−61
This diff is too big to show here.
nixos/doc/manual/configuration/adding-custom-packages.section.mdnew file+74
This diff is too big to show here.
nixos/doc/manual/configuration/adding-custom-packages.xmldeleted−73
This diff is too big to show here.
nixos/doc/manual/configuration/config-file.section.mdnew file+175
This diff is too big to show here.
nixos/doc/manual/configuration/config-file.xmldeleted−210
This diff is too big to show here.
nixos/doc/manual/configuration/config-syntax.chapter.mdnew file+19
This diff is too big to show here.
nixos/doc/manual/configuration/config-syntax.xmldeleted−25
This diff is too big to show here.
nixos/doc/manual/configuration/configuration.xml+14−10
This diff is too big to show here.
nixos/doc/manual/configuration/customizing-packages.section.mdnew file+74
This diff is too big to show here.
nixos/doc/manual/configuration/customizing-packages.xmldeleted−86
This diff is too big to show here.
nixos/doc/manual/configuration/declarative-packages.section.mdnew file+46
This diff is too big to show here.
nixos/doc/manual/configuration/declarative-packages.xmldeleted−43
This diff is too big to show here.
nixos/doc/manual/configuration/file-systems.chapter.mdnew file+42
This diff is too big to show here.
nixos/doc/manual/configuration/file-systems.xmldeleted−46
This diff is too big to show here.
nixos/doc/manual/configuration/firewall.section.mdnew file+32
This diff is too big to show here.
nixos/doc/manual/configuration/firewall.xmldeleted−37
This diff is too big to show here.
nixos/doc/manual/configuration/gpu-accel.chapter.mdnew file+204
This diff is too big to show here.
nixos/doc/manual/configuration/ipv4-config.section.mdnew file+35
This diff is too big to show here.
nixos/doc/manual/configuration/ipv4-config.xmldeleted−43
This diff is too big to show here.
nixos/doc/manual/configuration/ipv6-config.section.mdnew file+42
This diff is too big to show here.
nixos/doc/manual/configuration/ipv6-config.xmldeleted−50
This diff is too big to show here.
nixos/doc/manual/configuration/kubernetes.chapter.mdnew file+104
This diff is too big to show here.
nixos/doc/manual/configuration/linux-kernel.chapter.mdnew file+140
This diff is too big to show here.
nixos/doc/manual/configuration/linux-kernel.xmldeleted−138
This diff is too big to show here.
nixos/doc/manual/configuration/luks-file-systems.section.mdnew file+77
This diff is too big to show here.
nixos/doc/manual/configuration/luks-file-systems.xmldeleted−40
This diff is too big to show here.
nixos/doc/manual/configuration/modularity.section.mdnew file+133
This diff is too big to show here.
nixos/doc/manual/configuration/modularity.xmldeleted−149
This diff is too big to show here.
nixos/doc/manual/configuration/network-manager.section.mdnew file+42
This diff is too big to show here.
nixos/doc/manual/configuration/network-manager.xmldeleted−44
This diff is too big to show here.
nixos/doc/manual/configuration/networking.chapter.mdnew file+16
This diff is too big to show here.
nixos/doc/manual/configuration/networking.xmldeleted−19
This diff is too big to show here.
nixos/doc/manual/configuration/package-mgmt.chapter.mdnew file+18
This diff is too big to show here.
nixos/doc/manual/configuration/package-mgmt.xmldeleted−31
This diff is too big to show here.
nixos/doc/manual/configuration/profiles.chapter.mdnew file+34
This diff is too big to show here.
nixos/doc/manual/configuration/profiles.xmldeleted−39
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/all-hardware.section.mdnew file+11
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/all-hardware.xmldeleted−20
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/base.section.mdnew file+7
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/base.xmldeleted−15
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/clone-config.section.mdnew file+11
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/clone-config.xmldeleted−14
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/demo.section.mdnew file+4
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/demo.xmldeleted−13
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/docker-container.section.mdnew file+7
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/docker-container.xmldeleted−15
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/graphical.section.mdnew file+10
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/graphical.xmldeleted−21
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/hardened.section.mdnew file+20
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/hardened.xmldeleted−22
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/headless.section.mdnew file+9
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/headless.xmldeleted−18
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/installation-device.section.mdnew file+24
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/installation-device.xmldeleted−35
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/minimal.section.mdnew file+9
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/minimal.xmldeleted−17
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/qemu-guest.section.mdnew file+7
This diff is too big to show here.
nixos/doc/manual/configuration/profiles/qemu-guest.xmldeleted−16
This diff is too big to show here.
nixos/doc/manual/configuration/renaming-interfaces.section.mdnew file+51
This diff is too big to show here.
nixos/doc/manual/configuration/ssh.section.mdnew file+19
This diff is too big to show here.
nixos/doc/manual/configuration/ssh.xmldeleted−27
This diff is too big to show here.
nixos/doc/manual/configuration/sshfs-file-systems.section.mdnew file+104
This diff is too big to show here.
nixos/doc/manual/configuration/subversion.chapter.mdnew file+102
This diff is too big to show here.
nixos/doc/manual/configuration/summary.section.mdnew file+46
This diff is too big to show here.
nixos/doc/manual/configuration/summary.xmldeleted−227
This diff is too big to show here.
nixos/doc/manual/configuration/user-mgmt.chapter.mdnew file+92
This diff is too big to show here.
nixos/doc/manual/configuration/user-mgmt.xmldeleted−88
This diff is too big to show here.
nixos/doc/manual/configuration/wayland.chapter.mdnew file+27
This diff is too big to show here.
nixos/doc/manual/configuration/wireless.section.mdnew file+67
This diff is too big to show here.
nixos/doc/manual/configuration/wireless.xmldeleted−45
This diff is too big to show here.
nixos/doc/manual/configuration/x-windows.chapter.mdnew file+337
This diff is too big to show here.
nixos/doc/manual/configuration/x-windows.xmldeleted−136
This diff is too big to show here.
nixos/doc/manual/configuration/xfce.chapter.mdnew file+52
This diff is too big to show here.
nixos/doc/manual/configuration/xfce.xmldeleted−72
This diff is too big to show here.
nixos/doc/manual/contributing-to-this-manual.chapter.mdnew file+13
This diff is too big to show here.
nixos/doc/manual/default.nix+34−104
This diff is too big to show here.
nixos/doc/manual/development/activation-script.section.mdnew file+72
This diff is too big to show here.
nixos/doc/manual/development/assertions.section.mdnew file+40
This diff is too big to show here.
nixos/doc/manual/development/assertions.xmldeleted−74
This diff is too big to show here.
nixos/doc/manual/development/building-nixos.xmldeleted−27
This diff is too big to show here.
nixos/doc/manual/development/building-parts.chapter.mdnew file+74
This diff is too big to show here.
nixos/doc/manual/development/building-parts.xmldeleted−121
This diff is too big to show here.
nixos/doc/manual/development/debugging-nixos-tests.xmldeleted−37
This diff is too big to show here.
nixos/doc/manual/development/development.xml+8−9
This diff is too big to show here.
nixos/doc/manual/development/freeform-modules.section.mdnew file+79
This diff is too big to show here.
nixos/doc/manual/development/importing-modules.section.mdnew file+46
This diff is too big to show here.
nixos/doc/manual/development/importing-modules.xmldeleted−56
This diff is too big to show here.
nixos/doc/manual/development/linking-nixos-tests-to-packages.section.mdnew file+6
This diff is too big to show here.
nixos/doc/manual/development/meta-attributes.section.mdnew file+66
This diff is too big to show here.
nixos/doc/manual/development/meta-attributes.xmldeleted−63
This diff is too big to show here.
nixos/doc/manual/development/nixos-tests.chapter.mdnew file+13
This diff is too big to show here.
nixos/doc/manual/development/nixos-tests.xmldeleted−20
This diff is too big to show here.
nixos/doc/manual/development/option-declarations.section.mdnew file+221
This diff is too big to show here.
nixos/doc/manual/development/option-declarations.xmldeleted−199
This diff is too big to show here.
nixos/doc/manual/development/option-def.section.mdnew file+91
This diff is too big to show here.
nixos/doc/manual/development/option-def.xmldeleted−99
This diff is too big to show here.
nixos/doc/manual/development/option-types.section.mdnew file+583
This diff is too big to show here.
nixos/doc/manual/development/option-types.xmldeleted−781
This diff is too big to show here.
nixos/doc/manual/development/releases.xmldeleted−260
This diff is too big to show here.
nixos/doc/manual/development/replace-modules.section.mdnew file+64
This diff is too big to show here.
nixos/doc/manual/development/replace-modules.xmldeleted−79
This diff is too big to show here.
nixos/doc/manual/development/running-nixos-tests-interactively.section.mdnew file+35
This diff is too big to show here.
nixos/doc/manual/development/running-nixos-tests-interactively.xmldeleted−44
This diff is too big to show here.
nixos/doc/manual/development/running-nixos-tests.section.mdnew file+31
This diff is too big to show here.
nixos/doc/manual/development/running-nixos-tests.xmldeleted−36
This diff is too big to show here.
nixos/doc/manual/development/settings-options.section.mdnew file+251
This diff is too big to show here.
nixos/doc/manual/development/sources.chapter.mdnew file+77
This diff is too big to show here.
nixos/doc/manual/development/sources.xmldeleted−86
This diff is too big to show here.
nixos/doc/manual/development/testing-installer.chapter.mdnew file+18
This diff is too big to show here.
nixos/doc/manual/development/testing-installer.xmldeleted−22
This diff is too big to show here.
nixos/doc/manual/development/unit-handling.section.mdnew file+62
This diff is too big to show here.
nixos/doc/manual/development/what-happens-during-a-system-switch.chapter.mdnew file+53
This diff is too big to show here.
nixos/doc/manual/development/writing-documentation.chapter.mdnew file+93
This diff is too big to show here.
nixos/doc/manual/development/writing-documentation.xmldeleted−149
This diff is too big to show here.
nixos/doc/manual/development/writing-modules.chapter.mdnew file+208
This diff is too big to show here.
nixos/doc/manual/development/writing-modules.xmldeleted−186
This diff is too big to show here.
nixos/doc/manual/development/writing-nixos-tests.section.mdnew file+382
This diff is too big to show here.
nixos/doc/manual/development/writing-nixos-tests.xmldeleted−421
This diff is too big to show here.
nixos/doc/manual/from_md/README.mdnew file+5
This diff is too big to show here.
nixos/doc/manual/from_md/administration/boot-problems.section.xmlnew file+144
This diff is too big to show here.
nixos/doc/manual/from_md/administration/cleaning-store.chapter.xmlnew file+72
This diff is too big to show here.
nixos/doc/manual/from_md/administration/container-networking.section.xmlnew file+54
This diff is too big to show here.
nixos/doc/manual/from_md/administration/containers.chapter.xmlnew file+31
This diff is too big to show here.
nixos/doc/manual/from_md/administration/control-groups.chapter.xmlnew file+67
This diff is too big to show here.
nixos/doc/manual/from_md/administration/declarative-containers.section.xmlnew file+60
This diff is too big to show here.
nixos/doc/manual/from_md/administration/imperative-containers.section.xmlnew file+132
This diff is too big to show here.
nixos/doc/manual/from_md/administration/logging.chapter.xmlnew file+45
This diff is too big to show here.
nixos/doc/manual/from_md/administration/maintenance-mode.section.xmlnew file+14
This diff is too big to show here.
nixos/doc/manual/from_md/administration/network-problems.section.xmlnew file+25
This diff is too big to show here.
nixos/doc/manual/from_md/administration/rebooting.chapter.xmlnew file+38
This diff is too big to show here.
nixos/doc/manual/from_md/administration/rollback.section.xmlnew file+42
This diff is too big to show here.
nixos/doc/manual/from_md/administration/service-mgmt.chapter.xmlnew file+141
This diff is too big to show here.
nixos/doc/manual/from_md/administration/store-corruption.section.xmlnew file+34
This diff is too big to show here.
nixos/doc/manual/from_md/administration/troubleshooting.chapter.xmlnew file+12
This diff is too big to show here.
nixos/doc/manual/from_md/administration/user-sessions.chapter.xmlnew file+46
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/abstractions.section.xmlnew file+101
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/ad-hoc-network-config.section.xmlnew file+16
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/ad-hoc-packages.section.xmlnew file+59
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/adding-custom-packages.section.xmlnew file+80
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/config-file.section.xmlnew file+231
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/config-syntax.chapter.xmlnew file+21
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/customizing-packages.section.xmlnew file+90
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/declarative-packages.section.xmlnew file+53
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/file-systems.chapter.xmlnew file+55
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/firewall.section.xmlnew file+39
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/gpu-accel.chapter.xmlnew file+239
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/ipv4-config.section.xmlnew file+43
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/ipv6-config.section.xmlnew file+47
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/kubernetes.chapter.xmlnew file+126
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/linux-kernel.chapter.xmlnew file+157
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/luks-file-systems.section.xmlnew file+84
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/modularity.section.xmlnew file+152
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/network-manager.section.xmlnew file+49
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/networking.chapter.xmlnew file+15
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/package-mgmt.chapter.xmlnew file+28
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles.chapter.xmlnew file+38
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/all-hardware.section.xmlnew file+15
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/base.section.xmlnew file+10
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/clone-config.section.xmlnew file+16
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/demo.section.xmlnew file+10
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/docker-container.section.xmlnew file+12
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/graphical.section.xmlnew file+14
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/hardened.section.xmlnew file+25
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/headless.section.xmlnew file+15
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/installation-device.section.xmlnew file+32
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/minimal.section.xmlnew file+13
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/profiles/qemu-guest.section.xmlnew file+11
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/renaming-interfaces.section.xmlnew file+62
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/ssh.section.xmlnew file+23
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/sshfs-file-systems.section.xmlnew file+139
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/subversion.chapter.xmlnew file+121
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/summary.section.xmlnew file+332
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/user-mgmt.chapter.xmlnew file+105
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/wayland.chapter.xmlnew file+31
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/wireless.section.xmlnew file+73
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/x-windows.chapter.xmlnew file+381
This diff is too big to show here.
nixos/doc/manual/from_md/configuration/xfce.chapter.xmlnew file+62
This diff is too big to show here.
nixos/doc/manual/from_md/contributing-to-this-manual.chapter.xmlnew file+22
This diff is too big to show here.
nixos/doc/manual/from_md/development/activation-script.section.xmlnew file+150
This diff is too big to show here.
nixos/doc/manual/from_md/development/assertions.section.xmlnew file+58
This diff is too big to show here.
nixos/doc/manual/from_md/development/building-parts.chapter.xmlnew file+124
This diff is too big to show here.
nixos/doc/manual/from_md/development/freeform-modules.section.xmlnew file+87
This diff is too big to show here.
nixos/doc/manual/from_md/development/importing-modules.section.xmlnew file+47
This diff is too big to show here.
nixos/doc/manual/from_md/development/linking-nixos-tests-to-packages.section.xmlnew file+10
This diff is too big to show here.
nixos/doc/manual/from_md/development/meta-attributes.section.xmlnew file+95
This diff is too big to show here.
nixos/doc/manual/from_md/development/nixos-tests.chapter.xmlnew file+14
This diff is too big to show here.
nixos/doc/manual/from_md/development/option-declarations.section.xmlnew file+327
This diff is too big to show here.
nixos/doc/manual/from_md/development/option-def.section.xmlnew file+104
This diff is too big to show here.
nixos/doc/manual/from_md/development/option-types.section.xmlnew file+1038
This diff is too big to show here.
nixos/doc/manual/from_md/development/replace-modules.section.xmlnew file+70
This diff is too big to show here.
nixos/doc/manual/from_md/development/running-nixos-tests-interactively.section.xmlnew file+39
This diff is too big to show here.
nixos/doc/manual/from_md/development/running-nixos-tests.section.xmlnew file+34
This diff is too big to show here.
nixos/doc/manual/from_md/development/settings-options.section.xmlnew file+421
This diff is too big to show here.
nixos/doc/manual/from_md/development/sources.chapter.xmlnew file+90
This diff is too big to show here.
nixos/doc/manual/from_md/development/testing-installer.chapter.xmlnew file+22
This diff is too big to show here.
nixos/doc/manual/from_md/development/unit-handling.section.xmlnew file+131
This diff is too big to show here.
nixos/doc/manual/from_md/development/what-happens-during-a-system-switch.chapter.xmlnew file+122
This diff is too big to show here.
nixos/doc/manual/from_md/development/writing-documentation.chapter.xmlnew file+144
This diff is too big to show here.
nixos/doc/manual/from_md/development/writing-modules.chapter.xmlnew file+245
This diff is too big to show here.
nixos/doc/manual/from_md/development/writing-nixos-tests.section.xmlnew file+655
This diff is too big to show here.
nixos/doc/manual/from_md/installation/building-nixos.chapter.xmlnew file+106
This diff is too big to show here.
nixos/doc/manual/from_md/installation/changing-config.chapter.xmlnew file+117
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing-behind-a-proxy.section.xmlnew file+41
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing-from-other-distro.section.xmlnew file+388
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing-pxe.section.xmlnew file+42
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing-usb.section.xmlnew file+35
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing-virtualbox-guest.section.xmlnew file+92
This diff is too big to show here.
nixos/doc/manual/from_md/installation/installing.chapter.xmlnew file+645
This diff is too big to show here.
nixos/doc/manual/from_md/installation/obtaining.chapter.xmlnew file+48
This diff is too big to show here.
nixos/doc/manual/from_md/installation/upgrading.chapter.xmlnew file+152
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1310.section.xmlnew file+6
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1404.section.xmlnew file+189
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1412.section.xmlnew file+466
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1509.section.xmlnew file+776
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1603.section.xmlnew file+695
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1609.section.xmlnew file+273
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1703.section.xmlnew file+818
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1709.section.xmlnew file+922
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1803.section.xmlnew file+879
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1809.section.xmlnew file+941
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1903.section.xmlnew file+790
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-1909.section.xmlnew file+1197
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-2003.section.xmlnew file+1497
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-2009.section.xmlnew file+2210
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-2105.section.xmlnew file+1567
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-2111.section.xmlnew file+2091
This diff is too big to show here.
nixos/doc/manual/from_md/release-notes/rl-2205.section.xmlnew file+2470
This diff is too big to show here.
nixos/doc/manual/installation/building-nixos.chapter.mdnew file+77
This diff is too big to show here.
nixos/doc/manual/installation/changing-config.chapter.mdnew file+100
This diff is too big to show here.
nixos/doc/manual/installation/changing-config.xmldeleted−85
This diff is too big to show here.
nixos/doc/manual/installation/installation.xml+6−5
This diff is too big to show here.
nixos/doc/manual/installation/installing-behind-a-proxy.section.mdnew file+29
This diff is too big to show here.
nixos/doc/manual/installation/installing-behind-a-proxy.xmldeleted−48
This diff is too big to show here.
nixos/doc/manual/installation/installing-from-other-distro.section.mdnew file+279
This diff is too big to show here.
nixos/doc/manual/installation/installing-from-other-distro.xmldeleted−356
This diff is too big to show here.
nixos/doc/manual/installation/installing-pxe.section.mdnew file+32
This diff is too big to show here.
nixos/doc/manual/installation/installing-pxe.xmldeleted−50
This diff is too big to show here.
nixos/doc/manual/installation/installing-usb.section.mdnew file+31
This diff is too big to show here.
nixos/doc/manual/installation/installing-usb.xmldeleted−40
This diff is too big to show here.
nixos/doc/manual/installation/installing-virtualbox-guest.section.mdnew file+59
This diff is too big to show here.
nixos/doc/manual/installation/installing-virtualbox-guest.xmldeleted−99
This diff is too big to show here.
nixos/doc/manual/installation/installing.chapter.mdnew file+482
This diff is too big to show here.
nixos/doc/manual/installation/installing.xmldeleted−558
This diff is too big to show here.
nixos/doc/manual/installation/obtaining.chapter.mdnew file+26
This diff is too big to show here.
nixos/doc/manual/installation/obtaining.xmldeleted−54
This diff is too big to show here.
nixos/doc/manual/installation/upgrading.chapter.mdnew file+118
This diff is too big to show here.
nixos/doc/manual/installation/upgrading.xmldeleted−134
This diff is too big to show here.
nixos/doc/manual/man-configuration.xml+2−2
This diff is too big to show here.
nixos/doc/manual/man-nixos-build-vms.xml+25−7
This diff is too big to show here.
nixos/doc/manual/man-nixos-enter.xml+25−9
This diff is too big to show here.
nixos/doc/manual/man-nixos-generate-config.xml+4−4
This diff is too big to show here.
nixos/doc/manual/man-nixos-install.xml+116−26
This diff is too big to show here.
nixos/doc/manual/man-nixos-option.xml+28−31
This diff is too big to show here.
nixos/doc/manual/man-nixos-rebuild.xml+293−45
This diff is too big to show here.
nixos/doc/manual/man-nixos-version.xml+31−6
This diff is too big to show here.
nixos/doc/manual/man-pages.xml+7−2
This diff is too big to show here.
nixos/doc/manual/manual.xml+2−26
This diff is too big to show here.
nixos/doc/manual/md-to-db.shnew file+49
This diff is too big to show here.
nixos/doc/manual/preface.xmlnew file+42
This diff is too big to show here.
nixos/doc/manual/release-notes/release-notes.xml+17−11
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1310.section.mdnew file+3
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1310.xmldeleted−11
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1404.section.mdnew file+81
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1404.xmldeleted−179
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1412.section.mdnew file+171
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1412.xmldeleted−467
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1509.section.mdnew file+319
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1509.xmldeleted−750
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1603.section.mdnew file+282
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1603.xmldeleted−671
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1609.section.mdnew file+73
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1609.xmldeleted−277
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1703.section.mdnew file+303
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1703.xmldeleted−817
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1709.section.mdnew file+316
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1709.xmldeleted−899
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1803.section.mdnew file+286
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1803.xmldeleted−855
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1809.section.mdnew file+332
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1809.xmldeleted−932
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1903.section.mdnew file+214
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1903.xmldeleted−288
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-1909.section.mdnew file+313
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-2003.section.mdnew file+507
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-2009.section.mdnew file+747
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-2105.section.mdnew file+428
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-2111.section.mdnew file+575
This diff is too big to show here.
nixos/doc/manual/release-notes/rl-2205.section.mdnew file+878
This diff is too big to show here.
nixos/doc/manual/shell.nix+1−1
This diff is too big to show here.
nixos/doc/varlistentry-fixer.rb+37−37
This diff is too big to show here.
nixos/doc/xmlformat.conf−1
This diff is too big to show here.
nixos/lib/build-vms.nix+36−22
This diff is too big to show here.
nixos/lib/default.nixnew file+33
This diff is too big to show here.
nixos/lib/eval-cacheable-options.nixnew file+53
This diff is too big to show here.
nixos/lib/eval-config-minimal.nixnew file+49
This diff is too big to show here.
nixos/lib/eval-config.nix+62−18
This diff is too big to show here.
nixos/lib/make-disk-image.nix+254−54
This diff is too big to show here.
nixos/lib/make-ext4-fs.nix+52−64
This diff is too big to show here.
nixos/lib/make-iso9660-image.nix+7−7
This diff is too big to show here.
nixos/lib/make-iso9660-image.sh+17−13
This diff is too big to show here.
nixos/lib/make-multi-disk-zfs-image.nixnew file+333
This diff is too big to show here.
nixos/lib/make-options-doc/default.nixnew file+169
This diff is too big to show here.
nixos/lib/make-options-doc/generateAsciiDoc.pynew file+37
This diff is too big to show here.
nixos/lib/make-options-doc/generateCommonMark.pynew file+27
This diff is too big to show here.
nixos/lib/make-options-doc/mergeJSON.pynew file+95
This diff is too big to show here.
nixos/doc/manual/options-to-docbook.xsl → nixos/lib/make-options-doc/options-to-docbook.xslrenamed+30−20
This diff is too big to show here.
nixos/lib/make-options-doc/optionsJSONtoXML.nixnew file+6
This diff is too big to show here.
nixos/doc/manual/postprocess-option-descriptions.xsl → nixos/lib/make-options-doc/postprocess-option-descriptions.xslrenamed
The content is the same.
nixos/lib/make-options-doc/sortXML.pynew file+27
This diff is too big to show here.
nixos/lib/make-single-disk-zfs-image.nixnew file+322
This diff is too big to show here.
nixos/lib/make-squashfs.nix+11−1
This diff is too big to show here.
nixos/lib/make-system-tarball.nix+1−1
This diff is too big to show here.
nixos/lib/qemu-common.nixnew file+32
This diff is too big to show here.
nixos/lib/qemu-flags.nixdeleted−25
This diff is too big to show here.
nixos/lib/systemd-lib.nixnew file+426
This diff is too big to show here.
nixos/lib/systemd-types.nixnew file+69
This diff is too big to show here.
nixos/lib/systemd-unit-options.nixnew file+711
This diff is too big to show here.
nixos/lib/test-driver/Logger.pmdeleted−72
This diff is too big to show here.
nixos/lib/test-driver/Machine.pmdeleted−724
This diff is too big to show here.
nixos/lib/test-driver/default.nixnew file+32
This diff is too big to show here.
nixos/lib/test-driver/log2html.xsldeleted−135
This diff is too big to show here.
nixos/lib/test-driver/logfile.cssdeleted−129
This diff is too big to show here.
nixos/lib/test-driver/setup.pynew file+13
This diff is too big to show here.
nixos/lib/test-driver/test-driver.pldeleted−191
This diff is too big to show here.
nixos/lib/test-driver/test_driver/__init__.pynew file+128
This diff is too big to show here.
nixos/lib/test-driver/test_driver/driver.pynew file+226
This diff is too big to show here.
nixos/lib/test-driver/test_driver/logger.pynew file+105
This diff is too big to show here.
nixos/lib/test-driver/test_driver/machine.pynew file+1023
This diff is too big to show here.
nixos/lib/test-driver/test_driver/polling_condition.pynew file+77
This diff is too big to show here.
nixos/lib/test-driver/test_driver/vlan.pynew file+58
This diff is too big to show here.
nixos/lib/test-driver/treebits.jsdeleted−30
This diff is too big to show here.
nixos/lib/testing-python.nixnew file+250
This diff is too big to show here.
nixos/lib/testing.nixdeleted−255
This diff is too big to show here.
nixos/lib/testing/jquery-ui.nixdeleted−24
This diff is too big to show here.
nixos/lib/testing/jquery.nixdeleted−36
This diff is too big to show here.
nixos/lib/utils.nix+198−8
This diff is too big to show here.
nixos/maintainers/option-usages.nix+2−2
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/.gitignorenew file+1
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/README.mdnew file+42
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/boot-vm.shnew file+36
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/common.shnew file+7
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/examples/basic/image.nixnew file+10
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/examples/basic/system.nixnew file+34
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/shell.nixnew file+13
This diff is too big to show here.
nixos/maintainers/scripts/azure-new/upload-image.shnew file+58
This diff is too big to show here.
nixos/maintainers/scripts/azure/create-azure.sh+2−2
This diff is too big to show here.
nixos/maintainers/scripts/cloudstack/cloudstack-image.nixnew file+22
This diff is too big to show here.
nixos/maintainers/scripts/ec2/amazon-image-zfs.nixnew file+12
This diff is too big to show here.
nixos/maintainers/scripts/ec2/amazon-image.nix+115−16
This diff is too big to show here.
nixos/maintainers/scripts/ec2/create-amis.sh+314−251
This diff is too big to show here.
nixos/maintainers/scripts/gce/create-gce.sh+13−1
This diff is too big to show here.
nixos/maintainers/scripts/lxd/lxd-image-inner.nixnew file+102
This diff is too big to show here.
nixos/maintainers/scripts/lxd/lxd-image.nixnew file+34
This diff is too big to show here.
nixos/maintainers/scripts/lxd/nix.tplnew file+9
This diff is too big to show here.
nixos/maintainers/scripts/openstack/nova-image.nixdeleted−26
This diff is too big to show here.
nixos/maintainers/scripts/openstack/openstack-image-zfs.nixnew file+101
This diff is too big to show here.
nixos/maintainers/scripts/openstack/openstack-image.nixnew file+27
This diff is too big to show here.
nixos/modules/config/appstream.nixnew file+25
This diff is too big to show here.
nixos/modules/config/console.nixnew file+217
This diff is too big to show here.
nixos/modules/config/fonts/corefonts.nixdeleted−36
This diff is too big to show here.
nixos/modules/config/fonts/fontconfig-penultimate.nixdeleted−278
This diff is too big to show here.
nixos/modules/config/fonts/fontconfig-ultimate.nixdeleted−86
This diff is too big to show here.
nixos/modules/config/fonts/fontconfig.nix+267−249
This diff is too big to show here.
nixos/modules/config/fonts/fontdir.nix+35−15
This diff is too big to show here.
nixos/modules/config/fonts/fonts.nix+49−18
This diff is too big to show here.
nixos/modules/config/fonts/ghostscript.nix+1
This diff is too big to show here.
nixos/modules/config/gnu.nix+4−6
This diff is too big to show here.
nixos/modules/config/gtk/gtk-icon-cache.nix+3−2
This diff is too big to show here.
nixos/modules/config/i18n.nix+14−77
This diff is too big to show here.
nixos/modules/config/iproute2.nix+9−9
This diff is too big to show here.
nixos/modules/config/krb5/default.nix+28−26
This diff is too big to show here.
nixos/modules/config/ldap.nix+97−50
This diff is too big to show here.
nixos/modules/config/locale.nixnew file+94
This diff is too big to show here.
nixos/modules/config/malloc.nixnew file+117
This diff is too big to show here.
nixos/modules/config/networking.nix+58−141
This diff is too big to show here.
nixos/modules/config/no-x-libs.nix+6−3
This diff is too big to show here.
nixos/modules/config/nsswitch.nix+91−58
This diff is too big to show here.
nixos/modules/config/power-management.nix+5−5
This diff is too big to show here.
nixos/modules/config/pulseaudio.nix+45−34
This diff is too big to show here.
nixos/modules/config/qt5.nixnew file+104
This diff is too big to show here.
nixos/modules/config/resolvconf.nixnew file+145
This diff is too big to show here.
nixos/modules/config/shells-environment.nix+31−9
This diff is too big to show here.
nixos/modules/config/swap.nix+36−9
This diff is too big to show here.
nixos/modules/config/sysctl.nix+5−11
This diff is too big to show here.
nixos/modules/config/system-environment.nix+71−10
This diff is too big to show here.
nixos/modules/config/system-path.nix+54−12
This diff is too big to show here.
nixos/modules/config/terminfo.nix+27−3
This diff is too big to show here.
nixos/modules/config/timezone.nixdeleted−59
This diff is too big to show here.
nixos/modules/config/unix-odbc-drivers.nix+2−2
This diff is too big to show here.
nixos/modules/config/update-users-groups.pl+111−28
This diff is too big to show here.
nixos/modules/config/users-groups.nix+194−77
This diff is too big to show here.
nixos/modules/config/vpnc.nixdeleted−41
This diff is too big to show here.
nixos/modules/config/vte.nixnew file+56
This diff is too big to show here.
nixos/modules/config/xdg/autostart.nix+6−2
This diff is too big to show here.
nixos/modules/config/xdg/icons.nix+23−8
This diff is too big to show here.
nixos/modules/config/xdg/menus.nix+6−2
This diff is too big to show here.
nixos/modules/config/xdg/mime.nix+68−2
This diff is too big to show here.
nixos/modules/config/xdg/portal.nixnew file+81
This diff is too big to show here.
nixos/modules/config/xdg/portals/wlr.nixnew file+67
This diff is too big to show here.
nixos/modules/config/xdg/sounds.nixnew file+30
This diff is too big to show here.
nixos/modules/config/zram.nix+83−16
This diff is too big to show here.
nixos/modules/hardware/acpilight.nixnew file+25
This diff is too big to show here.
nixos/modules/hardware/all-firmware.nix+42−5
This diff is too big to show here.
nixos/modules/hardware/bladeRF.nixnew file+28
This diff is too big to show here.
nixos/modules/hardware/brightnessctl.nixdeleted−30
This diff is too big to show here.
nixos/modules/hardware/brillo.nixnew file+22
This diff is too big to show here.
nixos/modules/hardware/ckb-next.nix+6−2
This diff is too big to show here.
nixos/modules/hardware/corectrl.nixnew file+62
This diff is too big to show here.
nixos/modules/hardware/cpu/intel-sgx.nixnew file+69
This diff is too big to show here.
nixos/modules/hardware/device-tree.nixnew file+205
This diff is too big to show here.
nixos/modules/hardware/digitalbitbox.nix+1−1
This diff is too big to show here.
nixos/modules/hardware/flirc.nixnew file+12
This diff is too big to show here.
nixos/modules/hardware/gkraken.nixnew file+18
This diff is too big to show here.
nixos/modules/hardware/gpgsmartcards.nixnew file+37
This diff is too big to show here.
nixos/modules/hardware/hackrf.nixnew file+23
This diff is too big to show here.
nixos/modules/hardware/i2c.nixnew file+43
This diff is too big to show here.
nixos/modules/hardware/keyboard/teck.nixnew file+16
This diff is too big to show here.
nixos/modules/hardware/keyboard/zsa.nixnew file+24
This diff is too big to show here.
nixos/modules/hardware/ksm.nix+28−8
This diff is too big to show here.
nixos/modules/hardware/ledger.nixnew file+14
This diff is too big to show here.
nixos/modules/hardware/logitech.nixnew file+96
This diff is too big to show here.
nixos/modules/hardware/network/ath-user-regd.nixnew file+31
This diff is too big to show here.
nixos/modules/hardware/network/b43.nix−4
This diff is too big to show here.
nixos/modules/hardware/nitrokey.nix+1−15
This diff is too big to show here.
nixos/modules/hardware/onlykey.nixdeleted−33
This diff is too big to show here.
nixos/modules/hardware/onlykey.udevdeleted−4
This diff is too big to show here.
nixos/modules/hardware/onlykey/default.nixnew file+33
This diff is too big to show here.
nixos/modules/hardware/onlykey/onlykey.udevnew file+18
This diff is too big to show here.
nixos/modules/hardware/opengl.nix+39−37
This diff is too big to show here.
nixos/modules/hardware/openrazer.nixnew file+146
This diff is too big to show here.
nixos/modules/hardware/opentabletdriver.nixnew file+69
This diff is too big to show here.
nixos/modules/hardware/pcmcia.nix+1
This diff is too big to show here.
nixos/modules/hardware/printers.nixnew file+130
This diff is too big to show here.
nixos/modules/hardware/raid/hpsa.nix+6−3
This diff is too big to show here.
nixos/modules/hardware/rtl-sdr.nixnew file+23
This diff is too big to show here.
nixos/modules/hardware/sata.nixnew file+100
This diff is too big to show here.
nixos/modules/hardware/sensor/hddtemp.nixnew file+81
This diff is too big to show here.
nixos/modules/hardware/sensor/iio.nix+6−1
This diff is too big to show here.
nixos/modules/hardware/steam-hardware.nix+7
This diff is too big to show here.
nixos/modules/hardware/system-76.nixnew file+89
This diff is too big to show here.
nixos/modules/hardware/tuxedo-keyboard.nixnew file+35
This diff is too big to show here.
nixos/modules/hardware/ubertooth.nixnew file+29
This diff is too big to show here.
nixos/modules/hardware/uinput.nixnew file+19
This diff is too big to show here.
nixos/modules/hardware/usb-wwan.nix+13
This diff is too big to show here.
nixos/modules/hardware/video/amdgpu-pro.nix+27−23
This diff is too big to show here.
nixos/modules/hardware/video/amdgpu.nixdeleted−9
This diff is too big to show here.
nixos/modules/hardware/video/ati.nixdeleted−39
This diff is too big to show here.
nixos/modules/hardware/video/bumblebee.nix+1−1
This diff is too big to show here.
nixos/modules/hardware/video/capture/mwprocapture.nix−5
This diff is too big to show here.
nixos/modules/hardware/video/displaylink.nix+16−6
This diff is too big to show here.
nixos/modules/hardware/video/hidpi.nixnew file+16
This diff is too big to show here.
nixos/modules/hardware/video/nvidia.nix+287−85
This diff is too big to show here.
nixos/modules/hardware/video/switcheroo-control.nixnew file+18
This diff is too big to show here.
nixos/modules/hardware/video/uvcvideo/default.nix+2−2
This diff is too big to show here.
nixos/modules/hardware/video/uvcvideo/uvcdynctrl-udev-rules.nix+1
This diff is too big to show here.
nixos/modules/hardware/video/webcam/facetimehd.nix+14−6
This diff is too big to show here.
nixos/modules/hardware/wooting.nixnew file+12
This diff is too big to show here.
nixos/modules/hardware/xone.nixnew file+23
This diff is too big to show here.
nixos/modules/hardware/xpadneo.nixnew file+29
This diff is too big to show here.
nixos/modules/i18n/input-method/default.nix+4−1
This diff is too big to show here.
nixos/modules/i18n/input-method/default.xml+47
This diff is too big to show here.
nixos/modules/i18n/input-method/fcitx.nix+4−1
This diff is too big to show here.
nixos/modules/i18n/input-method/fcitx5.nixnew file+47
This diff is too big to show here.
nixos/modules/i18n/input-method/hime.nixnew file+14
This diff is too big to show here.
nixos/modules/i18n/input-method/ibus.nix+23−4
This diff is too big to show here.
nixos/modules/i18n/input-method/kime.nixnew file+51
This diff is too big to show here.
nixos/modules/i18n/input-method/uim.nix+1−1
This diff is too big to show here.
nixos/modules/installer/cd-dvd/channel.nix+7−4
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-base.nix+20−3
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-base.nix+35−22
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-calamares-gnome.nixnew file+59
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-calamares-plasma5.nixnew file+49
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-calamares.nixnew file+20
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-gnome.nix+26−11
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-kde-new-kernel.nixdeleted−7
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-kde.nixdeleted−44
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-plasma5-new-kernel.nixnew file+7
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-graphical-plasma5.nixnew file+48
This diff is too big to show here.
nixos/modules/installer/cd-dvd/installation-cd-minimal.nix+2
This diff is too big to show here.
nixos/modules/installer/cd-dvd/iso-image.nix+301−114
This diff is too big to show here.
nixos/modules/installer/cd-dvd/sd-image-aarch64-new-kernel.nixnew file+14
This diff is too big to show here.
nixos/modules/installer/cd-dvd/sd-image-aarch64.nix+9−55
This diff is too big to show here.
nixos/modules/installer/cd-dvd/sd-image-armv7l-multiplatform.nix+9−58
This diff is too big to show here.
nixos/modules/installer/cd-dvd/sd-image-raspberrypi.nix+9−47
This diff is too big to show here.
nixos/modules/installer/cd-dvd/sd-image.nix+10−164
This diff is too big to show here.
nixos/modules/installer/cd-dvd/system-tarball-fuloong2f.nix+3−3
This diff is too big to show here.
nixos/modules/installer/cd-dvd/system-tarball-pc-readme.txt+1−1
This diff is too big to show here.
nixos/modules/installer/cd-dvd/system-tarball-pc.nix+6−7
This diff is too big to show here.
nixos/modules/installer/cd-dvd/system-tarball-sheevaplug.nix+8−9
This diff is too big to show here.
nixos/modules/installer/cd-dvd/system-tarball.nix+4−4
This diff is too big to show here.
nixos/modules/installer/kexec/kexec-boot.nixnew file+51
This diff is too big to show here.
nixos/modules/installer/netboot/netboot.nix+25−14
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-aarch64-installer.nixnew file+10
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-aarch64-new-kernel-installer.nixnew file+10
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-aarch64-new-kernel.nixnew file+7
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-aarch64.nixnew file+83
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-armv7l-multiplatform-installer.nixnew file+10
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-armv7l-multiplatform.nixnew file+52
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-raspberrypi-installer.nixnew file+10
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-raspberrypi.nixnew file+41
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-riscv64-qemu-installer.nixnew file+10
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-riscv64-qemu.nixnew file+32
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image-x86_64.nixnew file+27
This diff is too big to show here.
nixos/modules/installer/sd-card/sd-image.nixnew file+269
This diff is too big to show here.
nixos/modules/installer/tools/nix-fallback-paths.nix+5−4
This diff is too big to show here.
nixos/modules/installer/tools/nixos-build-vms/build-vms.nix+23−5
This diff is too big to show here.
nixos/modules/installer/tools/nixos-build-vms/nixos-build-vms.sh+30−34
This diff is too big to show here.
nixos/modules/installer/tools/nixos-enter.sh+54−6
This diff is too big to show here.
nixos/modules/installer/tools/nixos-generate-config.pl+128−98
This diff is too big to show here.
nixos/modules/installer/tools/nixos-install.sh+103−29
This diff is too big to show here.
nixos/modules/installer/tools/nixos-option.shdeleted−327
This diff is too big to show here.
nixos/modules/installer/tools/nixos-option/default.nixnew file+1
This diff is too big to show here.
nixos/modules/installer/tools/nixos-rebuild.shdeleted−387
This diff is too big to show here.
nixos/modules/installer/tools/nixos-version.sh+11−1
This diff is too big to show here.
nixos/modules/installer/tools/tools.nix+178−20
This diff is too big to show here.
nixos/modules/installer/virtualbox-demo.nix+2−4
This diff is too big to show here.
nixos/modules/misc/crashdump.nix+3−3
This diff is too big to show here.
nixos/modules/misc/documentation.nix+190−42
This diff is too big to show here.
nixos/modules/misc/extra-arguments.nix+2−2
This diff is too big to show here.
nixos/modules/misc/ids.nix+129−101
This diff is too big to show here.
nixos/modules/misc/locate.nix+200−69
This diff is too big to show here.
nixos/modules/misc/man-db.nixnew file+73
This diff is too big to show here.
nixos/modules/misc/mandoc.nixnew file+61
This diff is too big to show here.
nixos/modules/misc/meta.nix+18−3
This diff is too big to show here.
nixos/modules/misc/nixops-autoluks.nixnew file+43
This diff is too big to show here.
nixos/modules/misc/nixpkgs.nix+34−20
This diff is too big to show here.
nixos/modules/misc/nixpkgs/test.nixnew file+8
This diff is too big to show here.
nixos/modules/misc/version.nix+76−26
This diff is too big to show here.
nixos/modules/misc/wordlist.nixnew file+59
This diff is too big to show here.
nixos/modules/module-list.nix+514−110
This diff is too big to show here.
nixos/modules/profiles/all-hardware.nix+70−4
This diff is too big to show here.
nixos/modules/profiles/base.nix+2
This diff is too big to show here.
nixos/modules/profiles/demo.nix+6−4
This diff is too big to show here.
nixos/modules/profiles/docker-container.nix+8−1
This diff is too big to show here.
nixos/modules/profiles/graphical.nix+3−1
This diff is too big to show here.
nixos/modules/profiles/hardened.nix+76−39
This diff is too big to show here.
nixos/modules/profiles/headless.nix+1−2
This diff is too big to show here.
nixos/modules/profiles/installation-device.nix+49−21
This diff is too big to show here.
nixos/modules/profiles/minimal.nix+3−1
This diff is too big to show here.
nixos/modules/profiles/qemu-guest.nix+2−4
This diff is too big to show here.
nixos/modules/programs/_1password-gui.nixnew file+68
This diff is too big to show here.
nixos/modules/programs/_1password.nixnew file+44
This diff is too big to show here.
nixos/modules/programs/adb.nix+1−2
This diff is too big to show here.
nixos/modules/programs/appgate-sdp.nixnew file+25
This diff is too big to show here.
nixos/modules/programs/atop.nix+127−8
This diff is too big to show here.
nixos/modules/programs/autojump.nixnew file+33
This diff is too big to show here.
nixos/modules/programs/bandwhich.nixnew file+31
This diff is too big to show here.
nixos/modules/programs/bash-my-aws.nixnew file+25
This diff is too big to show here.
nixos/modules/programs/bash/bash-completion.nixnew file+37
This diff is too big to show here.
nixos/modules/programs/bash/bash.nix+23−39
This diff is too big to show here.
nixos/modules/programs/bash/ls-colors.nixnew file+20
This diff is too big to show here.
nixos/modules/programs/bash/undistract-me.nixnew file+36
This diff is too big to show here.
nixos/modules/programs/bcc.nix+3−3
This diff is too big to show here.
nixos/modules/programs/blcr.nixdeleted−27
This diff is too big to show here.
nixos/modules/programs/browserpass.nix+20−11
This diff is too big to show here.
nixos/modules/programs/calls.nixnew file+27
This diff is too big to show here.
nixos/modules/programs/captive-browser.nixnew file+152
This diff is too big to show here.
nixos/modules/programs/ccache.nix+4−2
This diff is too big to show here.
nixos/modules/programs/cdemu.nix+4
This diff is too big to show here.
nixos/modules/programs/chromium.nix+34−8
This diff is too big to show here.
nixos/modules/programs/clickshare.nixnew file+21
This diff is too big to show here.
nixos/modules/programs/cnping.nixnew file+21
This diff is too big to show here.
nixos/modules/programs/command-not-found/command-not-found.nix+9−9
This diff is too big to show here.
nixos/modules/programs/command-not-found/command-not-found.pl+43−17
This diff is too big to show here.
nixos/modules/programs/criu.nix+1
This diff is too big to show here.
nixos/modules/programs/dconf.nix+35−13
This diff is too big to show here.
nixos/modules/programs/digitalbitbox/default.nix+1−1
This diff is too big to show here.
nixos/modules/programs/dmrconfig.nix+1−1
This diff is too big to show here.
nixos/modules/programs/droidcam.nixnew file+16
This diff is too big to show here.
nixos/modules/programs/environment.nix+13−8
This diff is too big to show here.
nixos/modules/programs/evince.nixnew file+51
This diff is too big to show here.
nixos/modules/programs/extra-container.nixnew file+17
This diff is too big to show here.
nixos/modules/programs/feedbackd.nixnew file+33
This diff is too big to show here.
nixos/modules/programs/file-roller.nixnew file+48
This diff is too big to show here.
nixos/modules/programs/firejail.nix+65−16
This diff is too big to show here.
nixos/modules/programs/fish.nix+209−77
This diff is too big to show here.
nixos/modules/programs/fish_completion-generator.patchnew file+14
This diff is too big to show here.
nixos/modules/programs/flashrom.nixnew file+26
This diff is too big to show here.
nixos/modules/programs/flexoptix-app.nixnew file+25
This diff is too big to show here.
nixos/modules/programs/freetds.nix+3−3
This diff is too big to show here.
nixos/modules/programs/fuse.nixnew file+37
This diff is too big to show here.
nixos/modules/programs/gamemode.nixnew file+98
This diff is too big to show here.
nixos/modules/programs/geary.nixnew file+24
This diff is too big to show here.
nixos/modules/programs/git.nixnew file+69
This diff is too big to show here.
nixos/modules/programs/gnome-disks.nixnew file+50
This diff is too big to show here.
nixos/modules/programs/gnome-documents.nixnew file+54
This diff is too big to show here.
nixos/modules/programs/gnome-terminal.nixnew file+38
This diff is too big to show here.
nixos/modules/programs/gnupg.nix+57−4
This diff is too big to show here.
nixos/modules/programs/gpaste.nixnew file+36
This diff is too big to show here.
nixos/modules/programs/hamster.nixnew file+15
This diff is too big to show here.
nixos/modules/programs/htop.nixnew file+58
This diff is too big to show here.
nixos/modules/programs/iftop.nix+3−1
This diff is too big to show here.
nixos/modules/programs/iotop.nixnew file+19
This diff is too big to show here.
nixos/modules/programs/java.nix+1−1
This diff is too big to show here.
nixos/modules/programs/k3b.nixnew file+52
This diff is too big to show here.
nixos/modules/programs/k40-whisperer.nixnew file+40
This diff is too big to show here.
nixos/modules/programs/kbdlight.nix+6−1
This diff is too big to show here.
nixos/modules/programs/kclock.nixnew file+13
This diff is too big to show here.
nixos/modules/programs/kdeconnect.nixnew file+35
This diff is too big to show here.
nixos/modules/programs/less.nix+14−11
This diff is too big to show here.
nixos/modules/programs/liboping.nixnew file+24
This diff is too big to show here.
nixos/modules/programs/mininet.nix+3−3
This diff is too big to show here.
nixos/modules/programs/mosh.nix+1−1
This diff is too big to show here.
nixos/modules/programs/msmtp.nixnew file+106
This diff is too big to show here.
nixos/modules/programs/mtr.nix+15−2
This diff is too big to show here.
nixos/modules/programs/nano.nix+4−3
This diff is too big to show here.
nixos/modules/programs/nbd.nixnew file+19
This diff is too big to show here.
nixos/modules/programs/neovim.nixnew file+166
This diff is too big to show here.
nixos/modules/programs/nethoscope.nixnew file+30
This diff is too big to show here.
nixos/modules/programs/nix-ld.nixnew file+12
This diff is too big to show here.
nixos/modules/programs/nm-applet.nixnew file+31
This diff is too big to show here.
nixos/modules/programs/nncp.nixnew file+101
This diff is too big to show here.
nixos/modules/programs/noisetorch.nixnew file+28
This diff is too big to show here.
nixos/modules/programs/npm.nix+11−3
This diff is too big to show here.
nixos/modules/programs/nylas-mail.nixdeleted−36
This diff is too big to show here.
nixos/modules/programs/oblogout.nix+3−168
This diff is too big to show here.
nixos/modules/programs/pantheon-tweaks.nixnew file+19
This diff is too big to show here.
nixos/modules/programs/partition-manager.nixnew file+19
This diff is too big to show here.
nixos/modules/programs/phosh.nixnew file+162
This diff is too big to show here.
nixos/modules/programs/plotinus.nix+2−2
This diff is too big to show here.
nixos/modules/programs/plotinus.xml+2−2
This diff is too big to show here.
nixos/modules/programs/proxychains.nixnew file+165
This diff is too big to show here.
nixos/modules/programs/qt5ct.nix+1−1
This diff is too big to show here.
nixos/modules/programs/screen.nix+2−1
This diff is too big to show here.
nixos/modules/programs/seahorse.nixnew file+46
This diff is too big to show here.
nixos/modules/programs/shadow.nix+39−26
This diff is too big to show here.
nixos/modules/programs/shell.nixdeleted−54
This diff is too big to show here.
nixos/modules/programs/singularity.nix+20−6
This diff is too big to show here.
nixos/modules/programs/slock.nix+6−1
This diff is too big to show here.
nixos/modules/programs/spacefm.nix+6−6
This diff is too big to show here.
nixos/modules/programs/ssh.nix+136−33
This diff is too big to show here.
nixos/modules/programs/ssmtp.nixdeleted−165
This diff is too big to show here.
nixos/modules/programs/starship.nixnew file+51
This diff is too big to show here.
nixos/modules/programs/steam.nixnew file+63
This diff is too big to show here.
nixos/modules/programs/sway-beta.nixdeleted−79
This diff is too big to show here.
nixos/modules/programs/sway.nix+107−42
This diff is too big to show here.
nixos/modules/programs/system-config-printer.nixnew file+32
This diff is too big to show here.
nixos/modules/programs/systemtap.nix+1
This diff is too big to show here.
nixos/modules/programs/thefuck.nix+8−7
This diff is too big to show here.
nixos/modules/programs/tmux.nix+21−4
This diff is too big to show here.
nixos/modules/programs/traceroute.nixnew file+28
This diff is too big to show here.
nixos/modules/programs/tsm-client.nixnew file+287
This diff is too big to show here.
nixos/modules/programs/turbovnc.nixnew file+54
This diff is too big to show here.
nixos/modules/programs/udevil.nix+6−1
This diff is too big to show here.
nixos/modules/programs/usbtop.nixnew file+21
This diff is too big to show here.
nixos/modules/programs/venus.nixdeleted−173
This diff is too big to show here.
nixos/modules/programs/vim.nix+12−2
This diff is too big to show here.
nixos/modules/programs/wavemon.nix+3−1
This diff is too big to show here.
nixos/modules/programs/way-cooler.nixdeleted−78
This diff is too big to show here.
nixos/modules/programs/waybar.nixnew file+20
This diff is too big to show here.
nixos/modules/programs/weylus.nixnew file+47
This diff is too big to show here.
nixos/modules/programs/wireshark.nix+1−1
This diff is too big to show here.
nixos/modules/programs/wshowkeys.nixnew file+27
This diff is too big to show here.
nixos/modules/programs/xfs_quota.nix+1−1
This diff is too big to show here.
nixos/modules/programs/xonsh.nix+31−5
This diff is too big to show here.
nixos/modules/programs/xss-lock.nix+22−3
This diff is too big to show here.
nixos/modules/programs/xwayland.nixnew file+50
This diff is too big to show here.
nixos/modules/programs/yabar.nix+6−5
This diff is too big to show here.
nixos/modules/programs/zmap.nixnew file+18
This diff is too big to show here.
nixos/modules/programs/zsh/oh-my-zsh.nix+9−1
This diff is too big to show here.
nixos/modules/programs/zsh/oh-my-zsh.xml+6−6
This diff is too big to show here.
nixos/modules/programs/zsh/zsh-autoenv.nix+1−1
This diff is too big to show here.
nixos/modules/programs/zsh/zsh-autosuggestions.nix+25−12
This diff is too big to show here.
nixos/modules/programs/zsh/zsh-syntax-highlighting.nix+33−4
This diff is too big to show here.
nixos/modules/programs/zsh/zsh.nix+118−27
This diff is too big to show here.
nixos/modules/rename.nix+90−283
This diff is too big to show here.
nixos/modules/security/acme.nixdeleted−391
This diff is too big to show here.
nixos/modules/security/acme.xmldeleted−99
This diff is too big to show here.
nixos/modules/security/acme/default.nixnew file+921
This diff is too big to show here.
nixos/modules/security/acme/doc.xmlnew file+413
This diff is too big to show here.
nixos/modules/security/acme/mk-cert-ownership-assertion.nixnew file+4
This diff is too big to show here.
nixos/modules/security/apparmor-suid.nixdeleted−45
This diff is too big to show here.
nixos/modules/security/apparmor.nix+208−41
This diff is too big to show here.
nixos/modules/security/apparmor/includes.nixnew file+317
This diff is too big to show here.
nixos/modules/security/apparmor/profiles.nixnew file+11
This diff is too big to show here.
nixos/modules/security/auditd.nix+4
This diff is too big to show here.
nixos/modules/security/ca.nix+11−16
This diff is too big to show here.
nixos/modules/security/chromium-suid-sandbox.nix+10−1
This diff is too big to show here.
nixos/modules/security/dhparams.nix+5−3
This diff is too big to show here.
nixos/modules/security/doas.nixnew file+288
This diff is too big to show here.
nixos/modules/security/duosec.nix+82−48
This diff is too big to show here.
nixos/modules/security/google_oslogin.nixnew file+71
This diff is too big to show here.
nixos/modules/security/hidepid.nixdeleted−27
This diff is too big to show here.
nixos/modules/security/hidepid.xmldeleted−28
This diff is too big to show here.
nixos/modules/security/lock-kernel-modules.nix+19−9
This diff is too big to show here.
nixos/modules/security/misc.nix+135−19
This diff is too big to show here.
nixos/modules/security/pam.nix+826−158
This diff is too big to show here.
nixos/modules/security/pam_mount.nix+116−14
This diff is too big to show here.
nixos/modules/security/pam_usb.nix+12−2
This diff is too big to show here.
nixos/modules/security/polkit.nix+17−10
This diff is too big to show here.
nixos/modules/security/prey.nixdeleted−51
This diff is too big to show here.
nixos/modules/security/rngd.nix+14−33
This diff is too big to show here.
nixos/modules/security/rtkit.nix+5−3
This diff is too big to show here.
nixos/modules/security/sudo.nix+68−31
This diff is too big to show here.
nixos/modules/security/systemd-confinement.nixnew file+202
This diff is too big to show here.
nixos/modules/security/tpm2.nixnew file+184
This diff is too big to show here.
nixos/modules/security/wrappers/default.nix+204−101
This diff is too big to show here.
nixos/modules/security/wrappers/wrapper.c+162−168
This diff is too big to show here.
nixos/modules/security/wrappers/wrapper.nixnew file+21
This diff is too big to show here.
nixos/modules/services/admin/meshcentral.nixnew file+53
This diff is too big to show here.
nixos/modules/services/admin/oxidized.nix+7−5
This diff is too big to show here.
nixos/modules/services/admin/pgadmin.nixnew file+127
This diff is too big to show here.
nixos/modules/services/admin/salt/master.nix+2−2
This diff is too big to show here.
nixos/modules/services/admin/salt/minion.nix+1−1
This diff is too big to show here.
nixos/modules/services/amqp/activemq/default.nix+10−6
This diff is too big to show here.
nixos/modules/services/amqp/rabbitmq.nix+36−18
This diff is too big to show here.
nixos/modules/services/audio/alsa.nix+15−16
This diff is too big to show here.
nixos/modules/services/audio/botamusique.nixnew file+115
This diff is too big to show here.
nixos/modules/services/audio/hqplayerd.nixnew file+142
This diff is too big to show here.
nixos/modules/services/audio/icecast.nix+4−3
This diff is too big to show here.
nixos/modules/services/audio/jack.nixnew file+294
This diff is too big to show here.
nixos/modules/services/audio/jmusicbot.nixnew file+48
This diff is too big to show here.
nixos/modules/services/audio/liquidsoap.nix+4−9
This diff is too big to show here.
nixos/modules/services/audio/mopidy.nix+8−8
This diff is too big to show here.
nixos/modules/services/audio/mpd.nix+113−50
This diff is too big to show here.
nixos/modules/services/audio/mpdscribble.nixnew file+213
This diff is too big to show here.
nixos/modules/services/audio/navidrome.nixnew file+71
This diff is too big to show here.
nixos/modules/services/audio/networkaudiod.nixnew file+19
This diff is too big to show here.
nixos/modules/services/audio/roon-bridge.nixnew file+76
This diff is too big to show here.
nixos/modules/services/audio/roon-server.nixnew file+79
This diff is too big to show here.
nixos/modules/services/audio/slimserver.nix+6−3
This diff is too big to show here.
nixos/modules/services/audio/snapserver.nixnew file+323
This diff is too big to show here.
nixos/modules/services/audio/spotifyd.nixnew file+68
This diff is too big to show here.
nixos/modules/services/audio/squeezelite.nix+20−41
This diff is too big to show here.
nixos/modules/services/audio/ympd.nix+4−4
This diff is too big to show here.
nixos/modules/services/backup/automysqlbackup.nixnew file+119
This diff is too big to show here.
nixos/modules/services/backup/bacula.nix+193−27
This diff is too big to show here.
nixos/modules/services/backup/borgbackup.nix+143−29
This diff is too big to show here.
nixos/modules/services/backup/borgbackup.xmlnew file+209
This diff is too big to show here.
nixos/modules/services/backup/borgmatic.nixnew file+57
This diff is too big to show here.
nixos/modules/services/backup/btrbk.nixnew file+220
This diff is too big to show here.
nixos/modules/services/backup/crashplan-small-business.nixdeleted−73
This diff is too big to show here.
nixos/modules/services/backup/crashplan.nixdeleted−67
This diff is too big to show here.
nixos/modules/services/backup/duplicati.nix+41−12
This diff is too big to show here.
nixos/modules/services/backup/duplicity.nixnew file+196
This diff is too big to show here.
nixos/modules/services/backup/mysql-backup.nix+18−19
This diff is too big to show here.
nixos/modules/services/backup/postgresql-backup.nix+97−29
This diff is too big to show here.
nixos/modules/services/backup/postgresql-wal-receiver.nixnew file+204
This diff is too big to show here.
nixos/modules/services/backup/restic-rest-server.nix+5−1
This diff is too big to show here.
nixos/modules/services/backup/restic.nix+145−15
This diff is too big to show here.
nixos/modules/services/backup/rsnapshot.nix+2−2
This diff is too big to show here.
nixos/modules/services/backup/sanoid.nixnew file+204
This diff is too big to show here.
nixos/modules/services/backup/syncoid.nixnew file+421
This diff is too big to show here.
nixos/modules/services/backup/tarsnap.nix+35−29
This diff is too big to show here.
nixos/modules/services/backup/tsm.nixnew file+125
This diff is too big to show here.
nixos/modules/services/backup/zfs-replication.nixnew file+90
This diff is too big to show here.
nixos/modules/services/backup/znapzend.nix+99−34
This diff is too big to show here.
nixos/modules/services/backup/zrepl.nixnew file+57
This diff is too big to show here.
nixos/modules/services/blockchain/ethereum/geth.nixnew file+179
This diff is too big to show here.
nixos/modules/services/cluster/corosync/default.nixnew file+112
This diff is too big to show here.
nixos/modules/services/cluster/hadoop/conf.nix+25−12
This diff is too big to show here.
nixos/modules/services/cluster/hadoop/default.nix+193−30
This diff is too big to show here.
nixos/modules/services/cluster/hadoop/hdfs.nix+175−44
This diff is too big to show here.
nixos/modules/services/cluster/hadoop/yarn.nix+157−31
This diff is too big to show here.
nixos/modules/services/cluster/k3s/default.nixnew file+128
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/addon-manager.nixnew file+171
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/addons/dns.nixnew file+368
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/apiserver.nixnew file+500
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/controller-manager.nixnew file+176
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/dashboard.nixdeleted−321
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/default.nix+152−1037
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/dns.nixdeleted−320
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/flannel.nixnew file+100
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/kubelet.nixnew file+398
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/pki.nixnew file+406
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/proxy.nixnew file+102
This diff is too big to show here.
nixos/modules/services/cluster/kubernetes/scheduler.nixnew file+101
This diff is too big to show here.
nixos/modules/services/cluster/pacemaker/default.nixnew file+52
This diff is too big to show here.
nixos/modules/services/cluster/spark/default.nixnew file+162
This diff is too big to show here.
nixos/modules/services/computing/boinc/client.nix+10−9
This diff is too big to show here.
nixos/modules/services/computing/foldingathome/client.nixnew file+91
This diff is too big to show here.
nixos/modules/services/computing/slurm/slurm.nix+105−27
This diff is too big to show here.
nixos/modules/services/computing/torque/mom.nix+2−2
This diff is too big to show here.
nixos/modules/services/computing/torque/server.nix+2−2
This diff is too big to show here.
nixos/modules/services/continuous-integration/buildbot/master.nix+51−28
This diff is too big to show here.
nixos/modules/services/continuous-integration/buildbot/worker.nix+30−18
This diff is too big to show here.
nixos/modules/services/continuous-integration/buildkite-agent.nixdeleted−252
This diff is too big to show here.
nixos/modules/services/continuous-integration/buildkite-agents.nixnew file+280
This diff is too big to show here.
nixos/modules/services/continuous-integration/github-runner.nixnew file+320
This diff is too big to show here.
nixos/modules/services/continuous-integration/gitlab-runner.nix+534−93
This diff is too big to show here.
nixos/modules/services/continuous-integration/gocd-agent/default.nix+26−14
This diff is too big to show here.
nixos/modules/services/continuous-integration/gocd-server/default.nix+32−14
This diff is too big to show here.
nixos/modules/services/continuous-integration/hail.nix+1−1
This diff is too big to show here.
nixos/modules/services/continuous-integration/hercules-ci-agent/common.nixnew file+266
This diff is too big to show here.
nixos/modules/services/continuous-integration/hercules-ci-agent/default.nixnew file+101
This diff is too big to show here.
nixos/modules/services/continuous-integration/hydra/default.nix+105−32
This diff is too big to show here.
nixos/modules/services/continuous-integration/jenkins/default.nix+47−26
This diff is too big to show here.
nixos/modules/services/continuous-integration/jenkins/job-builder.nix+86−18
This diff is too big to show here.
nixos/modules/services/continuous-integration/jenkins/slave.nix+26−12
This diff is too big to show here.
nixos/modules/services/databases/4store-endpoint.nixdeleted−74
This diff is too big to show here.
nixos/modules/services/databases/4store.nixdeleted−72
This diff is too big to show here.
nixos/modules/services/databases/aerospike.nix+1
This diff is too big to show here.
nixos/modules/services/databases/cassandra.nix+415−143
This diff is too big to show here.
nixos/modules/services/databases/clickhouse.nix+21−18
This diff is too big to show here.
nixos/modules/services/databases/cockroachdb.nixnew file+225
This diff is too big to show here.
nixos/modules/services/databases/couchdb.nix+59−38
This diff is too big to show here.
nixos/modules/services/databases/firebird.nix+27−25
This diff is too big to show here.
nixos/modules/services/databases/foundationdb.nix+40−27
This diff is too big to show here.
nixos/modules/services/databases/foundationdb.xml+19−19
This diff is too big to show here.
nixos/modules/services/databases/hbase.nix+48−33
This diff is too big to show here.
nixos/modules/services/databases/influxdb.nix+19−19
This diff is too big to show here.
nixos/modules/services/databases/influxdb2.nixnew file+66
This diff is too big to show here.
nixos/modules/services/databases/memcached.nix+35−20
This diff is too big to show here.
nixos/modules/services/databases/monetdb.nix+1−1
This diff is too big to show here.
nixos/modules/services/databases/mongodb.nix+77−12
This diff is too big to show here.
nixos/modules/services/databases/mysql.nix+377−240
This diff is too big to show here.
nixos/modules/services/databases/neo4j.nix+29−8
This diff is too big to show here.
nixos/modules/services/databases/openldap.nix+255−90
This diff is too big to show here.
nixos/modules/services/databases/opentsdb.nix+3−4
This diff is too big to show here.
nixos/modules/services/databases/pgmanage.nix+8−7
This diff is too big to show here.
nixos/modules/services/databases/postgresql.nix+244−98
This diff is too big to show here.
nixos/modules/services/databases/postgresql.xml+158−21
This diff is too big to show here.
nixos/modules/services/databases/redis.nix+355−219
This diff is too big to show here.
nixos/modules/services/databases/rethinkdb.nix+3−5
This diff is too big to show here.
nixos/modules/services/databases/riak-cs.nixdeleted−202
This diff is too big to show here.
nixos/modules/services/databases/riak.nix+4−5
This diff is too big to show here.
nixos/modules/services/databases/stanchion.nixdeleted−202
This diff is too big to show here.
nixos/modules/services/databases/victoriametrics.nixnew file+78
This diff is too big to show here.
nixos/modules/services/databases/virtuoso.nixdeleted−98
This diff is too big to show here.
nixos/modules/services/desktops/accountsservice.nix+4
This diff is too big to show here.
nixos/modules/services/desktops/bamf.nix+4
This diff is too big to show here.
nixos/modules/services/desktops/blueman.nixnew file+25
This diff is too big to show here.
nixos/modules/services/desktops/cpupower-gui.nixnew file+56
This diff is too big to show here.
nixos/modules/services/desktops/espanso.nixnew file+24
This diff is too big to show here.
nixos/modules/services/desktops/flatpak.nix+21−17
This diff is too big to show here.
nixos/modules/services/desktops/flatpak.xml+12−12
This diff is too big to show here.
nixos/modules/services/desktops/geoclue2.nix+209−5
This diff is too big to show here.
nixos/modules/services/desktops/gnome/at-spi2-core.nixnew file+57
This diff is too big to show here.
nixos/modules/services/desktops/gnome/chrome-gnome-shell.nixnew file+41
This diff is too big to show here.
nixos/modules/services/desktops/gnome/evolution-data-server.nixnew file+71
This diff is too big to show here.
nixos/modules/services/desktops/gnome/glib-networking.nixnew file+45
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-initial-setup.nixnew file+98
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-keyring.nixnew file+63
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-online-accounts.nixnew file+51
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-online-miners.nixnew file+51
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-remote-desktop.nixnew file+32
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-settings-daemon.nixnew file+70
This diff is too big to show here.
nixos/modules/services/desktops/gnome/gnome-user-share.nixnew file+48
This diff is too big to show here.
nixos/modules/services/desktops/gnome/rygel.nixnew file+44
This diff is too big to show here.
nixos/modules/services/desktops/gnome/sushi.nixnew file+50
This diff is too big to show here.
nixos/modules/services/desktops/gnome/tracker-miners.nixnew file+54
This diff is too big to show here.
nixos/modules/services/desktops/gnome/tracker.nixnew file+76
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/at-spi2-core.nixdeleted−42
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/chrome-gnome-shell.nixdeleted−27
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/evolution-data-server.nixdeleted−41
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-disks.nixdeleted−39
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-documents.nixdeleted−43
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-keyring.nixdeleted−40
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-online-accounts.nixdeleted−39
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-online-miners.nixdeleted−39
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-terminal-server.nixdeleted−41
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gnome-user-share.nixdeleted−42
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gpaste.nixdeleted−27
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/gvfs.nixdeleted−43
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/rygel.nixdeleted−30
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/seahorse.nixdeleted−38
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/sushi.nixdeleted−38
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/tracker-miners.nixdeleted−41
This diff is too big to show here.
nixos/modules/services/desktops/gnome3/tracker.nixdeleted−41
This diff is too big to show here.
nixos/modules/services/desktops/gsignond.nix+2
This diff is too big to show here.
nixos/modules/services/desktops/gvfs.nixnew file+64
This diff is too big to show here.
nixos/modules/services/desktops/malcontent.nixnew file+40
This diff is too big to show here.
nixos/modules/services/desktops/neard.nixnew file+23
This diff is too big to show here.
nixos/modules/services/desktops/pipewire.nixdeleted−37
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/client-rt.conf.jsonnew file+39
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/client.conf.jsonnew file+31
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/jack.conf.jsonnew file+38
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/minimal.conf.jsonnew file+118
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/pipewire-pulse.conf.jsonnew file+100
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/daemon/pipewire.conf.jsonnew file+96
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/media-session/alsa-monitor.conf.jsonnew file+34
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/media-session/bluez-monitor.conf.jsonnew file+36
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/media-session/media-session.conf.jsonnew file+68
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/media-session/v4l2-monitor.conf.jsonnew file+30
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/pipewire-media-session.nixnew file+141
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/pipewire.nixnew file+262
This diff is too big to show here.
nixos/modules/services/desktops/pipewire/wireplumber.nixnew file+54
This diff is too big to show here.
nixos/modules/services/desktops/profile-sync-daemon.nix+3−3
This diff is too big to show here.
nixos/modules/services/desktops/system-config-printer.nixnew file+41
This diff is too big to show here.
nixos/modules/services/desktops/telepathy.nix+9
This diff is too big to show here.
nixos/modules/services/desktops/tumbler.nixnew file+52
This diff is too big to show here.
nixos/modules/services/desktops/zeitgeist.nix+5
This diff is too big to show here.
nixos/modules/services/development/blackfire.nixnew file+60
This diff is too big to show here.
nixos/modules/services/development/blackfire.xmlnew file+46
This diff is too big to show here.
nixos/modules/services/development/bloop.nix+20−3
This diff is too big to show here.
nixos/modules/services/development/distccd.nixnew file+155
This diff is too big to show here.
nixos/modules/services/development/hoogle.nix+13−8
This diff is too big to show here.
nixos/modules/services/development/jupyter/default.nix+31−14
This diff is too big to show here.
nixos/modules/services/development/jupyter/kernel-options.nix+4−4
This diff is too big to show here.
nixos/modules/services/development/jupyterhub/default.nixnew file+202
This diff is too big to show here.
nixos/modules/services/development/lorri.nixnew file+55
This diff is too big to show here.
nixos/modules/services/development/rstudio-server/default.nixnew file+107
This diff is too big to show here.
nixos/modules/services/development/zammad.nixnew file+323
This diff is too big to show here.
nixos/modules/services/display-managers/greetd.nixnew file+111
This diff is too big to show here.
nixos/modules/services/editors/emacs.nix+26−31
This diff is too big to show here.
nixos/modules/services/editors/emacs.xml+26−33
This diff is too big to show here.
nixos/modules/services/editors/haste.nixnew file+86
This diff is too big to show here.
nixos/modules/services/editors/infinoted.nix+14−12
This diff is too big to show here.
nixos/modules/services/finance/odoo.nixnew file+122
This diff is too big to show here.
nixos/modules/services/games/asf.nixnew file+236
This diff is too big to show here.
nixos/modules/services/games/crossfire-server.nixnew file+179
This diff is too big to show here.
nixos/modules/services/games/deliantra-server.nixnew file+172
This diff is too big to show here.
nixos/modules/services/games/factorio.nix+90−41
This diff is too big to show here.
nixos/modules/services/games/freeciv.nixnew file+187
This diff is too big to show here.
nixos/modules/services/games/minecraft-server.nix+205−21
This diff is too big to show here.
nixos/modules/services/games/minetest-server.nix+9−9
This diff is too big to show here.
nixos/modules/services/games/openarena.nixnew file+56
This diff is too big to show here.
nixos/modules/services/games/quake3-server.nixnew file+112
This diff is too big to show here.
nixos/modules/services/games/teeworlds.nixnew file+119
This diff is too big to show here.
nixos/modules/services/games/terraria.nix+31−11
This diff is too big to show here.
nixos/modules/services/hardware/80-net-setup-link.rulesdeleted−13
This diff is too big to show here.
nixos/modules/services/hardware/acpid.nix+17−18
This diff is too big to show here.
nixos/modules/services/hardware/actkbd.nix+3−3
This diff is too big to show here.
nixos/modules/services/hardware/auto-cpufreq.nixnew file+24
This diff is too big to show here.
nixos/modules/services/hardware/bluetooth.nix+98−41
This diff is too big to show here.
nixos/modules/services/hardware/bolt.nixnew file+34
This diff is too big to show here.
nixos/modules/services/hardware/brltty.nix+32−25
This diff is too big to show here.
nixos/modules/services/hardware/ddccontrol.nixnew file+39
This diff is too big to show here.
nixos/modules/services/hardware/fancontrol.nixnew file+48
This diff is too big to show here.
nixos/modules/services/hardware/freefall.nix+2−2
This diff is too big to show here.
nixos/modules/services/hardware/fwupd.nix+69−32
This diff is too big to show here.
nixos/modules/services/hardware/interception-tools.nix+1
This diff is too big to show here.
nixos/modules/services/hardware/irqbalance.nix+4−10
This diff is too big to show here.
nixos/modules/services/hardware/joycond.nixnew file+36
This diff is too big to show here.
nixos/modules/services/hardware/lcd.nix+2−3
This diff is too big to show here.
nixos/modules/services/hardware/lirc.nix+15−4
This diff is too big to show here.
nixos/modules/services/hardware/pcscd.nix+45−41
This diff is too big to show here.
nixos/modules/services/hardware/power-profiles-daemon.nixnew file+55
This diff is too big to show here.
nixos/modules/services/hardware/rasdaemon.nixnew file+170
This diff is too big to show here.
nixos/modules/services/hardware/ratbagd.nix+1−6
This diff is too big to show here.
nixos/modules/services/hardware/sane.nix+44−9
This diff is too big to show here.
nixos/modules/services/hardware/sane_extra_backends/brscan4.nix+9−12
This diff is too big to show here.
nixos/modules/services/hardware/sane_extra_backends/brscan4_etc_files.nix+10−13
This diff is too big to show here.
nixos/modules/services/hardware/sane_extra_backends/brscan5.nixnew file+110
This diff is too big to show here.
nixos/modules/services/hardware/sane_extra_backends/brscan5_etc_files.nixnew file+77
This diff is too big to show here.
nixos/modules/services/hardware/sane_extra_backends/dsseries.nixnew file+26
This diff is too big to show here.
nixos/modules/services/hardware/spacenavd.nixnew file+24
This diff is too big to show here.
nixos/modules/services/hardware/tcsd.nix+38−27
This diff is too big to show here.
nixos/modules/services/hardware/thermald.nix+15−10
This diff is too big to show here.
nixos/modules/services/hardware/thinkfan.nix+174−92
This diff is too big to show here.
nixos/modules/services/hardware/throttled.nixnew file+36
This diff is too big to show here.
nixos/modules/services/hardware/tlp.nix+89−82
This diff is too big to show here.
nixos/modules/services/hardware/trezord.nix+29−19
This diff is too big to show here.
nixos/modules/services/hardware/trezord.xmlnew file+26
This diff is too big to show here.
nixos/modules/services/hardware/triggerhappy.nix+13−5
This diff is too big to show here.
nixos/modules/services/hardware/u2f.nixdeleted−23
This diff is too big to show here.
nixos/modules/services/hardware/udev.nix+147−24
This diff is too big to show here.
nixos/modules/services/hardware/udisks2.nix+42−4
This diff is too big to show here.
nixos/modules/services/hardware/undervolt.nix+101−45
This diff is too big to show here.
nixos/modules/services/hardware/upower.nix+186−51
This diff is too big to show here.
nixos/modules/services/hardware/usbmuxd.nix+8−6
This diff is too big to show here.
nixos/modules/services/hardware/usbrelayd.nixnew file+44
This diff is too big to show here.
nixos/modules/services/hardware/vdr.nixnew file+82
This diff is too big to show here.
nixos/modules/services/hardware/xow.nixnew file+20
This diff is too big to show here.
nixos/modules/services/home-automation/home-assistant.nixnew file+552
This diff is too big to show here.
nixos/modules/services/home-automation/zigbee2mqtt.nixnew file+142
This diff is too big to show here.
nixos/modules/services/logging/SystemdJournal2Gelf.nix+4−3
This diff is too big to show here.
nixos/modules/services/logging/awstats.nix+219−85
This diff is too big to show here.
nixos/modules/services/logging/filebeat.nixnew file+253
This diff is too big to show here.
nixos/modules/services/logging/fluentd.nix+1−1
This diff is too big to show here.
nixos/modules/services/logging/graylog.nix+16−16
This diff is too big to show here.
nixos/modules/services/logging/heartbeat.nix+4−2
This diff is too big to show here.
nixos/modules/services/logging/journalbeat.nix+35−17
This diff is too big to show here.
nixos/modules/services/logging/journalwatch.nix+31−12
This diff is too big to show here.
nixos/modules/services/logging/klogd.nix+6−34
This diff is too big to show here.
nixos/modules/services/logging/logcheck.nix+16−11
This diff is too big to show here.
nixos/modules/services/logging/logrotate.nix+374−17
This diff is too big to show here.
nixos/modules/services/logging/logstash.nix+36−19
This diff is too big to show here.
nixos/modules/services/logging/promtail.nixnew file+91
This diff is too big to show here.
nixos/modules/services/logging/rsyslogd.nix+2−2
This diff is too big to show here.
nixos/modules/services/logging/syslog-ng.nix+6−2
This diff is too big to show here.
nixos/modules/services/logging/vector.nixnew file+64
This diff is too big to show here.
nixos/modules/services/mail/davmail.nixnew file+99
This diff is too big to show here.
nixos/modules/services/mail/dovecot.nix+216−155
This diff is too big to show here.
nixos/modules/services/mail/dspam.nix+11−16
This diff is too big to show here.
nixos/modules/services/mail/exim.nix+22−12
This diff is too big to show here.
nixos/modules/services/mail/freepops.nixdeleted−89
This diff is too big to show here.
nixos/modules/services/mail/maddy.nixnew file+273
This diff is too big to show here.
nixos/modules/services/mail/mail.nix+2−1
This diff is too big to show here.
nixos/modules/services/mail/mailcatcher.nixnew file+68
This diff is too big to show here.
nixos/modules/services/mail/mailhog.nix+53−14
This diff is too big to show here.
nixos/modules/services/mail/mailman.nixnew file+469
This diff is too big to show here.
nixos/modules/services/mail/mailman.xmlnew file+94
This diff is too big to show here.
nixos/modules/services/mail/mlmmj.nix+34−19
This diff is too big to show here.
nixos/modules/services/mail/nullmailer.nix+10−10
This diff is too big to show here.
nixos/modules/services/mail/offlineimap.nix+3−3
This diff is too big to show here.
nixos/modules/services/mail/opendkim.nix+45−10
This diff is too big to show here.
nixos/modules/services/mail/opensmtpd.nix+26−22
This diff is too big to show here.
nixos/modules/services/mail/pfix-srsd.nix+4−4
This diff is too big to show here.
nixos/modules/services/mail/postfix.nix+175−61
This diff is too big to show here.
nixos/modules/services/mail/postfixadmin.nixnew file+199
This diff is too big to show here.
nixos/modules/services/mail/postgrey.nix+22−11
This diff is too big to show here.
nixos/modules/services/mail/postsrsd.nix+7−7
This diff is too big to show here.
nixos/modules/services/mail/rmilter.nixdeleted−252
This diff is too big to show here.
nixos/modules/services/mail/roundcube.nixnew file+249
This diff is too big to show here.
nixos/modules/services/mail/rspamd.nix+56−29
This diff is too big to show here.
nixos/modules/services/mail/rss2email.nix+9−10
This diff is too big to show here.
nixos/modules/services/mail/spamassassin.nix+45−53
This diff is too big to show here.
nixos/modules/services/mail/sympa.nixnew file+590
This diff is too big to show here.
nixos/modules/services/misc/matrix-synapse-log_config.yaml → nixos/modules/services/matrix/matrix-synapse-log_config.yamlrenamed
The content is the same.
nixos/modules/services/matrix/matrix-synapse.nixnew file+773
This diff is too big to show here.
nixos/modules/services/matrix/matrix-synapse.xmlnew file+231
This diff is too big to show here.
nixos/modules/services/matrix/mjolnir.nixnew file+242
This diff is too big to show here.
nixos/modules/services/matrix/mjolnir.xmlnew file+134
This diff is too big to show here.
nixos/modules/services/matrix/pantalaimon-options.nixnew file+70
This diff is too big to show here.
nixos/modules/services/matrix/pantalaimon.nixnew file+70
This diff is too big to show here.
nixos/modules/services/misc/airsonic.nix+53−10
This diff is too big to show here.
nixos/modules/services/misc/ananicy.nixnew file+107
This diff is too big to show here.
nixos/modules/services/misc/ankisyncd.nixnew file+79
This diff is too big to show here.
nixos/modules/services/misc/apache-kafka.nix+22−31
This diff is too big to show here.
nixos/modules/services/misc/autofs.nix+4−1
This diff is too big to show here.
nixos/modules/services/misc/autorandr.nix+311−4
This diff is too big to show here.
nixos/modules/services/misc/bazarr.nixnew file+77
This diff is too big to show here.
nixos/modules/services/misc/beanstalkd.nixnew file+63
This diff is too big to show here.
nixos/modules/services/misc/bees.nixnew file+132
This diff is too big to show here.
nixos/modules/services/misc/bepasty.nix+11−15
This diff is too big to show here.
nixos/modules/services/misc/calibre-server.nix+36−13
This diff is too big to show here.
nixos/modules/services/misc/cfdyndns.nix+18−6
This diff is too big to show here.
nixos/modules/services/misc/cgminer.nix+17−14
This diff is too big to show here.
nixos/modules/services/misc/clipcat.nixnew file+31
This diff is too big to show here.
nixos/modules/services/misc/clipmenu.nix+1−1
This diff is too big to show here.
nixos/modules/services/misc/confd.nix+2−2
This diff is too big to show here.
nixos/modules/services/misc/couchpotato.nixdeleted−50
This diff is too big to show here.
nixos/modules/services/misc/cpuminer-cryptonight.nix+4−4
This diff is too big to show here.
nixos/modules/services/misc/defaultUnicornConfig.rbdeleted−69
This diff is too big to show here.
nixos/modules/services/misc/dendrite.nixnew file+273
This diff is too big to show here.
nixos/modules/services/misc/devmon.nix+1−6
This diff is too big to show here.
nixos/modules/services/misc/dictd.nix+6−10
This diff is too big to show here.
nixos/modules/services/misc/disnix.nix+15−14
This diff is too big to show here.
nixos/modules/services/misc/docker-registry.nix+22−11
This diff is too big to show here.
nixos/modules/services/misc/domoticz.nixnew file+51
This diff is too big to show here.
nixos/modules/services/misc/duckling.nixnew file+39
This diff is too big to show here.
nixos/modules/services/misc/dwm-status.nixnew file+73
This diff is too big to show here.
nixos/modules/services/misc/dysnomia.nix+77−28
This diff is too big to show here.
nixos/modules/services/misc/emby.nixdeleted−76
This diff is too big to show here.
nixos/modules/services/misc/errbot.nix+5−2
This diff is too big to show here.
nixos/modules/services/misc/etcd.nix+20−13
This diff is too big to show here.
nixos/modules/services/misc/etebase-server.nixnew file+226
This diff is too big to show here.
nixos/modules/services/misc/etesync-dav.nixnew file+92
This diff is too big to show here.
nixos/modules/services/misc/ethminer.nixnew file+117
This diff is too big to show here.
nixos/modules/services/misc/exhibitor.nix+8−6
This diff is too big to show here.
nixos/modules/services/misc/felix.nix+7−12
This diff is too big to show here.
nixos/modules/services/misc/folding-at-home.nixdeleted−68
This diff is too big to show here.
nixos/modules/services/misc/freeswitch.nixnew file+104
This diff is too big to show here.
nixos/modules/services/misc/fstrim.nix+3−3
This diff is too big to show here.
nixos/modules/services/misc/gammu-smsd.nix+3−3
This diff is too big to show here.
nixos/modules/services/misc/geoip-updater.nixdeleted−306
This diff is too big to show here.
nixos/modules/services/misc/geoipupdate.nixnew file+187
This diff is too big to show here.
nixos/modules/services/misc/gitea.nix+373−112
This diff is too big to show here.
nixos/modules/services/misc/gitit.nix+28−27
This diff is too big to show here.
nixos/modules/services/misc/gitlab.nix+1016−208
This diff is too big to show here.
nixos/modules/services/misc/gitlab.xml+60−59
This diff is too big to show here.
nixos/modules/services/misc/gitolite.nix+33−19
This diff is too big to show here.
nixos/modules/services/misc/gitweb.nix+2−1
This diff is too big to show here.
nixos/modules/services/misc/gogs.nix+7−12
This diff is too big to show here.
nixos/modules/services/misc/gollum.nix+18−10
This diff is too big to show here.
nixos/modules/services/misc/gpsd.nix+5−8
This diff is too big to show here.
nixos/modules/services/misc/greenclip.nixnew file+31
This diff is too big to show here.
nixos/modules/services/misc/headphones.nixnew file+89
This diff is too big to show here.
nixos/modules/services/misc/heisenbridge.nixnew file+222
This diff is too big to show here.
nixos/modules/services/misc/home-assistant.nixdeleted−185
This diff is too big to show here.
nixos/modules/services/misc/ihaskell.nix+6−3
This diff is too big to show here.
nixos/modules/services/misc/input-remapper.nixnew file+30
This diff is too big to show here.
nixos/modules/services/misc/jackett.nix+52−17
This diff is too big to show here.
nixos/modules/services/misc/jellyfin.nixnew file+122
This diff is too big to show here.
nixos/modules/services/misc/klipper.nixnew file+117
This diff is too big to show here.
nixos/modules/services/misc/leaps.nix+2−2
This diff is too big to show here.
nixos/modules/services/misc/libreddit.nixnew file+66
This diff is too big to show here.
nixos/modules/services/misc/lidarr.nix+59−16
This diff is too big to show here.
nixos/modules/services/misc/lifecycled.nixnew file+164
This diff is too big to show here.
nixos/modules/services/misc/logkeys.nix+1−1
This diff is too big to show here.
nixos/modules/services/misc/mame.nixnew file+69
This diff is too big to show here.
nixos/modules/services/misc/mantisbt.nixdeleted−68
This diff is too big to show here.
nixos/modules/services/misc/mathics.nixdeleted−54
This diff is too big to show here.
nixos/modules/services/misc/matrix-appservice-discord.nixnew file+161
This diff is too big to show here.
nixos/modules/services/misc/matrix-appservice-irc.nixnew file+232
This diff is too big to show here.
nixos/modules/services/misc/matrix-conduit.nixnew file+149
This diff is too big to show here.
nixos/modules/services/misc/matrix-synapse.nixdeleted−698
This diff is too big to show here.
nixos/modules/services/misc/mautrix-facebook.nixnew file+195
This diff is too big to show here.
nixos/modules/services/misc/mautrix-telegram.nixnew file+181
This diff is too big to show here.
nixos/modules/services/misc/mbpfan.nix+60−62
This diff is too big to show here.
nixos/modules/services/misc/mediatomb.nix+187−81
This diff is too big to show here.
nixos/modules/services/misc/mesos-master.nixdeleted−126
This diff is too big to show here.
nixos/modules/services/misc/mesos-slave.nixdeleted−221
This diff is too big to show here.
nixos/modules/services/misc/metabase.nixnew file+103
This diff is too big to show here.
nixos/modules/services/misc/moonraker.nixnew file+178
This diff is too big to show here.
nixos/modules/services/misc/mwlib.nixdeleted−259
This diff is too big to show here.
nixos/modules/services/misc/mx-puppet-discord.nixnew file+122
This diff is too big to show here.
nixos/modules/services/misc/n8n.nixnew file+79
This diff is too big to show here.
nixos/modules/services/misc/nitter.nixnew file+358
This diff is too big to show here.
nixos/modules/services/misc/nix-daemon.nix+657−314
This diff is too big to show here.
nixos/modules/services/misc/nix-gc.nix+52−7
This diff is too big to show here.
nixos/modules/services/misc/nix-optimise.nix+10−4
This diff is too big to show here.
nixos/modules/services/misc/nix-ssh-serve.nix+10−2
This diff is too big to show here.
nixos/modules/services/misc/nixos-manual.nixdeleted−73
This diff is too big to show here.
nixos/modules/services/misc/nscd-sssd.confdeleted−36
This diff is too big to show here.
nixos/modules/services/misc/nzbget.nix+60−45
This diff is too big to show here.
nixos/modules/services/misc/nzbhydra2.nixnew file+78
This diff is too big to show here.
nixos/modules/services/misc/octoprint.nix+24−20
This diff is too big to show here.
nixos/modules/services/misc/ombi.nixnew file+81
This diff is too big to show here.
nixos/modules/services/misc/osrm.nix+1
This diff is too big to show here.
nixos/modules/services/misc/owncast.nixnew file+98
This diff is too big to show here.
nixos/modules/services/misc/packagekit.nix+54−38
This diff is too big to show here.
nixos/modules/services/misc/paperless.nixnew file+320
This diff is too big to show here.
nixos/modules/services/misc/parsoid.nix+27−2
This diff is too big to show here.
nixos/modules/services/misc/phd.nixdeleted−52
This diff is too big to show here.
nixos/modules/services/misc/pinnwand.nixnew file+103
This diff is too big to show here.
nixos/modules/services/misc/plex.nix+83−75
This diff is too big to show here.
nixos/modules/services/misc/plexpy.nixdeleted−81
This diff is too big to show here.
nixos/modules/services/misc/plikd.nixnew file+82
This diff is too big to show here.
nixos/modules/services/misc/podgrab.nixnew file+50
This diff is too big to show here.
nixos/modules/services/misc/prowlarr.nixnew file+41
This diff is too big to show here.
nixos/modules/services/misc/pykms.nix+50−48
This diff is too big to show here.
nixos/modules/services/misc/radarr.nix+45−17
This diff is too big to show here.
nixos/modules/services/misc/redmine.nix+163−120
This diff is too big to show here.
nixos/modules/services/misc/ripple-data-api.nix+5−4
This diff is too big to show here.
nixos/modules/services/misc/rippled.nix+183−177
This diff is too big to show here.
nixos/modules/services/misc/rmfakecloud.nixnew file+147
This diff is too big to show here.
nixos/modules/services/misc/rogue.nixdeleted−62
This diff is too big to show here.
nixos/modules/services/misc/safeeyes.nix+7−6
This diff is too big to show here.
nixos/modules/services/misc/sdrplay.nixnew file+35
This diff is too big to show here.
nixos/modules/services/misc/serviio.nix+10−15
This diff is too big to show here.
nixos/modules/services/misc/sickbeard.nix+18−15
This diff is too big to show here.
nixos/modules/services/misc/signald.nixnew file+105
This diff is too big to show here.
nixos/modules/services/misc/siproxd.nix+14−15
This diff is too big to show here.
nixos/modules/services/misc/snapper.nix+51−16
This diff is too big to show here.
nixos/modules/services/misc/sonarr.nix+46−17
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/builds.nixnew file+236
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/default.nixnew file+1386
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/dispatch.nixnew file+127
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/git.nixnew file+217
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/hg.nixnew file+175
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/hub.nixnew file+120
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/lists.nixnew file+187
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/man.nixnew file+124
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/meta.nixnew file+213
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/paste.nixnew file+135
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/service.nixnew file+375
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/sourcehut.xmlnew file+119
This diff is too big to show here.
nixos/modules/services/misc/sourcehut/todo.nixnew file+163
This diff is too big to show here.
nixos/modules/services/misc/spice-vdagentd.nix+1−1
This diff is too big to show here.
nixos/modules/services/misc/ssm-agent.nix+34−7
This diff is too big to show here.
nixos/modules/services/misc/sssd.nix+12−12
This diff is too big to show here.
nixos/modules/services/misc/subsonic.nix+12−8
This diff is too big to show here.
nixos/modules/services/misc/svnserve.nix+4−2
This diff is too big to show here.
nixos/modules/services/misc/synergy.nix+32−15
This diff is too big to show here.
nixos/modules/services/misc/taskserver/default.nix+27−22
This diff is too big to show here.
nixos/modules/services/misc/taskserver/doc.xml+2−2
This diff is too big to show here.
nixos/modules/services/misc/taskserver/helper-tool.py+5−5
This diff is too big to show here.
nixos/modules/services/misc/tautulli.nixnew file+81
This diff is too big to show here.
nixos/modules/services/misc/tiddlywiki.nixnew file+52
This diff is too big to show here.
nixos/modules/services/misc/tp-auto-kbbl.nixnew file+58
This diff is too big to show here.
nixos/modules/services/misc/tzupdate.nix+2−2
This diff is too big to show here.
nixos/modules/services/misc/uhub.nix+86−160
This diff is too big to show here.
nixos/modules/services/misc/weechat.nix+10−5
This diff is too big to show here.
nixos/modules/services/misc/weechat.xml+2−2
This diff is too big to show here.
nixos/modules/services/misc/xmr-stak.nix+1−1
This diff is too big to show here.
nixos/modules/services/misc/xmrig.nixnew file+76
This diff is too big to show here.
nixos/modules/services/misc/zoneminder.nixnew file+370
This diff is too big to show here.
nixos/modules/services/misc/zookeeper.nix+21−10
This diff is too big to show here.
nixos/modules/services/monitoring/alerta.nix+7−12
This diff is too big to show here.
nixos/modules/services/monitoring/apcupsd.nix+4−4
This diff is too big to show here.
nixos/modules/services/monitoring/arbtt.nix+1−2
This diff is too big to show here.
nixos/modules/services/monitoring/bosun.nix+7−8
This diff is too big to show here.
nixos/modules/services/monitoring/cadvisor.nix+13−1
This diff is too big to show here.
nixos/modules/services/monitoring/collectd.nix+91−29
This diff is too big to show here.
nixos/modules/services/monitoring/datadog-agent.nix+53−28
This diff is too big to show here.
nixos/modules/services/monitoring/dd-agent/dd-agent.nix+37−40
This diff is too big to show here.
nixos/modules/services/monitoring/do-agent.nixnew file+25
This diff is too big to show here.
nixos/modules/services/monitoring/fusion-inventory.nix+3−3
This diff is too big to show here.
nixos/modules/services/monitoring/grafana-image-renderer.nixnew file+150
This diff is too big to show here.
nixos/modules/services/monitoring/grafana-reporter.nix+6−5
This diff is too big to show here.
nixos/modules/services/monitoring/grafana.nix+386−38
This diff is too big to show here.
nixos/modules/services/monitoring/graphite.nix+64−124
This diff is too big to show here.
nixos/modules/services/monitoring/hdaps.nix+1
This diff is too big to show here.
nixos/modules/services/monitoring/heapster.nix+8−7
This diff is too big to show here.
nixos/modules/services/monitoring/incron.nix+8−3
This diff is too big to show here.
nixos/modules/services/monitoring/kapacitor.nix+10−14
This diff is too big to show here.
nixos/modules/services/monitoring/loki.nixnew file+114
This diff is too big to show here.
nixos/modules/services/monitoring/mackerel-agent.nixnew file+110
This diff is too big to show here.
nixos/modules/services/monitoring/metricbeat.nixnew file+151
This diff is too big to show here.
nixos/modules/services/monitoring/mimir.nixnew file+63
This diff is too big to show here.
nixos/modules/services/monitoring/monit.nix+4−2
This diff is too big to show here.
nixos/modules/services/monitoring/munin.nix+207−22
This diff is too big to show here.
nixos/modules/services/monitoring/nagios.nix+104−81
This diff is too big to show here.
nixos/modules/services/monitoring/netdata.nix+195−32
This diff is too big to show here.
nixos/modules/services/monitoring/osquery.nix−91
This diff is too big to show here.
nixos/modules/services/monitoring/parsedmarc.md+113
This diff is too big to show here.
nixos/modules/services/monitoring/parsedmarc.nix+542
This diff is too big to show here.
nixos/modules/services/monitoring/parsedmarc.xml+125
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/alertmanager.nix+45−27
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/default.nix+1669−366
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters.nix+165−40
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters.xml+117−56
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/apcupsd.nix+38
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/artifactory.nix+59
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/bind.nix+54
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/bird.nix+50
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/bitcoin.nix+82
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/blackbox.nix+45−6
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/buildkite-agent.nix+64
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/collectd.nix+11−12
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/dmarc.nix+117
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/dnsmasq.nix+2−3
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/domain.nix+19
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/dovecot.nix+45−3
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/fastly.nix+41
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/flow.nix+50
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/fritzbox.nix+2−3
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/influxdb.nix+34
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/jitsi.nix+40
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/json.nix+19−12
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/kea.nix+47
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/keylight.nix+19
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/knot.nix+54
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/lnd.nix+46
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/mail.nix+176
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/mikrotik.nix+66
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/minio.nix+3−4
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/modemmanager.nix+37
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/nextcloud.nix+58
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/nginx.nix+33−12
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/nginxlog.nix+51
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/node.nix+15−6
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/openldap.nix+67
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/openvpn.nix+39
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/pihole.nix+74
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/postfix.nix+27−10
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/postgres.nix+88
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/process.nix+46
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/pve.nix+118
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/py-air-control.nix+53
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/redis.nix+19
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/rspamd.nix+97
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/rtl_433.nix+83
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/script.nix+64
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/smartctl.nix+75
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/smokeping.nix+61
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/snmp.nix+17−20
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/sql.nix+108
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/surfboard.nix+1−2
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/systemd.nix+22
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/tor.nix+6−2
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/unbound.nix+63
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/unifi-poller.nix+34
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/unifi.nix+3−4
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/varnish.nix+7−6
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/exporters/wireguard.nix+71
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/pushgateway.nix+166
This diff is too big to show here.
nixos/modules/services/monitoring/prometheus/xmpp-alerts.nix+55
This diff is too big to show here.
nixos/modules/services/monitoring/riemann-dash.nix+5−3
This diff is too big to show here.
nixos/modules/services/monitoring/riemann-tools.nix+10−3
This diff is too big to show here.
nixos/modules/services/monitoring/scollector.nix+8−10
This diff is too big to show here.
nixos/modules/services/monitoring/smartd.nix+19−8
This diff is too big to show here.
nixos/modules/services/monitoring/statsd.nix+1−2
This diff is too big to show here.
nixos/modules/services/monitoring/sysstat.nix+4−8
This diff is too big to show here.
nixos/modules/services/monitoring/systemhealth.nix−133
This diff is too big to show here.
nixos/modules/services/monitoring/teamviewer.nix+9−6
This diff is too big to show here.
nixos/modules/services/monitoring/telegraf.nix+43−24
This diff is too big to show here.
nixos/modules/services/monitoring/thanos.nix+838
This diff is too big to show here.
nixos/modules/services/monitoring/tuptime.nix+91
This diff is too big to show here.
nixos/modules/services/monitoring/unifi-poller.nix+318
This diff is too big to show here.
nixos/modules/services/monitoring/ups.nix+18−35
This diff is too big to show here.
nixos/modules/services/monitoring/uptime.nix+10−5
This diff is too big to show here.
nixos/modules/services/monitoring/vnstat.nix+32−15
This diff is too big to show here.
nixos/modules/services/monitoring/zabbix-agent.nix+126−61
This diff is too big to show here.
nixos/modules/services/monitoring/zabbix-proxy.nix+323
This diff is too big to show here.
nixos/modules/services/monitoring/zabbix-server.nix+282−88
This diff is too big to show here.
nixos/modules/services/network-filesystems/beegfs.nix−354
This diff is too big to show here.
nixos/modules/services/network-filesystems/cachefilesd.nix+11−7
This diff is too big to show here.
nixos/modules/services/network-filesystems/ceph.nix+113−78
This diff is too big to show here.
nixos/modules/services/network-filesystems/davfs2.nix+31−12
This diff is too big to show here.
nixos/modules/services/network-filesystems/diod.nix−1
This diff is too big to show here.
nixos/modules/services/network-filesystems/drbd.nix+7−11
This diff is too big to show here.
nixos/modules/services/network-filesystems/glusterfs.nix+2−6
This diff is too big to show here.
nixos/modules/services/network-filesystems/ipfs.nix+167−129
This diff is too big to show here.
nixos/modules/services/network-filesystems/kbfs.nix+71−18
This diff is too big to show here.
nixos/modules/services/network-filesystems/litestream/default.nix+100
This diff is too big to show here.
nixos/modules/services/network-filesystems/litestream/litestream.xml+65
This diff is too big to show here.
nixos/modules/services/network-filesystems/moosefs.nix+249
This diff is too big to show here.
nixos/modules/services/network-filesystems/netatalk.nix+45−98
This diff is too big to show here.
nixos/modules/services/network-filesystems/nfsd.nix+4
This diff is too big to show here.
nixos/modules/services/network-filesystems/openafs/client.nix+11−12
This diff is too big to show here.
nixos/modules/services/network-filesystems/openafs/lib.nix+1−1
This diff is too big to show here.
nixos/modules/services/network-filesystems/openafs/server.nix+4−4
This diff is too big to show here.
nixos/modules/services/network-filesystems/orangefs/client.nix+96
This diff is too big to show here.
nixos/modules/services/network-filesystems/orangefs/server.nix+225
This diff is too big to show here.
nixos/modules/services/network-filesystems/rsyncd.nix+95−91
This diff is too big to show here.
nixos/modules/services/network-filesystems/samba-wsdd.nix+124
This diff is too big to show here.
nixos/modules/services/network-filesystems/samba.nix+37−37
This diff is too big to show here.
nixos/modules/services/network-filesystems/tahoe.nix+10−9
This diff is too big to show here.
nixos/modules/services/network-filesystems/u9fs.nix+1
This diff is too big to show here.
nixos/modules/services/network-filesystems/webdav-server-rs.nix+144
This diff is too big to show here.
nixos/modules/services/network-filesystems/webdav.nix+107
This diff is too big to show here.
nixos/modules/services/network-filesystems/xtreemfs.nix+24−3
This diff is too big to show here.
nixos/modules/services/network-filesystems/yandex-disk.nix+6−3
This diff is too big to show here.
nixos/modules/services/networking/3proxy.nix+413
This diff is too big to show here.
nixos/modules/services/networking/adguardhome.nix+140
This diff is too big to show here.
nixos/modules/services/networking/amuled.nix+10−3
This diff is too big to show here.
nixos/modules/services/networking/antennas.nix+80
This diff is too big to show here.
nixos/modules/services/networking/aria2.nix+10−14
This diff is too big to show here.
nixos/modules/services/networking/asterisk.nix+15−47
This diff is too big to show here.
nixos/modules/services/networking/atftpd.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/autossh.nix+4−5
This diff is too big to show here.
nixos/modules/services/networking/avahi-daemon.nix+191−158
This diff is too big to show here.
nixos/modules/services/networking/babeld.nix+57−13
This diff is too big to show here.
nixos/modules/services/networking/bee-clef.nix+107
This diff is too big to show here.
nixos/modules/services/networking/bee.nix+149
This diff is too big to show here.
nixos/modules/services/networking/biboumi.nix+270
This diff is too big to show here.
nixos/modules/services/networking/bind.nix+107−36
This diff is too big to show here.
nixos/modules/services/networking/bird.nix+89−64
This diff is too big to show here.
nixos/modules/services/networking/bitcoind.nix+261
This diff is too big to show here.
nixos/modules/services/networking/bitlbee.nix+13−18
This diff is too big to show here.
nixos/modules/services/networking/blockbook-frontend.nix+278
This diff is too big to show here.
nixos/modules/services/networking/blocky.nix+40
This diff is too big to show here.
nixos/modules/services/networking/btsync.nix−324
This diff is too big to show here.
nixos/modules/services/networking/charybdis.nix+19−15
This diff is too big to show here.
nixos/modules/services/networking/chrony.nix−128
This diff is too big to show here.
nixos/modules/services/networking/cjdns.nix+56−35
This diff is too big to show here.
nixos/modules/services/networking/cloudflare-dyndns.nix+93
This diff is too big to show here.
nixos/modules/services/networking/cntlm.nix+8−8
This diff is too big to show here.
nixos/modules/services/networking/connman.nix+56−22
This diff is too big to show here.
nixos/modules/services/networking/consul.nix+48−17
This diff is too big to show here.
nixos/modules/services/networking/coredns.nix+50
This diff is too big to show here.
nixos/modules/services/networking/corerad.nix+82
This diff is too big to show here.
nixos/modules/services/networking/coturn.nix+67−38
This diff is too big to show here.
nixos/modules/services/networking/create_ap.nix+50
This diff is too big to show here.
nixos/modules/services/networking/croc.nix+86
This diff is too big to show here.
nixos/modules/services/networking/ddclient.nix+63−26
This diff is too big to show here.
nixos/modules/services/networking/dhcpcd.nix+61−13
This diff is too big to show here.
nixos/modules/services/networking/dhcpd.nix+63−50
This diff is too big to show here.
nixos/modules/services/networking/dnscache.nix+8−6
This diff is too big to show here.
nixos/modules/services/networking/dnschain.nix−177
This diff is too big to show here.
nixos/modules/services/networking/dnscrypt-proxy.nix−328
This diff is too big to show here.
nixos/modules/services/networking/dnscrypt-proxy.xml−66
This diff is too big to show here.
nixos/modules/services/networking/dnscrypt-proxy2.nix+124
This diff is too big to show here.
nixos/modules/services/networking/dnscrypt-wrapper.nix+96−9
This diff is too big to show here.
nixos/modules/services/networking/dnsdist.nix+11−19
This diff is too big to show here.
nixos/modules/services/networking/dnsmasq.nix+14−4
This diff is too big to show here.
nixos/modules/services/networking/doh-proxy-rust.nix+60
This diff is too big to show here.
nixos/modules/services/networking/ejabberd.nix+20−26
This diff is too big to show here.
nixos/modules/services/networking/envoy.nix+84
This diff is too big to show here.
nixos/modules/services/networking/epmd.nix+19−3
This diff is too big to show here.
nixos/modules/services/networking/ergo.nix+143
This diff is too big to show here.
nixos/modules/services/networking/ergochat.nix+155
This diff is too big to show here.
nixos/modules/services/networking/eternal-terminal.nix+7−1
This diff is too big to show here.
nixos/modules/services/networking/fakeroute.nix+2
This diff is too big to show here.
nixos/modules/services/networking/ferm.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/firefox/sync-server.nix−179
This diff is too big to show here.
nixos/modules/services/networking/firewall.nix+39−29
This diff is too big to show here.
nixos/modules/services/networking/flannel.nix+51−13
This diff is too big to show here.
nixos/modules/services/networking/flashpolicyd.nix−84
This diff is too big to show here.
nixos/modules/services/networking/freeradius.nix+17−3
This diff is too big to show here.
nixos/modules/services/networking/frr.nix+211
This diff is too big to show here.
nixos/modules/services/networking/gale.nix−182
This diff is too big to show here.
nixos/modules/services/networking/gateone.nix+3−3
This diff is too big to show here.
nixos/modules/services/networking/ghostunnel.nix+242
This diff is too big to show here.
nixos/modules/services/networking/git-daemon.nix+9−8
This diff is too big to show here.
nixos/modules/services/networking/globalprotect-vpn.nix+43
This diff is too big to show here.
nixos/modules/services/networking/gnunet.nix+23−11
This diff is too big to show here.
nixos/modules/services/networking/go-neb.nix+79
This diff is too big to show here.
nixos/modules/services/networking/go-shadowsocks2.nix+30
This diff is too big to show here.
nixos/modules/services/networking/gobgpd.nix+64
This diff is too big to show here.
nixos/modules/services/networking/gogoclient.nix−84
This diff is too big to show here.
nixos/modules/services/networking/gvpe.nix+10−8
This diff is too big to show here.
nixos/modules/services/networking/hans.nix+4−4
This diff is too big to show here.
nixos/modules/services/networking/haproxy.nix+64−14
This diff is too big to show here.
nixos/modules/services/networking/headscale.nix+490
This diff is too big to show here.
nixos/modules/services/networking/helpers.nix+11
This diff is too big to show here.
nixos/modules/services/networking/heyefi.nix−82
This diff is too big to show here.
nixos/modules/services/networking/hostapd.nix+61−12
This diff is too big to show here.
nixos/modules/services/networking/htpdate.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/https-dns-proxy.nix+128
This diff is too big to show here.
nixos/modules/services/networking/hylafax/default.nix+2
This diff is too big to show here.
nixos/modules/services/networking/hylafax/faxq-default.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/hylafax/faxq-wait.sh+1−1
This diff is too big to show here.
nixos/modules/services/networking/hylafax/modem-default.nix+3−3
This diff is too big to show here.
nixos/modules/services/networking/hylafax/options.nix+26−29
This diff is too big to show here.
nixos/modules/services/networking/hylafax/spool.sh+3−3
This diff is too big to show here.
nixos/modules/services/networking/hylafax/systemd.nix+31−31
This diff is too big to show here.
nixos/modules/services/networking/i2pd.nix+31−20
This diff is too big to show here.
nixos/modules/services/networking/icecream/daemon.nix+155
This diff is too big to show here.
nixos/modules/services/networking/icecream/scheduler.nix+101
This diff is too big to show here.
nixos/modules/services/networking/inspircd.nix+62
This diff is too big to show here.
nixos/modules/services/networking/iodine.nix+113−65
This diff is too big to show here.
nixos/modules/services/networking/iperf3.nix+10
This diff is too big to show here.
nixos/modules/services/networking/ircd-hybrid/default.nix+15−13
This diff is too big to show here.
nixos/modules/services/networking/ircd-hybrid/ircd.conf+1−1
This diff is too big to show here.
nixos/modules/services/networking/iscsi/initiator.nix+84
This diff is too big to show here.
nixos/modules/services/networking/iscsi/root-initiator.nix+190
This diff is too big to show here.
nixos/modules/services/networking/iscsi/target.nix+53
This diff is too big to show here.
nixos/modules/services/networking/iwd.nix+48−10
This diff is too big to show here.
nixos/modules/services/networking/jibri/default.nix+417
This diff is too big to show here.
nixos/modules/services/networking/jibri/logging.properties-journal+32
This diff is too big to show here.
nixos/modules/services/networking/jicofo.nix+152
This diff is too big to show here.
nixos/modules/services/networking/jitsi-videobridge.nix+288
This diff is too big to show here.
nixos/modules/services/networking/kea.nix+449
This diff is too big to show here.
nixos/modules/services/networking/keepalived/vrrp-instance-options.nix+1−3
This diff is too big to show here.
nixos/modules/services/networking/keepalived/vrrp-script-options.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/keybase.nix+9−3
This diff is too big to show here.
nixos/modules/services/networking/kippo.nix−118
This diff is too big to show here.
nixos/modules/services/networking/knot.nix+152
This diff is too big to show here.
nixos/modules/services/networking/kresd.nix+97−79
This diff is too big to show here.
nixos/modules/services/networking/lambdabot.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/libreswan.nix+89−58
This diff is too big to show here.
nixos/modules/services/networking/lldpd.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/logmein-hamachi.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/lxd-image-server.nix+133
This diff is too big to show here.
nixos/modules/services/networking/magic-wormhole-mailbox-server.nix+28
This diff is too big to show here.
nixos/modules/services/networking/mailpile.nix−76
This diff is too big to show here.
nixos/modules/services/networking/matterbridge.nix+11−9
This diff is too big to show here.
nixos/modules/services/networking/minidlna.nix+84−10
This diff is too big to show here.
nixos/modules/services/networking/miniupnpd.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/miredo.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/mjpg-streamer.nix+5−4
This diff is too big to show here.
nixos/modules/services/networking/monero.nix+26−20
This diff is too big to show here.
nixos/modules/services/networking/morty.nix+16−14
This diff is too big to show here.
nixos/modules/services/networking/mosquitto.md+102
This diff is too big to show here.
nixos/modules/services/networking/mosquitto.nix+586−145
This diff is too big to show here.
nixos/modules/services/networking/mosquitto.xml+147
This diff is too big to show here.
nixos/modules/services/networking/mozillavpn.nix+19
This diff is too big to show here.
nixos/modules/services/networking/mstpd.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/mtprotoproxy.nix+110
This diff is too big to show here.
nixos/modules/services/networking/mtr-exporter.nix+87
This diff is too big to show here.
nixos/modules/services/networking/mullvad-vpn.nix+50
This diff is too big to show here.
nixos/modules/services/networking/multipath.nix+557
This diff is too big to show here.
nixos/modules/services/networking/murmur.nix+69−20
This diff is too big to show here.
nixos/modules/services/networking/mxisd.nix+30−28
This diff is too big to show here.
nixos/modules/services/networking/namecoind.nix+11−15
This diff is too big to show here.
nixos/modules/services/networking/nar-serve.nix+55
This diff is too big to show here.
nixos/modules/services/networking/nat.nix+114−32
This diff is too big to show here.
nixos/modules/services/networking/nats.nix+158
This diff is too big to show here.
nixos/modules/services/networking/nbd.nix+159
This diff is too big to show here.
nixos/modules/services/networking/ncdns.nix+283
This diff is too big to show here.
nixos/modules/services/networking/ndppd.nix+167−25
This diff is too big to show here.
nixos/modules/services/networking/nebula.nix+217
This diff is too big to show here.
nixos/modules/services/networking/networkmanager.nix+325−274
This diff is too big to show here.
nixos/modules/services/networking/nextdns.nix+44
This diff is too big to show here.
nixos/modules/services/networking/nftables.nix+9−14
This diff is too big to show here.
nixos/modules/services/networking/nghttpx/default.nix+4−3
This diff is too big to show here.
nixos/modules/services/networking/ngircd.nix+5−2
This diff is too big to show here.
nixos/modules/services/networking/nix-serve.nix+29−10
This diff is too big to show here.
nixos/modules/services/networking/nix-store-gcs-proxy.nix+75
This diff is too big to show here.
nixos/modules/services/networking/nixops-dns.nix−1
This diff is too big to show here.
nixos/modules/services/networking/nntp-proxy.nix+18−19
This diff is too big to show here.
nixos/modules/services/networking/nomad.nix+178
This diff is too big to show here.
nixos/modules/services/networking/nsd.nix+50−45
This diff is too big to show here.
nixos/modules/services/networking/ntopng.nix+57−13
This diff is too big to show here.
nixos/modules/services/networking/ntp/chrony.nix+178
This diff is too big to show here.
nixos/modules/services/networking/ntp/ntpd.nix+24−8
This diff is too big to show here.
nixos/modules/services/networking/ntp/openntpd.nix+7−4
This diff is too big to show here.
nixos/modules/services/networking/nullidentdmod.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/nylon.nix+6−7
This diff is too big to show here.
nixos/modules/services/networking/ocserv.nix+4−4
This diff is too big to show here.
nixos/modules/services/networking/ofono.nix+44
This diff is too big to show here.
nixos/modules/services/networking/onedrive.nix+71
This diff is too big to show here.
nixos/modules/services/networking/onedrive.xml+34
This diff is too big to show here.
nixos/modules/services/networking/openconnect.nix+137
This diff is too big to show here.
nixos/modules/services/networking/openfire.nix−60
This diff is too big to show here.
nixos/modules/services/networking/openvpn.nix+9−6
This diff is too big to show here.
nixos/modules/services/networking/ostinato.nix+4−4
This diff is too big to show here.
nixos/modules/services/networking/owamp.nix+4−6
This diff is too big to show here.
nixos/modules/services/networking/pdns-recursor.nix+98−55
This diff is too big to show here.
nixos/modules/services/networking/pdnsd.nix+2−4
This diff is too big to show here.
nixos/modules/services/networking/pixiecore.nix+135
This diff is too big to show here.
nixos/modules/services/networking/pleroma.nix+149
This diff is too big to show here.
nixos/modules/services/networking/pleroma.xml+188
This diff is too big to show here.
nixos/modules/services/networking/polipo.nix+9−11
This diff is too big to show here.
nixos/modules/services/networking/powerdns.nix+19−21
This diff is too big to show here.
nixos/modules/services/networking/pppd.nix+154
This diff is too big to show here.
nixos/modules/services/networking/pptpd.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/prayer.nix+8−15
This diff is too big to show here.
nixos/modules/services/networking/privoxy.nix+232−65
This diff is too big to show here.
nixos/modules/services/networking/prosody.nix+389−26
This diff is too big to show here.
nixos/modules/services/networking/prosody.xml+87
This diff is too big to show here.
nixos/modules/services/networking/quagga.nix−185
This diff is too big to show here.
nixos/modules/services/networking/quassel.nix+49−19
This diff is too big to show here.
nixos/modules/services/networking/quicktun.nix+118
This diff is too big to show here.
nixos/modules/services/networking/quorum.nix+231
This diff is too big to show here.
nixos/modules/services/networking/racoon.nix−45
This diff is too big to show here.
nixos/modules/services/networking/radicale.nix+158−46
This diff is too big to show here.
nixos/modules/services/networking/radvd.nix+6−1
This diff is too big to show here.
nixos/modules/services/networking/rdnssd.nix+9−1
This diff is too big to show here.
nixos/modules/services/networking/resilio.nix+14−12
This diff is too big to show here.
nixos/modules/services/networking/robustirc-bridge.nix+47
This diff is too big to show here.
nixos/modules/services/networking/rxe.nix+9−20
This diff is too big to show here.
nixos/modules/services/networking/sabnzbd.nix+12−4
This diff is too big to show here.
nixos/modules/services/networking/seafile.nix+287
This diff is too big to show here.
nixos/modules/services/networking/searx.nix+184−31
This diff is too big to show here.
nixos/modules/services/networking/seeks.nix−75
This diff is too big to show here.
nixos/modules/services/networking/shadowsocks.nix+52−6
This diff is too big to show here.
nixos/modules/services/networking/shairport-sync.nix+32−3
This diff is too big to show here.
nixos/modules/services/networking/shellhub-agent.nix+100
This diff is too big to show here.
nixos/modules/services/networking/shorewall.nix+70
This diff is too big to show here.
nixos/modules/services/networking/shorewall6.nix+70
This diff is too big to show here.
nixos/modules/services/networking/shout.nix+7−6
This diff is too big to show here.
nixos/modules/services/networking/skydns.nix+4−3
This diff is too big to show here.
nixos/modules/services/networking/smartdns.nix+62
This diff is too big to show here.
nixos/modules/services/networking/smokeping.nix+106−61
This diff is too big to show here.
nixos/modules/services/networking/sniproxy.nix+6−17
This diff is too big to show here.
nixos/modules/services/networking/snowflake-proxy.nix+81
This diff is too big to show here.
nixos/modules/services/networking/softether.nix+3−3
This diff is too big to show here.
nixos/modules/services/networking/soju.nix+114
This diff is too big to show here.
nixos/modules/services/networking/solanum.nix+109
This diff is too big to show here.
nixos/modules/services/networking/spacecookie.nix+216
This diff is too big to show here.
nixos/modules/services/networking/spiped.nix+1−1
This diff is too big to show here.
nixos/modules/services/networking/squid.nix+24−6
This diff is too big to show here.
nixos/modules/services/networking/ssh/lshd.nix+19−6
This diff is too big to show here.
nixos/modules/services/networking/ssh/sshd.nix+117−34
This diff is too big to show here.
nixos/modules/services/networking/sslh.nix+17−14
This diff is too big to show here.
nixos/modules/services/networking/strongswan-swanctl/module.nix+9−7
This diff is too big to show here.
nixos/modules/services/networking/strongswan-swanctl/param-constructors.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/strongswan-swanctl/param-lib.nix+6−6
This diff is too big to show here.
nixos/modules/services/networking/strongswan-swanctl/swanctl-params.nix+68−12
This diff is too big to show here.
nixos/modules/services/networking/strongswan.nix+19−18
This diff is too big to show here.
nixos/modules/services/networking/stubby.nix+48−173
This diff is too big to show here.
nixos/modules/services/networking/stunnel.nix+28−11
This diff is too big to show here.
nixos/modules/services/networking/supplicant.nix+20−31
This diff is too big to show here.
nixos/modules/services/networking/supybot.nix+97−22
This diff is too big to show here.
nixos/modules/services/networking/syncplay.nix+96
This diff is too big to show here.
nixos/modules/services/networking/syncthing.nix+475−43
This diff is too big to show here.
nixos/modules/services/networking/tailscale.nix+52
This diff is too big to show here.
nixos/modules/services/networking/tcpcrypt.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/teamspeak3.nix+37−15
This diff is too big to show here.
nixos/modules/services/networking/tedicross.nix+100
This diff is too big to show here.
nixos/modules/services/networking/teleport.nix+99
This diff is too big to show here.
nixos/modules/services/networking/tetrd.nix+96
This diff is too big to show here.
nixos/modules/services/networking/thelounge.nix+106
This diff is too big to show here.
nixos/modules/services/networking/tinc.nix+246−20
This diff is too big to show here.
nixos/modules/services/networking/tinydns.nix+6−1
This diff is too big to show here.
nixos/modules/services/networking/tox-bootstrapd.nix+8−14
This diff is too big to show here.
nixos/modules/services/networking/tox-node.nix+90
This diff is too big to show here.
nixos/modules/services/networking/toxvpn.nix+8−6
This diff is too big to show here.
nixos/modules/services/networking/trickster.nix+113
This diff is too big to show here.
nixos/modules/services/networking/tvheadend.nix+3−1
This diff is too big to show here.
nixos/modules/services/networking/ucarp.nix+183
This diff is too big to show here.
nixos/modules/services/networking/unbound.nix+247−72
This diff is too big to show here.
nixos/modules/services/networking/unifi.nix+85−70
This diff is too big to show here.
nixos/modules/services/networking/v2ray.nix+95
This diff is too big to show here.
nixos/modules/services/networking/vsftpd.nix+124−30
This diff is too big to show here.
nixos/modules/services/networking/wakeonlan.nix−56
This diff is too big to show here.
nixos/modules/services/networking/wasabibackend.nix+160
This diff is too big to show here.
nixos/modules/services/networking/websockify.nix+6−6
This diff is too big to show here.
nixos/modules/services/networking/wg-netmanager.nix+42
This diff is too big to show here.
nixos/modules/services/networking/wg-quick.nix+311
This diff is too big to show here.
nixos/modules/services/networking/wicd.nix−39
This diff is too big to show here.
nixos/modules/services/networking/wireguard.nix+267−53
This diff is too big to show here.
nixos/modules/services/networking/wpa_supplicant.nix+383−78
This diff is too big to show here.
nixos/modules/services/networking/x2goserver.nix+164
This diff is too big to show here.
nixos/modules/services/networking/xandikos.nix+148
This diff is too big to show here.
nixos/modules/services/networking/xinetd.nix+9−14
This diff is too big to show here.
nixos/modules/services/networking/xl2tpd.nix+2−2
This diff is too big to show here.
nixos/modules/services/networking/xrdp.nix+28−8
This diff is too big to show here.
nixos/modules/services/networking/yggdrasil.nix+201
This diff is too big to show here.
nixos/modules/services/networking/yggdrasil.xml+156
This diff is too big to show here.
nixos/modules/services/networking/zerobin.nix+3−3
This diff is too big to show here.
nixos/modules/services/networking/zeronet.nix+42−62
This diff is too big to show here.
nixos/modules/services/networking/zerotierone.nix+19−5
This diff is too big to show here.
nixos/modules/services/networking/znc/default.nix+56−27
This diff is too big to show here.
nixos/modules/services/networking/znc/options.nix+6−6
This diff is too big to show here.
nixos/modules/services/printing/cupsd.nix+62−21
This diff is too big to show here.
nixos/modules/services/scheduling/atd.nix+7−16
This diff is too big to show here.
nixos/modules/services/scheduling/chronos.nix−54
This diff is too big to show here.
nixos/modules/services/scheduling/cron.nix+9−4
This diff is too big to show here.
nixos/modules/services/scheduling/fcron.nix+8−5
This diff is too big to show here.
nixos/modules/services/scheduling/marathon.nix−98
This diff is too big to show here.
nixos/modules/services/search/elasticsearch-curator.nix+4−2
This diff is too big to show here.
nixos/modules/services/search/elasticsearch.nix+43−11
This diff is too big to show here.
nixos/modules/services/search/hound.nix+24−22
This diff is too big to show here.
nixos/modules/services/search/kibana.nix+58−13
This diff is too big to show here.
nixos/modules/services/search/meilisearch.md+39
This diff is too big to show here.
nixos/modules/services/search/meilisearch.nix+132
This diff is too big to show here.
nixos/modules/services/search/meilisearch.xml+85
This diff is too big to show here.
nixos/modules/services/search/solr.nix+9−9
This diff is too big to show here.
nixos/modules/services/security/aesmd.nix+236
This diff is too big to show here.
nixos/modules/services/security/certmgr.nix+12−5
This diff is too big to show here.
nixos/modules/services/security/cfssl.nix+56−43
This diff is too big to show here.
nixos/modules/services/security/clamav.nix+42−37
This diff is too big to show here.
nixos/modules/services/security/fail2ban.nix+267−79
This diff is too big to show here.
nixos/modules/services/security/fprintd.nix+29−18
This diff is too big to show here.
nixos/modules/services/security/fprot.nix−88
This diff is too big to show here.
nixos/modules/services/security/haka.nix+3−3
This diff is too big to show here.
nixos/modules/services/security/haveged.nix+45−35
This diff is too big to show here.
nixos/modules/services/security/hockeypuck.nix+106
This diff is too big to show here.
nixos/modules/services/security/hologram-agent.nix+4−4
This diff is too big to show here.
nixos/modules/services/security/hologram-server.nix+1−1
This diff is too big to show here.
nixos/modules/services/security/munge.nix+5−10
This diff is too big to show here.
nixos/modules/services/security/nginx-sso.nix+67
This diff is too big to show here.
nixos/modules/services/security/oauth2_proxy.nix+48−20
This diff is too big to show here.
nixos/modules/services/security/oauth2_proxy_nginx.nix+7−5
This diff is too big to show here.
nixos/modules/services/security/opensnitch.nix+125
This diff is too big to show here.
nixos/modules/services/security/physlock.nix+17−6
This diff is too big to show here.
nixos/modules/services/security/privacyidea.nix+309
This diff is too big to show here.
nixos/modules/services/security/shibboleth-sp.nix+1−1
This diff is too big to show here.
nixos/modules/services/security/sks.nix+33−3
This diff is too big to show here.
nixos/modules/services/security/sshguard.nix+69−49
This diff is too big to show here.
nixos/modules/services/security/sslmate-agent.nix+32
This diff is too big to show here.
nixos/modules/services/security/step-ca.nix+146
This diff is too big to show here.
nixos/modules/services/security/tor.nix+867−577
This diff is too big to show here.
nixos/modules/services/security/torify.nix+3
This diff is too big to show here.
nixos/modules/services/security/torsocks.nix+5−5
This diff is too big to show here.
nixos/modules/services/security/usbguard.nix+81−70
This diff is too big to show here.
nixos/modules/services/security/vault.nix+59−12
This diff is too big to show here.
nixos/modules/services/security/vaultwarden/backup.sh+17
This diff is too big to show here.
nixos/modules/services/security/vaultwarden/default.nix+185
This diff is too big to show here.
nixos/modules/services/security/yubikey-agent.nix+66
This diff is too big to show here.
nixos/modules/services/system/cachix-agent/default.nix+57
This diff is too big to show here.
nixos/modules/services/system/cgmanager.nix−27
This diff is too big to show here.
nixos/modules/services/system/cloud-init.nix+20−8
This diff is too big to show here.
nixos/modules/services/system/dbus.nix+32−10
This diff is too big to show here.
nixos/modules/services/system/earlyoom.nix+138−74
This diff is too big to show here.
nixos/modules/services/system/kerberos.nix−64
This diff is too big to show here.
nixos/modules/services/system/kerberos/default.nix+75
This diff is too big to show here.
nixos/modules/services/system/kerberos/heimdal.nix+68
This diff is too big to show here.
nixos/modules/services/system/kerberos/mit.nix+68
This diff is too big to show here.
nixos/modules/services/system/localtime.nix+18−23
This diff is too big to show here.
nixos/modules/services/system/nscd.conf+24−18
This diff is too big to show here.
nixos/modules/services/system/nscd.nix+33−27
This diff is too big to show here.
nixos/modules/services/system/saslauthd.nix+1−1
This diff is too big to show here.
nixos/modules/services/system/self-deploy.nix+173
This diff is too big to show here.
nixos/modules/services/system/systembus-notify.nix+27
This diff is too big to show here.
nixos/modules/services/system/uptimed.nix+8−3
This diff is too big to show here.
nixos/modules/services/torrent/deluge.nix+231−20
This diff is too big to show here.
nixos/modules/services/torrent/flexget.nix+3−3
This diff is too big to show here.
nixos/modules/services/torrent/magnetico.nix+220
This diff is too big to show here.
nixos/modules/services/torrent/opentracker.nix+1−1
This diff is too big to show here.
nixos/modules/services/torrent/peerflix.nix+12−4
This diff is too big to show here.
nixos/modules/services/torrent/rtorrent.nix+211
This diff is too big to show here.
nixos/modules/services/torrent/transmission.nix+443−120
This diff is too big to show here.
nixos/modules/services/ttys/agetty.nix−118
This diff is too big to show here.
nixos/modules/services/ttys/getty.nix+162
This diff is too big to show here.
nixos/modules/services/ttys/kmscon.nix+26−10
This diff is too big to show here.
nixos/modules/services/video/epgstation/default.nix+334
This diff is too big to show here.
nixos/modules/services/video/epgstation/streaming.json+140
This diff is too big to show here.
nixos/modules/services/video/mirakurun.nix+204
This diff is too big to show here.
nixos/modules/services/video/replay-sorcery.nix+72
This diff is too big to show here.
nixos/modules/services/video/rtsp-simple-server.nix+80
This diff is too big to show here.
nixos/modules/services/video/unifi-video.nix+271
This diff is too big to show here.
nixos/modules/services/wayland/cage.nix+103
This diff is too big to show here.
nixos/modules/services/web-apps/atlassian/confluence.nix+21−12
This diff is too big to show here.
nixos/modules/services/web-apps/atlassian/crowd.nix+21−10
This diff is too big to show here.
nixos/modules/services/web-apps/atlassian/jira.nix+23−11
This diff is too big to show here.
nixos/modules/services/web-apps/baget.nix+170
This diff is too big to show here.
nixos/modules/services/web-apps/bookstack.nix+449
This diff is too big to show here.
nixos/modules/services/web-apps/calibre-web.nix+165
This diff is too big to show here.
nixos/modules/services/web-apps/code-server.nix+139
This diff is too big to show here.
nixos/modules/services/web-apps/codimd.nix−920
This diff is too big to show here.
nixos/modules/services/web-apps/convos.nix+72
This diff is too big to show here.
nixos/modules/services/web-apps/cryptpad.nix+54
This diff is too big to show here.
nixos/modules/services/web-apps/dex.nix+118
This diff is too big to show here.
nixos/modules/services/web-apps/discourse.nix+1093
This diff is too big to show here.
nixos/modules/services/web-apps/discourse.xml+355
This diff is too big to show here.
nixos/modules/services/web-apps/documize.nix+150
This diff is too big to show here.
nixos/modules/services/web-apps/dokuwiki.nix+439
This diff is too big to show here.
nixos/modules/services/web-apps/engelsystem.nix+186
This diff is too big to show here.
nixos/modules/services/web-apps/ethercalc.nix+62
This diff is too big to show here.
nixos/modules/services/web-apps/fluidd.nix+66
This diff is too big to show here.
nixos/modules/services/web-apps/frab.nix−223
This diff is too big to show here.
nixos/modules/services/web-apps/galene.nix+214
This diff is too big to show here.
nixos/modules/services/web-apps/gerrit.nix+242
This diff is too big to show here.
nixos/modules/services/web-apps/gotify-server.nix+49
This diff is too big to show here.
nixos/modules/services/web-apps/grocy.nix+172
This diff is too big to show here.
nixos/modules/services/web-apps/grocy.xml+77
This diff is too big to show here.
nixos/modules/services/web-apps/hedgedoc.nix+1038
This diff is too big to show here.
nixos/modules/services/web-apps/hledger-web.nix+142
This diff is too big to show here.
nixos/modules/services/web-apps/icingaweb2/icingaweb2.nix+262
This diff is too big to show here.
nixos/modules/services/web-apps/icingaweb2/module-monitoring.nix+157
This diff is too big to show here.
nixos/modules/services/web-apps/ihatemoney/default.nix+153
This diff is too big to show here.
nixos/modules/services/web-apps/invidious.nix+264
This diff is too big to show here.
nixos/modules/services/web-apps/invoiceplane.nix+305
This diff is too big to show here.
nixos/modules/services/web-apps/isso.nix+69
This diff is too big to show here.
nixos/modules/services/web-apps/jirafeau.nix+173
This diff is too big to show here.
nixos/modules/services/web-apps/jitsi-meet.nix+452
This diff is too big to show here.
nixos/modules/services/web-apps/jitsi-meet.xml+55
This diff is too big to show here.
nixos/modules/services/web-apps/keycloak.nix+683
This diff is too big to show here.
nixos/modules/services/web-apps/keycloak.xml+202
This diff is too big to show here.
nixos/modules/services/web-apps/lemmy.md+34
This diff is too big to show here.
nixos/modules/services/web-apps/lemmy.nix+236
This diff is too big to show here.
nixos/modules/services/web-apps/lemmy.xml+56
This diff is too big to show here.
nixos/modules/services/web-apps/limesurvey.nix+280
This diff is too big to show here.
nixos/modules/services/web-apps/mastodon.nix+638
This diff is too big to show here.
nixos/modules/services/web-apps/matomo-doc.xml+35−18
This diff is too big to show here.
nixos/modules/services/web-apps/matomo.nix+149−67
This diff is too big to show here.
nixos/modules/services/web-apps/mattermost.nix+158−44
This diff is too big to show here.
nixos/modules/services/web-apps/mediawiki.nix+475
This diff is too big to show here.
nixos/modules/services/web-apps/miniflux.nix+127
This diff is too big to show here.
nixos/modules/services/web-apps/moodle.nix+315
This diff is too big to show here.
nixos/modules/services/web-apps/netbox.nix+265
This diff is too big to show here.
nixos/modules/services/web-apps/nextcloud.nix+744−223
This diff is too big to show here.
nixos/modules/services/web-apps/nextcloud.xml+291
This diff is too big to show here.
nixos/modules/services/web-apps/nexus.nix+27−5
This diff is too big to show here.
nixos/modules/services/web-apps/nifi.nix+318
This diff is too big to show here.
nixos/modules/services/web-apps/node-red.nix+149
This diff is too big to show here.
nixos/modules/services/web-apps/openwebrx.nix+34
This diff is too big to show here.
nixos/modules/services/web-apps/peertube.nix+475
This diff is too big to show here.
nixos/modules/services/web-apps/pgpkeyserver-lite.nix+7−4
This diff is too big to show here.
nixos/modules/services/web-apps/pict-rs.md+88
This diff is too big to show here.
nixos/modules/services/web-apps/pict-rs.nix+50
This diff is too big to show here.
nixos/modules/services/web-apps/pict-rs.xml+162
This diff is too big to show here.
nixos/modules/services/web-apps/plantuml-server.nix+140
This diff is too big to show here.
nixos/modules/services/web-apps/plausible.nix+292
This diff is too big to show here.
nixos/modules/services/web-apps/plausible.xml+51
This diff is too big to show here.
nixos/modules/services/web-apps/powerdns-admin.nix+152
This diff is too big to show here.
nixos/modules/services/web-apps/prosody-filer.nix+86
This diff is too big to show here.
nixos/modules/services/web-apps/quassel-webserver.nix−101
This diff is too big to show here.
nixos/modules/services/web-apps/restya-board.nix+39−43
This diff is too big to show here.
nixos/modules/services/web-apps/rss-bridge.nix+125
This diff is too big to show here.
nixos/modules/services/web-apps/selfoss.nix+16−18
This diff is too big to show here.
nixos/modules/services/web-apps/shiori.nix+96
This diff is too big to show here.
nixos/modules/services/web-apps/sogo.nix+271
This diff is too big to show here.
nixos/modules/services/web-apps/timetagger.nix+80
This diff is too big to show here.
nixos/modules/services/web-apps/trilium.nix+146
This diff is too big to show here.
nixos/modules/services/web-apps/tt-rss.nix+174−123
This diff is too big to show here.
nixos/modules/services/web-apps/vikunja.nix+145
This diff is too big to show here.
nixos/modules/services/web-apps/virtlyst.nix+1
This diff is too big to show here.
nixos/modules/services/web-apps/whitebophir.nix+52
This diff is too big to show here.
nixos/modules/services/web-apps/wiki-js.nix+139
This diff is too big to show here.
nixos/modules/services/web-apps/wordpress.nix+480
This diff is too big to show here.
nixos/modules/services/web-apps/youtrack.nix+17−13
This diff is too big to show here.
nixos/modules/services/web-apps/zabbix.nix+238
This diff is too big to show here.
nixos/modules/services/web-servers/agate.nix+148
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/default.nix+550−450
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/foswiki.nix−78
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/limesurvey.nix−196
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/location-options.nix+54
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/mediawiki.nix−348
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/mercurial.nix−75
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/owncloud.nix−608
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/per-server-options.nix−188
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/phabricator.nix−50
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/tomcat-connector.nix−103
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/trac.nix−121
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/vhost-options.nix+295
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/wordpress.nix−285
This diff is too big to show here.
nixos/modules/services/web-servers/apache-httpd/zabbix.nix−84
This diff is too big to show here.
nixos/modules/services/web-servers/caddy.nix−105
This diff is too big to show here.
nixos/modules/services/web-servers/caddy/default.nix+339
This diff is too big to show here.
nixos/modules/services/web-servers/caddy/vhost-options.nix+79
This diff is too big to show here.
nixos/modules/services/web-servers/darkhttpd.nix+77
This diff is too big to show here.
nixos/modules/services/web-servers/hitch/default.nix+4−1
This diff is too big to show here.
nixos/modules/services/web-servers/hydron.nix+23−25
This diff is too big to show here.
nixos/modules/services/web-servers/jboss/builder.sh+6−6
This diff is too big to show here.
nixos/modules/services/web-servers/jboss/default.nix+8
This diff is too big to show here.
nixos/modules/services/web-servers/lighttpd/cgit.nix+7−3
This diff is too big to show here.
nixos/modules/services/web-servers/lighttpd/collectd.nix+7−3
This diff is too big to show here.
nixos/modules/services/web-servers/lighttpd/default.nix+15−3
This diff is too big to show here.
nixos/modules/services/web-servers/meguca.nix−158
This diff is too big to show here.
nixos/modules/services/web-servers/mighttpd2.nix+1−1
This diff is too big to show here.
nixos/modules/services/web-servers/minio.nix+37−18
This diff is too big to show here.
nixos/modules/services/web-servers/molly-brown.nix+101
This diff is too big to show here.
nixos/modules/services/web-servers/nginx/default.nix+450−121
This diff is too big to show here.
nixos/modules/services/web-servers/nginx/gitweb.nix+45−12
This diff is too big to show here.
nixos/modules/services/web-servers/nginx/location-options.nix+49−3
This diff is too big to show here.
nixos/modules/services/web-servers/nginx/vhost-options.nix+80−10
This diff is too big to show here.
nixos/modules/services/web-servers/phpfpm/default.nix+190−70
This diff is too big to show here.
nixos/modules/services/web-servers/phpfpm/pool-options.nix−35
This diff is too big to show here.
nixos/modules/services/web-servers/pomerium.nix+135
This diff is too big to show here.
nixos/modules/services/web-servers/shellinabox.nix−122
This diff is too big to show here.
nixos/modules/services/web-servers/tomcat.nix+10−12
This diff is too big to show here.
nixos/modules/services/web-servers/traefik.nix+91−46
This diff is too big to show here.
nixos/modules/services/web-servers/trafficserver/default.nix+310
This diff is too big to show here.
nixos/modules/services/web-servers/trafficserver/ip_allow.json+36
This diff is too big to show here.
nixos/modules/services/web-servers/trafficserver/logging.json+37
This diff is too big to show here.
nixos/modules/services/web-servers/ttyd.nix+196
This diff is too big to show here.
nixos/modules/services/web-servers/unit/default.nix+155
This diff is too big to show here.
nixos/modules/services/web-servers/uwsgi.nix+105−36
This diff is too big to show here.
nixos/modules/services/web-servers/varnish/default.nix+10−8
This diff is too big to show here.
nixos/modules/services/web-servers/winstone.nix−129
This diff is too big to show here.
nixos/modules/services/web-servers/zope2.nix+11−7
This diff is too big to show here.
nixos/modules/services/x11/clight.nix+131
This diff is too big to show here.
nixos/modules/services/x11/colord.nix+11−9
This diff is too big to show here.
nixos/modules/services/x11/compton.nix−257
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/cde.nix+73
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/cinnamon.nix+218
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/default.nix+20−34
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/enlightenment.nix+53−33
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/gnome.nix+582
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/gnome.xml+253
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/gnome3.nix−188
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/kodi.nix+13−2
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/lumina.nix+11−15
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/lxqt.nix+15−14
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/mate.nix+42−75
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/maxx.nix−25
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/none.nix+44−5
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/pantheon.nix+314
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/pantheon.xml+120
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/plasma5.nix+428−80
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/retroarch.nix+40
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/surf-display.nix+128
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/xfce.nix+96−49
This diff is too big to show here.
nixos/modules/services/x11/desktop-managers/xterm.nix+4−2
This diff is too big to show here.
nixos/modules/services/x11/display-managers/account-service-util.nix+44
This diff is too big to show here.
nixos/modules/services/x11/display-managers/default.nix+272−134
This diff is too big to show here.
nixos/modules/services/x11/display-managers/gdm.nix+193−149
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm-greeters/enso-os.nix+12−31
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm-greeters/gtk.nix+44−31
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm-greeters/mini.nix+9−9
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm-greeters/pantheon.nix+49
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm-greeters/tiny.nix+92
This diff is too big to show here.
nixos/modules/services/x11/display-managers/lightdm.nix+127−78
This diff is too big to show here.
nixos/modules/services/x11/display-managers/sddm.nix+109−115
This diff is too big to show here.
nixos/modules/services/x11/display-managers/set-session.py+89
This diff is too big to show here.
nixos/modules/services/x11/display-managers/slim.nix+10−150
This diff is too big to show here.
nixos/modules/services/x11/display-managers/startx.nix+15−5
This diff is too big to show here.
nixos/modules/services/x11/display-managers/sx.nix+34
This diff is too big to show here.
nixos/modules/services/x11/display-managers/xpra.nix+3−3
This diff is too big to show here.
nixos/modules/services/x11/extra-layouts.nix+135
This diff is too big to show here.
nixos/modules/services/x11/gdk-pixbuf.nix+5−5
This diff is too big to show here.
nixos/modules/services/x11/hardware/cmt.nix+59
This diff is too big to show here.
nixos/modules/services/x11/hardware/digimend.nix+38
This diff is too big to show here.
nixos/modules/services/x11/hardware/libinput.nix+95−51
This diff is too big to show here.
nixos/modules/services/x11/hardware/multitouch.nix−94
This diff is too big to show here.
nixos/modules/services/x11/hardware/synaptics.nix+10−5
This diff is too big to show here.
nixos/modules/services/x11/hardware/wacom.nix+1
This diff is too big to show here.
nixos/modules/services/x11/imwheel.nix+71
This diff is too big to show here.
nixos/modules/services/x11/picom.nix+335
This diff is too big to show here.
nixos/modules/services/x11/redshift.nix+36−47
This diff is too big to show here.
nixos/modules/services/x11/terminal-server.nix+1−1
This diff is too big to show here.
nixos/modules/services/x11/touchegg.nix+38
This diff is too big to show here.
nixos/modules/services/x11/unclutter-xfixes.nix+1−1
This diff is too big to show here.
nixos/modules/services/x11/unclutter.nix+11−3
This diff is too big to show here.
nixos/modules/services/x11/urserver.nix+38
This diff is too big to show here.
nixos/modules/services/x11/urxvtd.nix+21−9
This diff is too big to show here.
nixos/modules/services/x11/window-managers/awesome.nix+1−1
This diff is too big to show here.
nixos/modules/services/x11/window-managers/berry.nix+25
This diff is too big to show here.
nixos/modules/services/x11/window-managers/bspwm.nix+6−6
This diff is too big to show here.
nixos/modules/services/x11/window-managers/clfswm.nix+13−3
This diff is too big to show here.
nixos/modules/services/x11/window-managers/cwm.nix+23
This diff is too big to show here.
nixos/modules/services/x11/window-managers/default.nix+18−8
This diff is too big to show here.
nixos/modules/services/x11/window-managers/dwm.nix+1−1
This diff is too big to show here.
nixos/modules/services/x11/window-managers/e16.nix+26
This diff is too big to show here.
nixos/modules/services/x11/window-managers/evilwm.nix+2−2
This diff is too big to show here.
nixos/modules/services/x11/window-managers/exwm.nix+19−4
This diff is too big to show here.
nixos/modules/services/x11/window-managers/fvwm.nix+1−1
This diff is too big to show here.
nixos/modules/services/x11/window-managers/herbstluftwm.nix+11−2
This diff is too big to show here.
nixos/modules/services/x11/window-managers/i3.nix+7−4
This diff is too big to show here.
nixos/modules/services/x11/window-managers/leftwm.nix+25
This diff is too big to show here.
nixos/modules/services/x11/window-managers/lwm.nix+25
This diff is too big to show here.
nixos/modules/services/x11/window-managers/metacity.nix+3−3
This diff is too big to show here.
nixos/modules/services/x11/window-managers/mlvwm.nix+41
This diff is too big to show here.
nixos/modules/services/x11/window-managers/qtile.nix+12−5
This diff is too big to show here.
nixos/modules/services/x11/window-managers/smallwm.nix+25
This diff is too big to show here.
nixos/modules/services/x11/window-managers/tinywm.nix+25
This diff is too big to show here.
nixos/modules/services/x11/window-managers/wmderland.nix+61
This diff is too big to show here.
nixos/modules/services/x11/window-managers/xmonad.nix+151−14
This diff is too big to show here.
nixos/modules/services/x11/window-managers/yeahwm.nix+25
This diff is too big to show here.
nixos/modules/services/x11/xautolock.nix+8−7
This diff is too big to show here.
nixos/modules/services/x11/xserver.nix+193−133
This diff is too big to show here.
nixos/modules/system/activation/activation-script.nix+100−57
This diff is too big to show here.
nixos/modules/system/activation/no-clone.nix+1−2
This diff is too big to show here.
nixos/modules/system/activation/switch-to-configuration.pl+705−273
This diff is too big to show here.
nixos/modules/system/activation/top-level.nix+150−68
This diff is too big to show here.
nixos/modules/system/boot/binfmt.nix+286−100
This diff is too big to show here.
nixos/modules/system/boot/coredump.nix−66
This diff is too big to show here.
nixos/modules/system/boot/emergency-mode.nix+1−1
This diff is too big to show here.
nixos/modules/system/boot/grow-partition.nix+6−3
This diff is too big to show here.
nixos/modules/system/boot/initrd-network.nix+41−30
This diff is too big to show here.
nixos/modules/system/boot/initrd-openvpn.nix+81
This diff is too big to show here.
nixos/modules/system/boot/initrd-ssh.nix+136−52
This diff is too big to show here.
nixos/modules/system/boot/kernel.nix+182−143
This diff is too big to show here.
nixos/modules/system/boot/kernel_config.nix+117
This diff is too big to show here.
nixos/modules/system/boot/kexec.nix+15−5
This diff is too big to show here.
nixos/modules/system/boot/loader/generations-dir/generations-dir-builder.sh+1−1
This diff is too big to show here.
nixos/modules/system/boot/loader/generations-dir/generations-dir.nix+1−4
This diff is too big to show here.
nixos/modules/system/boot/loader/generic-extlinux-compatible/default.nix+42−4
This diff is too big to show here.
nixos/modules/system/boot/loader/generic-extlinux-compatible/extlinux-conf-builder.sh+23−7
This diff is too big to show here.
nixos/modules/system/boot/loader/grub/grub.nix+242−46
This diff is too big to show here.
nixos/modules/system/boot/loader/grub/install-grub.pl+225−55
This diff is too big to show here.
nixos/modules/system/boot/loader/grub/ipxe.nix+1−1
This diff is too big to show here.
nixos/modules/system/boot/loader/grub/memtest.nix+40−17
This diff is too big to show here.
nixos/modules/system/boot/loader/init-script/init-script-builder.sh+2−3
This diff is too big to show here.
nixos/modules/system/boot/loader/loader.nix+6−1
This diff is too big to show here.
nixos/modules/system/boot/loader/raspberrypi/raspberrypi-builder.nix+2−3
This diff is too big to show here.
nixos/modules/system/boot/loader/raspberrypi/raspberrypi-builder.sh+13−2
This diff is too big to show here.
nixos/modules/system/boot/loader/raspberrypi/raspberrypi.nix+10−13
This diff is too big to show here.
nixos/modules/system/boot/loader/raspberrypi/uboot-builder.nix+6−4
This diff is too big to show here.
nixos/modules/system/boot/loader/systemd-boot/systemd-boot-builder.py+144−39
This diff is too big to show here.
nixos/modules/system/boot/loader/systemd-boot/systemd-boot.nix+196−7
This diff is too big to show here.
nixos/modules/system/boot/luksroot.nix+446−58
This diff is too big to show here.
nixos/modules/system/boot/modprobe.nix+3−1
This diff is too big to show here.
nixos/modules/system/boot/networkd.nix+1501−390
This diff is too big to show here.
nixos/modules/system/boot/pbkdf2-sha512.c+1−1
This diff is too big to show here.
nixos/modules/system/boot/plymouth.nix+99−25
This diff is too big to show here.
nixos/modules/system/boot/resolved.nix+43−14
This diff is too big to show here.
nixos/modules/system/boot/shutdown.nix+1−1
This diff is too big to show here.
nixos/modules/system/boot/stage-1-init.sh+136−65
This diff is too big to show here.
nixos/modules/system/boot/stage-1.nix+237−66
This diff is too big to show here.
nixos/modules/system/boot/stage-2-init.sh+71−99
This diff is too big to show here.
nixos/modules/system/boot/stage-2.nix+15−28
This diff is too big to show here.
nixos/modules/system/boot/systemd-lib.nix−218
This diff is too big to show here.
nixos/modules/system/boot/systemd-nspawn.nix−118
This diff is too big to show here.
nixos/modules/system/boot/systemd-unit-options.nix−509
This diff is too big to show here.
nixos/modules/system/boot/systemd.nix+230−518
This diff is too big to show here.
nixos/modules/system/boot/systemd/coredump.nix+57
This diff is too big to show here.
nixos/modules/system/boot/systemd/initrd-secrets.nix+36
This diff is too big to show here.
nixos/modules/system/boot/systemd/initrd.nix+502
This diff is too big to show here.
nixos/modules/system/boot/systemd/journald.nix+131
This diff is too big to show here.
nixos/modules/system/boot/systemd/logind.nix+114
This diff is too big to show here.
nixos/modules/system/boot/systemd/nspawn.nix+131
This diff is too big to show here.
nixos/modules/system/boot/systemd/shutdown.nix+58
This diff is too big to show here.
nixos/modules/system/boot/systemd/tmpfiles.nix+120
This diff is too big to show here.
nixos/modules/system/boot/systemd/user.nix+153
This diff is too big to show here.
nixos/modules/system/boot/timesyncd.nix+42−1
This diff is too big to show here.
nixos/modules/system/boot/tmp.nix+27−2
This diff is too big to show here.
nixos/modules/system/build.nix+21
This diff is too big to show here.
nixos/modules/system/etc/etc-activation.nix+12
This diff is too big to show here.
nixos/modules/system/etc/etc.nix+66−27
This diff is too big to show here.
nixos/modules/system/etc/make-etc.sh−46
This diff is too big to show here.
nixos/modules/system/etc/setup-etc.pl+6
This diff is too big to show here.
nixos/modules/system/etc/test.nix+70
This diff is too big to show here.
nixos/modules/tasks/auto-upgrade.nix+185−24
This diff is too big to show here.
nixos/modules/tasks/bcache.nix+16−6
This diff is too big to show here.
nixos/modules/tasks/cpu-freq.nix+57−19
This diff is too big to show here.
nixos/modules/tasks/encrypted-devices.nix+19−8
This diff is too big to show here.
nixos/modules/tasks/filesystems.nix+115−20
This diff is too big to show here.
nixos/modules/tasks/filesystems/apfs.nix+22
This diff is too big to show here.
nixos/modules/tasks/filesystems/bcachefs.nix+2−2
This diff is too big to show here.
nixos/modules/tasks/filesystems/btrfs.nix+24−7
This diff is too big to show here.
nixos/modules/tasks/filesystems/cifs.nix+1−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/ecryptfs.nix+12−2
This diff is too big to show here.
nixos/modules/tasks/filesystems/exfat.nix+5−3
This diff is too big to show here.
nixos/modules/tasks/filesystems/ext.nix+10−4
This diff is too big to show here.
nixos/modules/tasks/filesystems/f2fs.nix+7−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/jfs.nix+1−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/nfs.nix+41−14
This diff is too big to show here.
nixos/modules/tasks/filesystems/reiserfs.nix+1−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/unionfs-fuse.nix+16−5
This diff is too big to show here.
nixos/modules/tasks/filesystems/vboxsf.nix+1−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/vfat.nix+1−1
This diff is too big to show here.
nixos/modules/tasks/filesystems/xfs.nix+3−2
This diff is too big to show here.
nixos/modules/tasks/filesystems/zfs.nix+299−73
This diff is too big to show here.
nixos/modules/tasks/kbd.nix−126
This diff is too big to show here.
nixos/modules/tasks/lvm.nix+122−6
This diff is too big to show here.
nixos/modules/tasks/network-interfaces-scripted.nix+166−60
This diff is too big to show here.
nixos/modules/tasks/network-interfaces-systemd.nix+209−29
This diff is too big to show here.
nixos/modules/tasks/network-interfaces.nix+539−158
This diff is too big to show here.
nixos/modules/tasks/powertop.nix+1
This diff is too big to show here.
nixos/modules/tasks/snapraid.nix+230
This diff is too big to show here.
nixos/modules/tasks/swraid.nix+27−40
This diff is too big to show here.
nixos/modules/tasks/trackpoint.nix+5−4
This diff is too big to show here.
nixos/modules/testing/service-runner.nix+34−21
This diff is too big to show here.
nixos/modules/testing/test-instrumentation.nix+53−57
This diff is too big to show here.
nixos/modules/virtualisation/amazon-ec2-amis.nix+444
This diff is too big to show here.
nixos/modules/virtualisation/amazon-image.nix+60−36
This diff is too big to show here.
nixos/modules/virtualisation/amazon-init.nix+46−20
This diff is too big to show here.
nixos/modules/virtualisation/amazon-options.nix+62−2
This diff is too big to show here.
nixos/modules/virtualisation/anbox.nix+138
This diff is too big to show here.
nixos/modules/virtualisation/azure-agent.nix+8−13
This diff is too big to show here.
nixos/modules/virtualisation/azure-common.nix+7−1
This diff is too big to show here.
nixos/modules/virtualisation/azure-image.nix+30−19
This diff is too big to show here.
nixos/modules/virtualisation/brightbox-image.nix+3−3
This diff is too big to show here.
nixos/modules/virtualisation/build-vm.nix+58
This diff is too big to show here.
nixos/modules/virtualisation/cloudstack-config.nix+40
This diff is too big to show here.
nixos/modules/virtualisation/container-config.nix+3−2
This diff is too big to show here.
nixos/modules/virtualisation/containerd.nix+101
This diff is too big to show here.
nixos/modules/virtualisation/containers.nix+111−709
This diff is too big to show here.
nixos/modules/virtualisation/cri-o.nix+163
This diff is too big to show here.
nixos/modules/virtualisation/digital-ocean-config.nix+197
This diff is too big to show here.
nixos/modules/virtualisation/digital-ocean-image.nix+70
This diff is too big to show here.
nixos/modules/virtualisation/digital-ocean-init.nix+95
This diff is too big to show here.
nixos/modules/virtualisation/docker-preloader.nix−135
This diff is too big to show here.
nixos/modules/virtualisation/docker-rootless.nix+102
This diff is too big to show here.
nixos/modules/virtualisation/docker.nix+62−14
This diff is too big to show here.
nixos/modules/virtualisation/ec2-amis.nix+9−278
This diff is too big to show here.
nixos/modules/virtualisation/ec2-data.nix+6−2
This diff is too big to show here.
nixos/modules/virtualisation/ec2-metadata-fetcher.nix+77
This diff is too big to show here.
nixos/modules/virtualisation/ecs-agent.nix+2−3
This diff is too big to show here.
nixos/modules/virtualisation/gce-images.nix+9−1
This diff is too big to show here.
nixos/modules/virtualisation/google-compute-config.nix+37−196
This diff is too big to show here.
nixos/modules/virtualisation/google-compute-image.nix+15−5
This diff is too big to show here.
nixos/modules/virtualisation/hyperv-guest.nix+5−3
This diff is too big to show here.
nixos/modules/virtualisation/hyperv-image.nix+71
This diff is too big to show here.
nixos/modules/virtualisation/kubevirt.nix+30
This diff is too big to show here.
nixos/modules/virtualisation/kvmgt.nix+42−26
This diff is too big to show here.
nixos/modules/virtualisation/libvirtd.nix+257−88
This diff is too big to show here.
nixos/modules/virtualisation/lxc-container.nix+161−13
This diff is too big to show here.
nixos/modules/virtualisation/lxc.nix+9−5
This diff is too big to show here.
nixos/modules/virtualisation/lxd.nix+124−25
This diff is too big to show here.
nixos/modules/virtualisation/nixos-containers.nix+881
This diff is too big to show here.
nixos/modules/virtualisation/nova-config.nix−60
This diff is too big to show here.
nixos/modules/virtualisation/oci-containers.nix+365
This diff is too big to show here.
nixos/modules/virtualisation/openstack-config.nix+90
This diff is too big to show here.
nixos/modules/virtualisation/openstack-metadata-fetcher.nix+22
This diff is too big to show here.
nixos/modules/virtualisation/openstack-options.nix+71
This diff is too big to show here.
nixos/modules/virtualisation/openvswitch.nix+27−58
This diff is too big to show here.
nixos/modules/virtualisation/parallels-guest.nix+4−4
This diff is too big to show here.
nixos/modules/virtualisation/podman/default.nix+187
This diff is too big to show here.
nixos/modules/virtualisation/podman/dnsname.nix+36
This diff is too big to show here.
nixos/modules/virtualisation/podman/network-socket-ghostunnel.nix+34
This diff is too big to show here.
nixos/modules/virtualisation/podman/network-socket.nix+95
This diff is too big to show here.
nixos/modules/virtualisation/proxmox-image.nix+169
This diff is too big to show here.
nixos/modules/virtualisation/proxmox-lxc.nix+64
This diff is too big to show here.
nixos/modules/virtualisation/qemu-guest-agent.nix+10−1
This diff is too big to show here.
nixos/modules/virtualisation/qemu-vm.nix+608−141
This diff is too big to show here.
nixos/modules/virtualisation/railcar.nix+124
This diff is too big to show here.
nixos/modules/virtualisation/rkt.nix−64
This diff is too big to show here.
nixos/modules/virtualisation/spice-usb-redirection.nix+26
This diff is too big to show here.
nixos/modules/virtualisation/vagrant-guest.nix+58
This diff is too big to show here.
nixos/modules/virtualisation/vagrant-virtualbox-image.nix+60
This diff is too big to show here.
nixos/modules/virtualisation/virtualbox-guest.nix+2−2
This diff is too big to show here.
nixos/modules/virtualisation/virtualbox-host.nix+22−5
This diff is too big to show here.
nixos/modules/virtualisation/virtualbox-image.nix+123−13
This diff is too big to show here.
nixos/modules/virtualisation/vmware-guest.nix+41−11
This diff is too big to show here.
nixos/modules/virtualisation/vmware-host.nix+166
This diff is too big to show here.
nixos/modules/virtualisation/vmware-image.nix+91
This diff is too big to show here.
nixos/modules/virtualisation/waydroid.nix+75
This diff is too big to show here.
nixos/modules/virtualisation/xe-guest-utilities.nix+1−1
This diff is too big to show here.
nixos/modules/virtualisation/xen-dom0.nix+32−40
This diff is too big to show here.
nixos/release-combined.nix+126−103
This diff is too big to show here.
nixos/release-small.nix+40−12
This diff is too big to show here.
nixos/release.nix+124−18
This diff is too big to show here.
nixos/tests/3proxy.nix+189
This diff is too big to show here.
nixos/tests/acme.nix+586−28
This diff is too big to show here.
nixos/tests/adguardhome.nix+57
This diff is too big to show here.
nixos/tests/aesmd.nix+62
This diff is too big to show here.
nixos/tests/agda.nix+50
This diff is too big to show here.
nixos/tests/airsonic.nix+28
This diff is too big to show here.
nixos/tests/all-terminfo.nix+31
This diff is too big to show here.
nixos/tests/all-tests.nix+453−53
This diff is too big to show here.
nixos/tests/amazon-init-shell.nix+40
This diff is too big to show here.
nixos/tests/ammonite.nix−20
This diff is too big to show here.
nixos/tests/apfs.nix+54
This diff is too big to show here.
nixos/tests/apparmor.nix+82
This diff is too big to show here.
nixos/tests/atd.nix+12−12
This diff is too big to show here.
nixos/tests/atop.nix+226
This diff is too big to show here.
nixos/tests/avahi.nix+58−39
This diff is too big to show here.
nixos/tests/babeld.nix+142
This diff is too big to show here.
nixos/tests/bazarr.nix+26
This diff is too big to show here.
nixos/tests/bcachefs.nix+22−27
This diff is too big to show here.
nixos/tests/beanstalkd.nix+49
This diff is too big to show here.
nixos/tests/beegfs.nix−115
This diff is too big to show here.
nixos/tests/bees.nix+62
This diff is too big to show here.
nixos/tests/bind.nix+6−5
This diff is too big to show here.
nixos/tests/bird.nix+129
This diff is too big to show here.
nixos/tests/bitcoind.nix+46
This diff is too big to show here.
nixos/tests/bittorrent.nix+116−101
This diff is too big to show here.
nixos/tests/blivet.nix−87
This diff is too big to show here.
nixos/tests/blockbook-frontend.nix+28
This diff is too big to show here.
nixos/tests/blocky.nix+34
This diff is too big to show here.
nixos/tests/boot-stage1.nix+11−9
This diff is too big to show here.
nixos/tests/boot.nix+108−59
This diff is too big to show here.
nixos/tests/borgbackup.nix+103−57
This diff is too big to show here.
nixos/tests/botamusique.nix+51
This diff is too big to show here.
nixos/tests/bpf.nix+29
This diff is too big to show here.
nixos/tests/breitbandmessung.nix+33
This diff is too big to show here.
nixos/tests/brscan5.nix+43
This diff is too big to show here.
nixos/tests/btrbk.nix+110
This diff is too big to show here.
nixos/tests/buildbot.nix+101−108
This diff is too big to show here.
nixos/tests/buildkite-agents.nix+31
This diff is too big to show here.
nixos/tests/caddy.nix+107
This diff is too big to show here.
nixos/tests/cadvisor.nix+12−13
This diff is too big to show here.
nixos/tests/cage.nix+36
This diff is too big to show here.
nixos/tests/cagebreak.nix+64
This diff is too big to show here.
nixos/tests/calibre-web.nix+43
This diff is too big to show here.
nixos/tests/cassandra.nix+118−57
This diff is too big to show here.
nixos/tests/ceph-multi-node.nix+233
This diff is too big to show here.
nixos/tests/ceph-single-node-bluestore.nix+196
This diff is too big to show here.
nixos/tests/ceph-single-node.nix+196
This diff is too big to show here.
nixos/tests/ceph.nix−139
This diff is too big to show here.
nixos/tests/certmgr.nix+29−25
This diff is too big to show here.
nixos/tests/cfssl.nix+6−6
This diff is too big to show here.
nixos/tests/charliecloud.nix+43
This diff is too big to show here.
nixos/tests/chromium.nix+230−171
This diff is too big to show here.
nixos/tests/cjdns.nix+27−25
This diff is too big to show here.
nixos/tests/clickhouse.nix+32
This diff is too big to show here.
nixos/tests/cloud-init.nix+72−12
This diff is too big to show here.
nixos/tests/cntr.nix+75
This diff is too big to show here.
nixos/tests/cockroachdb.nix+124
This diff is too big to show here.
nixos/tests/codimd.nix−54
This diff is too big to show here.
nixos/tests/collectd.nix+38
This diff is too big to show here.
nixos/tests/common/acme/client/default.nix+16
This diff is too big to show here.
nixos/tests/common/acme/server/README.md+21
This diff is too big to show here.
nixos/tests/common/acme/server/acme.test.cert.pem+19
This diff is too big to show here.
nixos/tests/common/acme/server/acme.test.key.pem+27
This diff is too big to show here.
nixos/tests/common/acme/server/ca.cert.pem+20
This diff is too big to show here.
nixos/tests/common/acme/server/ca.key.pem+27
This diff is too big to show here.
nixos/tests/common/acme/server/default.nix+141
This diff is too big to show here.
nixos/tests/common/acme/server/generate-certs.nix+29
This diff is too big to show here.
nixos/tests/common/acme/server/snakeoil-certs.nix+13
This diff is too big to show here.
nixos/tests/common/auto.nix+4−4
This diff is too big to show here.
nixos/tests/common/ec2.nix+66
This diff is too big to show here.
nixos/tests/common/letsencrypt/common.nix−27
This diff is too big to show here.
nixos/tests/common/letsencrypt/default.nix−445
This diff is too big to show here.
nixos/tests/common/letsencrypt/mkcerts.nix−69
This diff is too big to show here.
nixos/tests/common/letsencrypt/mkcerts.sh−6
This diff is too big to show here.
nixos/tests/common/letsencrypt/snakeoil-certs.nix−253
This diff is too big to show here.
nixos/tests/common/lxd/config.yaml+24
This diff is too big to show here.
nixos/tests/common/resolver.nix+1−1
This diff is too big to show here.
nixos/tests/common/user-account.nix+1
This diff is too big to show here.
nixos/tests/common/wayland-cage.nix+13
This diff is too big to show here.
nixos/tests/common/webroot/news-rss.xml+19−7
This diff is too big to show here.
nixos/tests/common/x11.nix+11−6
This diff is too big to show here.
nixos/tests/consul.nix+229
This diff is too big to show here.
nixos/tests/containers-bridge.nix+49−36
This diff is too big to show here.
nixos/tests/containers-custom-pkgs.nix+34
This diff is too big to show here.
nixos/tests/containers-ephemeral.nix+54
This diff is too big to show here.
nixos/tests/containers-extra_veth.nix+36−47
This diff is too big to show here.
nixos/tests/containers-hosts.nix+9−12
This diff is too big to show here.
nixos/tests/containers-imperative.nix+137−82
This diff is too big to show here.
nixos/tests/containers-ip.nix+74
This diff is too big to show here.
nixos/tests/containers-ipv4.nix−55
This diff is too big to show here.
nixos/tests/containers-ipv6.nix−60
This diff is too big to show here.
nixos/tests/containers-macvlans.nix+18−18
This diff is too big to show here.
nixos/tests/containers-names.nix+37
This diff is too big to show here.
nixos/tests/containers-nested.nix+30
This diff is too big to show here.
nixos/tests/containers-physical_interfaces.nix+49−51
This diff is too big to show here.
nixos/tests/containers-portforward.nix+16−19
This diff is too big to show here.
nixos/tests/containers-reloadable.nix+26−20
This diff is too big to show here.
nixos/tests/containers-restart_networking.nix+49−49
This diff is too big to show here.
nixos/tests/containers-tmpfs.nix+63−52
This diff is too big to show here.
nixos/tests/convos.nix+30
This diff is too big to show here.
nixos/tests/corerad.nix+89
This diff is too big to show here.
nixos/tests/coturn.nix+29
This diff is too big to show here.
nixos/tests/couchdb.nix+42−35
This diff is too big to show here.
nixos/tests/cri-o.nix+19
This diff is too big to show here.
nixos/tests/croc.nix+51
This diff is too big to show here.
nixos/tests/cryptpad.nix+18
This diff is too big to show here.
nixos/tests/custom-ca.nix+193
This diff is too big to show here.
nixos/tests/deluge.nix+45−13
This diff is too big to show here.
nixos/tests/dendrite.nix+99
This diff is too big to show here.
nixos/tests/dex-oidc.nix+78
This diff is too big to show here.
nixos/tests/dhparams.nix+48−50
This diff is too big to show here.
nixos/tests/disable-installer-tools.nix+29
This diff is too big to show here.
nixos/tests/discourse.nix+201
This diff is too big to show here.
nixos/tests/dnscrypt-proxy.nix−33
This diff is too big to show here.
nixos/tests/dnscrypt-proxy2.nix+36
This diff is too big to show here.
nixos/tests/dnscrypt-wrapper/default.nix+72
This diff is too big to show here.
nixos/tests/dnscrypt-wrapper/public.key+1
This diff is too big to show here.
nixos/tests/dnscrypt-wrapper/secret.key+1
This diff is too big to show here.
nixos/tests/dnsdist.nix+48
This diff is too big to show here.
nixos/tests/doas.nix+98
This diff is too big to show here.
nixos/tests/docker-edge.nix+14−12
This diff is too big to show here.
nixos/tests/docker-preloader.nix−27
This diff is too big to show here.
nixos/tests/docker-registry.nix+31−33
This diff is too big to show here.
nixos/tests/docker-rootless.nix+41
This diff is too big to show here.
nixos/tests/docker-tools-cross.nix+76
This diff is too big to show here.
nixos/tests/docker-tools-overlay.nix+10−9
This diff is too big to show here.
nixos/tests/docker-tools.nix+413−56
This diff is too big to show here.
nixos/tests/docker.nix+17−12
This diff is too big to show here.
nixos/tests/documize.nix+62
This diff is too big to show here.
nixos/tests/doh-proxy-rust.nix+43
This diff is too big to show here.
nixos/tests/dokuwiki.nix+111
This diff is too big to show here.
nixos/tests/domination.nix+26
This diff is too big to show here.
nixos/tests/dovecot.nix+18−13
This diff is too big to show here.
nixos/tests/drbd.nix+87
This diff is too big to show here.
nixos/tests/earlyoom.nix+16
This diff is too big to show here.
nixos/tests/ec2.nix+90−110
This diff is too big to show here.
nixos/tests/ecryptfs.nix+62−61
This diff is too big to show here.
nixos/tests/elk.nix+199−46
This diff is too big to show here.
nixos/tests/emacs-daemon.nix+15−12
This diff is too big to show here.
nixos/tests/empty-file
This diff is too big to show here.
nixos/tests/engelsystem.nix+41
This diff is too big to show here.
nixos/tests/enlightenment.nix+96
This diff is too big to show here.
nixos/tests/env.nix+16−15
This diff is too big to show here.
nixos/tests/envoy.nix+33
This diff is too big to show here.
nixos/tests/ergo.nix+18
This diff is too big to show here.
nixos/tests/ergochat.nix+97
This diff is too big to show here.
nixos/tests/etcd-cluster.nix+23−26
This diff is too big to show here.
nixos/tests/etcd.nix+8−10
This diff is too big to show here.
nixos/tests/etebase-server.nix+50
This diff is too big to show here.
nixos/tests/etesync-dav.nix+21
This diff is too big to show here.
nixos/tests/fancontrol.nix+34
This diff is too big to show here.
nixos/tests/fcitx/config+12
This diff is too big to show here.
nixos/tests/fcitx/default.nix+141
This diff is too big to show here.
nixos/tests/fcitx/profile+4
This diff is too big to show here.
nixos/tests/fenics.nix+49
This diff is too big to show here.
nixos/tests/ferm.nix+18−17
This diff is too big to show here.
nixos/tests/firefox.nix+105−18
This diff is too big to show here.
nixos/tests/firejail.nix+91
This diff is too big to show here.
nixos/tests/firewall.nix+17−17
This diff is too big to show here.
nixos/tests/fish.nix+24
This diff is too big to show here.
nixos/tests/flannel.nix+22−20
This diff is too big to show here.
nixos/tests/flatpak.nix−26
This diff is too big to show here.
nixos/tests/fluentd.nix+49
This diff is too big to show here.
nixos/tests/fluidd.nix+21
This diff is too big to show here.
nixos/tests/fontconfig-default-fonts.nix+32
This diff is too big to show here.
nixos/tests/freeswitch.nix+29
This diff is too big to show here.
nixos/tests/frr.nix+104
This diff is too big to show here.
nixos/tests/fsck.nix+14−12
This diff is too big to show here.
nixos/tests/ft2-clone.nix+35
This diff is too big to show here.
nixos/tests/fwupd.nix−19
This diff is too big to show here.
nixos/tests/gdk-pixbuf.nix−21
This diff is too big to show here.
nixos/tests/gerrit.nix+54
This diff is too big to show here.
nixos/tests/geth.nix+41
This diff is too big to show here.
nixos/tests/ghostunnel.nix+103
This diff is too big to show here.
nixos/tests/git/hub.nix+17
This diff is too big to show here.
nixos/tests/gitdaemon.nix+71
This diff is too big to show here.
nixos/tests/gitea.nix+93−60
This diff is too big to show here.
nixos/tests/gitlab.nix+408−53
This diff is too big to show here.
nixos/tests/gitolite-fcgiwrap.nix+93
This diff is too big to show here.
nixos/tests/gitolite.nix+52−53
This diff is too big to show here.
nixos/tests/gjs.nix−19
This diff is too big to show here.
nixos/tests/glusterfs.nix+68
This diff is too big to show here.
nixos/tests/gnome-xorg.nix+96
This diff is too big to show here.
nixos/tests/gnome.nix+97
This diff is too big to show here.
nixos/tests/gnome3-gdm.nix−47
This diff is too big to show here.
nixos/tests/gnome3.nix−41
This diff is too big to show here.
nixos/tests/go-neb.nix+44
This diff is too big to show here.
nixos/tests/gobgpd.nix+71
This diff is too big to show here.
nixos/tests/gocd-agent.nix+17−9
This diff is too big to show here.
nixos/tests/gocd-server.nix+14−14
This diff is too big to show here.
nixos/tests/google-oslogin/default.nix+74
This diff is too big to show here.
nixos/tests/google-oslogin/server.nix+27
This diff is too big to show here.
nixos/tests/google-oslogin/server.py+135
This diff is too big to show here.
nixos/tests/gotify-server.nix+50
This diff is too big to show here.
nixos/tests/grafana.nix+96−12
This diff is too big to show here.
nixos/tests/graphite.nix+25−18
This diff is too big to show here.
nixos/tests/graylog.nix+115
This diff is too big to show here.
nixos/tests/grocy.nix+47
This diff is too big to show here.
nixos/tests/grub.nix+60
This diff is too big to show here.
nixos/tests/gvisor.nix+49
This diff is too big to show here.
nixos/tests/hadoop/default.nix+7
This diff is too big to show here.
nixos/tests/hadoop/hadoop.nix+255
This diff is too big to show here.
nixos/tests/hadoop/hdfs.nix+68−38
This diff is too big to show here.
nixos/tests/hadoop/yarn.nix+32−33
This diff is too big to show here.
nixos/tests/haka.nix+6−6
This diff is too big to show here.
nixos/tests/handbrake.nix−25
This diff is too big to show here.
nixos/tests/haproxy.nix+25−12
This diff is too big to show here.
nixos/tests/hardened.nix+64−37
This diff is too big to show here.
nixos/tests/haste-server.nix+23
This diff is too big to show here.
nixos/tests/hbase.nix+30
This diff is too big to show here.
nixos/tests/hedgedoc.nix+60
This diff is too big to show here.
nixos/tests/herbstluftwm.nix+37
This diff is too big to show here.
nixos/tests/hibernate.nix+114−24
This diff is too big to show here.
nixos/tests/hitch/default.nix+9−9
This diff is too big to show here.
nixos/tests/hledger-web.nix+50
This diff is too big to show here.
nixos/tests/hocker-fetchdocker/default.nix+7−6
This diff is too big to show here.
nixos/tests/hocker-fetchdocker/machine.nix+2−2
This diff is too big to show here.
nixos/tests/hockeypuck.nix+63
This diff is too big to show here.
nixos/tests/home-assistant.nix+142−65
This diff is too big to show here.
nixos/tests/hostname.nix+72
This diff is too big to show here.
nixos/tests/hound.nix+12−11
This diff is too big to show here.
nixos/tests/hydra/common.nix+48
This diff is too big to show here.
nixos/tests/hydra/create-trivial-project.sh+2
This diff is too big to show here.
nixos/tests/hydra/default.nix+40−58
This diff is too big to show here.
nixos/tests/i3wm.nix+35−24
This diff is too big to show here.
nixos/tests/icingaweb2.nix+71
This diff is too big to show here.
nixos/tests/iftop.nix+13−14
This diff is too big to show here.
nixos/tests/ihatemoney/default.nix+78
This diff is too big to show here.
nixos/tests/ihatemoney/rates.json+39
This diff is too big to show here.
nixos/tests/ihatemoney/server.crt+28
This diff is too big to show here.
nixos/tests/ihatemoney/server.key+52
This diff is too big to show here.
nixos/tests/image-contents.nix+51
This diff is too big to show here.
nixos/tests/incron.nix+17−17
This diff is too big to show here.
nixos/tests/influxdb.nix+22−15
This diff is too big to show here.
nixos/tests/initrd-network-openvpn/default.nix+145
This diff is too big to show here.
nixos/tests/initrd-network-openvpn/initrd.ovpn+29
This diff is too big to show here.
nixos/tests/initrd-network-openvpn/shared.key+21
This diff is too big to show here.
nixos/tests/initrd-network-ssh/default.nix+40−20
This diff is too big to show here.
nixos/tests/initrd-network-ssh/dropbear.priv
This diff is too big to show here.
nixos/tests/initrd-network-ssh/dropbear.pub−1
This diff is too big to show here.
nixos/tests/initrd-network-ssh/generate-keys.nix+3−5
This diff is too big to show here.
nixos/tests/initrd-network-ssh/id_ed25519+7
This diff is too big to show here.
nixos/tests/initrd-network-ssh/id_ed25519.pub+1
This diff is too big to show here.
nixos/tests/initrd-network-ssh/openssh.priv−51
This diff is too big to show here.
nixos/tests/initrd-network-ssh/openssh.pub−1
This diff is too big to show here.
nixos/tests/initrd-network-ssh/ssh_host_ed25519_key+7
This diff is too big to show here.
nixos/tests/initrd-network-ssh/ssh_host_ed25519_key.pub+1
This diff is too big to show here.
nixos/tests/initrd-network.nix+17−6
This diff is too big to show here.
nixos/tests/initrd-secrets.nix+41
This diff is too big to show here.
nixos/tests/input-remapper.nix+52
This diff is too big to show here.
nixos/tests/inspircd.nix+93
This diff is too big to show here.
nixos/tests/installed-tests/appstream-qt.nix+9
This diff is too big to show here.
nixos/tests/installed-tests/appstream.nix+9
This diff is too big to show here.
nixos/tests/installed-tests/colord.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/default.nix+111
This diff is too big to show here.
nixos/tests/installed-tests/flatpak-builder.nix+14
This diff is too big to show here.
nixos/tests/installed-tests/flatpak.nix+17
This diff is too big to show here.
nixos/tests/installed-tests/fwupd.nix+11
This diff is too big to show here.
nixos/tests/installed-tests/gcab.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/gdk-pixbuf.nix+13
This diff is too big to show here.
nixos/tests/installed-tests/gjs.nix+12
This diff is too big to show here.
nixos/tests/installed-tests/glib-networking.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/glib-testing.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/gnome-photos.nix+35
This diff is too big to show here.
nixos/tests/installed-tests/graphene.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/gsconnect.nix+7
This diff is too big to show here.
nixos/tests/installed-tests/ibus.nix+16
This diff is too big to show here.
nixos/tests/installed-tests/libgdata.nix+11
This diff is too big to show here.
nixos/tests/installed-tests/libjcat.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/librsvg.nix+9
This diff is too big to show here.
nixos/tests/installed-tests/libxmlb.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/malcontent.nix+5
This diff is too big to show here.
nixos/tests/installed-tests/ostree.nix+12
This diff is too big to show here.
nixos/tests/installed-tests/pipewire.nix+15
This diff is too big to show here.
nixos/tests/installed-tests/power-profiles-daemon.nix+9
This diff is too big to show here.
nixos/tests/installed-tests/xdg-desktop-portal.nix+9
This diff is too big to show here.
nixos/tests/installer-systemd-stage-1.nix+33
This diff is too big to show here.
nixos/tests/installer.nix+624−476
This diff is too big to show here.
nixos/tests/invidious.nix+81
This diff is too big to show here.
nixos/tests/invoiceplane.nix+82
This diff is too big to show here.
nixos/tests/iodine.nix+64
This diff is too big to show here.
nixos/tests/ipfs.nix+31−42
This diff is too big to show here.
nixos/tests/ipv6.nix+88−37
This diff is too big to show here.
nixos/tests/iscsi-multipath-root.nix+267
This diff is too big to show here.
nixos/tests/iscsi-root.nix+161
This diff is too big to show here.
nixos/tests/isso.nix+30
This diff is too big to show here.
nixos/tests/jackett.nix+19
This diff is too big to show here.
nixos/tests/jellyfin.nix+155
This diff is too big to show here.
nixos/tests/jenkins-cli.nix+30
This diff is too big to show here.
nixos/tests/jenkins.nix+95−13
This diff is too big to show here.
nixos/tests/jibri.nix+69
This diff is too big to show here.
nixos/tests/jirafeau.nix+22
This diff is too big to show here.
nixos/tests/jitsi-meet.nix+49
This diff is too big to show here.
nixos/tests/k3s-single-node-docker.nix+84
This diff is too big to show here.
nixos/tests/k3s-single-node.nix+82
This diff is too big to show here.
nixos/tests/kafka.nix+33−27
This diff is too big to show here.
nixos/tests/kbd-setfont-decompress.nix+21
This diff is too big to show here.
nixos/tests/kbd-update-search-paths-patch.nix+19
This diff is too big to show here.
nixos/tests/kea.nix+73
This diff is too big to show here.
nixos/tests/keepalived.nix+42
This diff is too big to show here.
nixos/tests/keepassxc.nix+68
This diff is too big to show here.
nixos/tests/kerberos/default.nix+7
This diff is too big to show here.
nixos/tests/kerberos/heimdal.nix+42
This diff is too big to show here.
nixos/tests/kerberos/mit.nix+41
This diff is too big to show here.
nixos/tests/kernel-generic.nix+41
This diff is too big to show here.
nixos/tests/kernel-latest-ath-user-regd.nix+17
This diff is too big to show here.
nixos/tests/kernel-latest.nix−17
This diff is too big to show here.
nixos/tests/kernel-lts.nix−17
This diff is too big to show here.
nixos/tests/kexec.nix+45−14
This diff is too big to show here.
nixos/tests/keycloak.nix+180
This diff is too big to show here.
nixos/tests/keymap.nix+88−49
This diff is too big to show here.
nixos/tests/knot.nix+216
This diff is too big to show here.
nixos/tests/krb5/deprecated-config.nix+6−4
This diff is too big to show here.
nixos/tests/krb5/example-config.nix+12−6
This diff is too big to show here.
nixos/tests/ksm.nix+22
This diff is too big to show here.
nixos/tests/kubernetes/base.nix+23−31
This diff is too big to show here.
nixos/tests/kubernetes/certs.nix−219
This diff is too big to show here.
nixos/tests/kubernetes/default.nix+13−5
This diff is too big to show here.
nixos/tests/kubernetes/dns.nix+56−32
This diff is too big to show here.
nixos/tests/kubernetes/e2e.nix+1−1
This diff is too big to show here.
nixos/tests/kubernetes/kubernetes-common.nix−58
This diff is too big to show here.
nixos/tests/kubernetes/rbac.nix+60−33
This diff is too big to show here.
nixos/tests/ldap.nix−119
This diff is too big to show here.
nixos/tests/leaps.nix+9−7
This diff is too big to show here.
nixos/tests/libinput.nix+38
This diff is too big to show here.
nixos/tests/libreddit.nix+19
This diff is too big to show here.
nixos/tests/libresprite.nix+30
This diff is too big to show here.
nixos/tests/libreswan.nix+134
This diff is too big to show here.
nixos/tests/lidarr.nix+20
This diff is too big to show here.
nixos/tests/lightdm.nix+11−12
This diff is too big to show here.
nixos/tests/limesurvey.nix+26
This diff is too big to show here.
nixos/tests/litestream.nix+93
This diff is too big to show here.
nixos/tests/locate.nix+62
This diff is too big to show here.
nixos/tests/login.nix+49−62
This diff is too big to show here.
nixos/tests/logrotate.nix+152
This diff is too big to show here.
nixos/tests/loki.nix+56
This diff is too big to show here.
nixos/tests/lorri/builder.sh+3
This diff is too big to show here.
nixos/tests/lorri/default.nix+26
This diff is too big to show here.
nixos/tests/lorri/fake-shell.nix+5
This diff is too big to show here.
nixos/tests/lvm2/default.nix+45
This diff is too big to show here.
nixos/tests/lvm2/systemd-stage-1.nix+104
This diff is too big to show here.
nixos/tests/lvm2/thinpool.nix+32
This diff is too big to show here.
nixos/tests/lvm2/vdo.nix+27
This diff is too big to show here.
nixos/tests/lxd-image-server.nix+94
This diff is too big to show here.
nixos/tests/lxd-nftables.nix+51
This diff is too big to show here.
nixos/tests/lxd.nix+114
This diff is too big to show here.
nixos/tests/maddy.nix+58
This diff is too big to show here.
nixos/tests/maestral.nix+72
This diff is too big to show here.
nixos/tests/magic-wormhole-mailbox-server.nix+38
This diff is too big to show here.
nixos/tests/magnetico.nix+41
This diff is too big to show here.
nixos/tests/mailcatcher.nix+35
This diff is too big to show here.
nixos/tests/mailhog.nix+24
This diff is too big to show here.
nixos/tests/make-test-python.nix+9
This diff is too big to show here.
nixos/tests/make-test.nix−9
This diff is too big to show here.
nixos/tests/man.nix+100
This diff is too big to show here.
nixos/tests/mathics.nix−20
This diff is too big to show here.
nixos/tests/matomo.nix+48
This diff is too big to show here.
nixos/tests/matrix-appservice-irc.nix+224
This diff is too big to show here.
nixos/tests/matrix-conduit.nix+95
This diff is too big to show here.
nixos/tests/matrix-synapse.nix+205−15
This diff is too big to show here.
nixos/tests/matrix/mjolnir.nix+170
This diff is too big to show here.
nixos/tests/matrix/pantalaimon.nix+88
This diff is too big to show here.
nixos/tests/mattermost.nix+124
This diff is too big to show here.
nixos/tests/mediatomb.nix+81
This diff is too big to show here.
nixos/tests/mediawiki.nix+28
This diff is too big to show here.
nixos/tests/meilisearch.nix+60
This diff is too big to show here.
nixos/tests/memcached.nix+11−15
This diff is too big to show here.
nixos/tests/mesos.nix−92
This diff is too big to show here.
nixos/tests/mesos_test.py−72
This diff is too big to show here.
nixos/tests/metabase.nix+19
This diff is too big to show here.
nixos/tests/minecraft-server.nix+37
This diff is too big to show here.
nixos/tests/minecraft.nix+28
This diff is too big to show here.
nixos/tests/minidlna.nix+41
This diff is too big to show here.
nixos/tests/miniflux.nix+82
This diff is too big to show here.
nixos/tests/minio.nix+40−16
This diff is too big to show here.
nixos/tests/misc.nix+132−111
This diff is too big to show here.
nixos/tests/mod_perl.nix+53
This diff is too big to show here.
nixos/tests/molly-brown.nix+71
This diff is too big to show here.
nixos/tests/mongodb.nix+53−29
This diff is too big to show here.
nixos/tests/moodle.nix+22
This diff is too big to show here.
nixos/tests/moonraker.nix+45
This diff is too big to show here.
nixos/tests/moosefs.nix+89
This diff is too big to show here.
nixos/tests/morty.nix+8−10
This diff is too big to show here.
nixos/tests/mosquitto.nix+208
This diff is too big to show here.
nixos/tests/mpd.nix+68−53
This diff is too big to show here.
nixos/tests/mpv.nix+28
This diff is too big to show here.
nixos/tests/mtp.nix+109
This diff is too big to show here.
nixos/tests/mumble.nix+48−36
This diff is too big to show here.
nixos/tests/munin.nix+23−25
This diff is too big to show here.
nixos/tests/musescore.nix+86
This diff is too big to show here.
nixos/tests/mutable-users.nix+46−12
This diff is too big to show here.
nixos/tests/mxisd.nix+7−7
This diff is too big to show here.
nixos/tests/mysql-backup.nix−50
This diff is too big to show here.
nixos/tests/mysql-replication.nix−81
This diff is too big to show here.
nixos/tests/mysql.nix−24
This diff is too big to show here.
nixos/tests/mysql/common.nix+10
This diff is too big to show here.
nixos/tests/mysql/mariadb-galera.nix+250
This diff is too big to show here.
nixos/tests/mysql/mysql-autobackup.nix+53
This diff is too big to show here.
nixos/tests/mysql/mysql-backup.nix+72
This diff is too big to show here.
nixos/tests/mysql/mysql-replication.nix+101
This diff is too big to show here.
nixos/tests/mysql/mysql.nix+149
This diff is too big to show here.
nixos/tests/mysql/testdb.sql
This diff is too big to show here.
nixos/tests/n8n.nix+25
This diff is too big to show here.
nixos/tests/nagios.nix+116
This diff is too big to show here.
nixos/tests/nar-serve.nix+48
This diff is too big to show here.
nixos/tests/nat.nix+31−28
This diff is too big to show here.
nixos/tests/nats.nix+63
This diff is too big to show here.
nixos/tests/navidrome.nix+12
This diff is too big to show here.
nixos/tests/nbd.nix+103
This diff is too big to show here.
nixos/tests/ncdns.nix+93
This diff is too big to show here.
nixos/tests/ndppd.nix+60
This diff is too big to show here.
nixos/tests/nebula.nix+223
This diff is too big to show here.
nixos/tests/neo4j.nix+20
This diff is too big to show here.
nixos/tests/netdata.nix+11−11
This diff is too big to show here.
nixos/tests/networking-proxy.nix+67−44
This diff is too big to show here.
nixos/tests/networking.nix+581−256
This diff is too big to show here.
nixos/tests/nextcloud/basic.nix+74−18
This diff is too big to show here.
nixos/tests/nextcloud/default.nix+20−8
This diff is too big to show here.
nixos/tests/nextcloud/with-mysql-and-memcached.nix+25−33
This diff is too big to show here.
nixos/tests/nextcloud/with-postgresql-and-redis.nix+31−59
This diff is too big to show here.
nixos/tests/nexus.nix+8−8
This diff is too big to show here.
nixos/tests/nfs.nix−90
This diff is too big to show here.
nixos/tests/nfs/default.nix+9
This diff is too big to show here.
nixos/tests/nfs/kerberos.nix+133
This diff is too big to show here.
nixos/tests/nfs/simple.nix+94
This diff is too big to show here.
nixos/tests/nghttpx.nix+7−7
This diff is too big to show here.
nixos/tests/nginx-auth.nix+47
This diff is too big to show here.
nixos/tests/nginx-etag.nix+88
This diff is too big to show here.
nixos/tests/nginx-modsecurity.nix+39
This diff is too big to show here.
nixos/tests/nginx-pubhtml.nix+21
This diff is too big to show here.
nixos/tests/nginx-sandbox.nix+65
This diff is too big to show here.
nixos/tests/nginx-sso.nix+48
This diff is too big to show here.
nixos/tests/nginx-variants.nix+33
This diff is too big to show here.
nixos/tests/nginx.nix+103−16
This diff is too big to show here.
nixos/tests/nitter.nix+18
This diff is too big to show here.
nixos/tests/nix-ld.nix+20
This diff is too big to show here.
nixos/tests/nix-serve-ssh.nix+45
This diff is too big to show here.
nixos/tests/nix-serve.nix+22
This diff is too big to show here.
nixos/tests/nix-ssh-serve.nix−39
This diff is too big to show here.
nixos/tests/nixops/default.nix+114
This diff is too big to show here.
nixos/tests/nixops/legacy/base-configuration.nix+31
This diff is too big to show here.
nixos/tests/nixops/legacy/nixops.nix+15
This diff is too big to show here.
nixos/tests/nixos-generate-config.nix+41
This diff is too big to show here.
nixos/tests/node-red.nix+31
This diff is too big to show here.
nixos/tests/nomad.nix+97
This diff is too big to show here.
nixos/tests/noto-fonts.nix+44
This diff is too big to show here.
nixos/tests/novacomd.nix+15−21
This diff is too big to show here.
nixos/tests/nsd.nix+36−28
This diff is too big to show here.
nixos/tests/nzbget.nix+46
This diff is too big to show here.
nixos/tests/nzbhydra2.nix+17
This diff is too big to show here.
nixos/tests/oci-containers.nix+43
This diff is too big to show here.
nixos/tests/odoo.nix+27
This diff is too big to show here.
nixos/tests/oh-my-zsh.nix+18
This diff is too big to show here.
nixos/tests/ombi.nix+18
This diff is too big to show here.
nixos/tests/openarena.nix+71
This diff is too big to show here.
nixos/tests/openldap.nix+126−31
This diff is too big to show here.
nixos/tests/openresty-lua.nix+55
This diff is too big to show here.
nixos/tests/opensmtpd-rspamd.nix+141
This diff is too big to show here.
nixos/tests/opensmtpd.nix+14−14
This diff is too big to show here.
nixos/tests/openssh.nix+77−40
This diff is too big to show here.
nixos/tests/openstack-image.nix+98
This diff is too big to show here.
nixos/tests/opentabletdriver.nix+30
This diff is too big to show here.
nixos/tests/orangefs.nix+82
This diff is too big to show here.
nixos/tests/os-prober.nix+121
This diff is too big to show here.
nixos/tests/osquery.nix−28
This diff is too big to show here.
nixos/tests/osrm-backend.nix+57
This diff is too big to show here.
nixos/tests/ostree.nix−21
This diff is too big to show here.
nixos/tests/overlayfs.nix+47
This diff is too big to show here.
nixos/tests/owncast.nix+42
This diff is too big to show here.
nixos/tests/owncloud.nix−39
This diff is too big to show here.
nixos/tests/pacemaker.nix+110
This diff is too big to show here.
nixos/tests/packagekit.nix+25
This diff is too big to show here.
nixos/tests/pam-oath-login.nix−124
This diff is too big to show here.
nixos/tests/pam/pam-file-contents.nix+25
This diff is too big to show here.
nixos/tests/pam/pam-oath-login.nix+108
This diff is too big to show here.
nixos/tests/pam/pam-u2f.nix+25
This diff is too big to show here.
nixos/tests/pam/pam-ussh.nix+70
This diff is too big to show here.
nixos/tests/pam/test_chfn.py+27
This diff is too big to show here.
nixos/tests/pantheon.nix+58
This diff is too big to show here.
nixos/tests/paperless.nix+44
This diff is too big to show here.
nixos/tests/parsedmarc/default.nix+235
This diff is too big to show here.
nixos/tests/partition.nix−247
This diff is too big to show here.
nixos/tests/pdns-recursor.nix+15
This diff is too big to show here.
nixos/tests/peerflix.nix+5−5
This diff is too big to show here.
nixos/tests/pgadmin4-standalone.nix+43
This diff is too big to show here.
nixos/tests/pgadmin4.nix+132
This diff is too big to show here.
nixos/tests/pgjwt.nix+10−13
This diff is too big to show here.
nixos/tests/pgmanage.nix+9−7
This diff is too big to show here.
nixos/tests/phabricator.nix−77
This diff is too big to show here.
nixos/tests/php-pcre.nix−44
This diff is too big to show here.
nixos/tests/php/default.nix+16
This diff is too big to show here.
nixos/tests/php/fpm.nix+59
This diff is too big to show here.
nixos/tests/php/httpd.nix+34
This diff is too big to show here.
nixos/tests/php/pcre.nix+42
This diff is too big to show here.
nixos/tests/pict-rs.nix+17
This diff is too big to show here.
nixos/tests/pinnwand.nix+94
This diff is too big to show here.
nixos/tests/plasma5-systemd-start.nix+42
This diff is too big to show here.
nixos/tests/plasma5.nix+39−42
This diff is too big to show here.
nixos/tests/plausible.nix+49
This diff is too big to show here.
nixos/tests/pleroma.nix+249
This diff is too big to show here.
nixos/tests/plikd.nix+27
This diff is too big to show here.
nixos/tests/plotinus.nix+16−15
This diff is too big to show here.
nixos/tests/podgrab.nix+34
This diff is too big to show here.
nixos/tests/podman/default.nix+144
This diff is too big to show here.
nixos/tests/podman/dnsname.nix+42
This diff is too big to show here.
nixos/tests/podman/tls-ghostunnel.nix+150
This diff is too big to show here.
nixos/tests/pomerium.nix+102
This diff is too big to show here.
nixos/tests/postfix-raise-smtpd-tls-security-level.nix+41
This diff is too big to show here.
nixos/tests/postfix.nix+77
This diff is too big to show here.
nixos/tests/postfixadmin.nix+31
This diff is too big to show here.
nixos/tests/postgis.nix+10−7
This diff is too big to show here.
nixos/tests/postgresql-wal-receiver.nix+119
This diff is too big to show here.
nixos/tests/postgresql.nix+104−34
This diff is too big to show here.
nixos/tests/power-profiles-daemon.nix+45
This diff is too big to show here.
nixos/tests/powerdns-admin.nix+117
This diff is too big to show here.
nixos/tests/powerdns.nix+57−3
This diff is too big to show here.
nixos/tests/pppd.nix+62
This diff is too big to show here.
nixos/tests/predictable-interface-names.nix+17−7
This diff is too big to show here.
nixos/tests/printing.nix+118−91
This diff is too big to show here.
nixos/tests/privacyidea.nix+43
This diff is too big to show here.
nixos/tests/privoxy.nix+113
This diff is too big to show here.
nixos/tests/prometheus-exporters.nix+1153−127
This diff is too big to show here.
nixos/tests/prometheus.nix+323−32
This diff is too big to show here.
nixos/tests/prosody.nix−78
This diff is too big to show here.
nixos/tests/prowlarr.nix+18
This diff is too big to show here.
nixos/tests/proxy.nix+71−77
This diff is too big to show here.
nixos/tests/pt2-clone.nix+35
This diff is too big to show here.
nixos/tests/pulseaudio.nix+71
This diff is too big to show here.
nixos/tests/qboot.nix+13
This diff is too big to show here.
nixos/tests/quagga.nix−96
This diff is too big to show here.
nixos/tests/quake3.nix−95
This diff is too big to show here.
nixos/tests/quorum.nix+102
This diff is too big to show here.
nixos/tests/rabbitmq.nix+15−9
This diff is too big to show here.
nixos/tests/radarr.nix+18
This diff is too big to show here.
nixos/tests/radicale.nix+77−88
This diff is too big to show here.
nixos/tests/rasdaemon.nix+34
This diff is too big to show here.
nixos/tests/redis.nix+46
This diff is too big to show here.
nixos/tests/redmine.nix+37−33
This diff is too big to show here.
nixos/tests/resolv.nix+46
This diff is too big to show here.
nixos/tests/restart-by-activation-script.nix+73
This diff is too big to show here.
nixos/tests/restic.nix+96
This diff is too big to show here.
nixos/tests/retroarch.nix+49
This diff is too big to show here.
nixos/tests/riak.nix+11−14
This diff is too big to show here.
nixos/tests/robustirc-bridge.nix+29
This diff is too big to show here.
nixos/tests/roundcube.nix+31
This diff is too big to show here.
nixos/tests/rspamd.nix+138−80
This diff is too big to show here.
nixos/tests/rss2email.nix+9−9
This diff is too big to show here.
nixos/tests/rstudio-server.nix+24
This diff is too big to show here.
nixos/tests/rsyncd.nix+36
This diff is too big to show here.
nixos/tests/rsyslogd.nix+14−16
This diff is too big to show here.
nixos/tests/run-in-machine.nix−20
This diff is too big to show here.
nixos/tests/rxe.nix+13−19
This diff is too big to show here.
nixos/tests/sabnzbd.nix+22
This diff is too big to show here.
nixos/tests/samba-wsdd.nix+44
This diff is too big to show here.
nixos/tests/samba.nix+9−10
This diff is too big to show here.
nixos/tests/sanoid.nix+112
This diff is too big to show here.
nixos/tests/sddm.nix+22−22
This diff is too big to show here.
nixos/tests/seafile.nix+121
This diff is too big to show here.
nixos/tests/searx.nix+114
This diff is too big to show here.
nixos/tests/service-runner.nix+36
This diff is too big to show here.
nixos/tests/sfxr-qt.nix+32
This diff is too big to show here.
nixos/tests/shadow.nix+119
This diff is too big to show here.
nixos/tests/shadowsocks/common.nix+84
This diff is too big to show here.
nixos/tests/shadowsocks/default.nix+16
This diff is too big to show here.
nixos/tests/shattered-pixel-dungeon.nix+30
This diff is too big to show here.
nixos/tests/shiori.nix+80
This diff is too big to show here.
nixos/tests/signal-desktop.nix+69
This diff is too big to show here.
nixos/tests/simple.nix+6−6
This diff is too big to show here.
nixos/tests/slim.nix−66
This diff is too big to show here.
nixos/tests/slurm.nix+98−62
This diff is too big to show here.
nixos/tests/smokeping.nix+10−9
This diff is too big to show here.
nixos/tests/snapcast.nix+90
This diff is too big to show here.
nixos/tests/snapper.nix+14−22
This diff is too big to show here.
nixos/tests/soapui.nix+24
This diff is too big to show here.
nixos/tests/sogo.nix+58
This diff is too big to show here.
nixos/tests/solanum.nix+97
This diff is too big to show here.
nixos/tests/solr.nix+32−23
This diff is too big to show here.
nixos/tests/sonarr.nix+18
This diff is too big to show here.
nixos/tests/sourcehut.nix+212
This diff is too big to show here.
nixos/tests/spacecookie.nix+56
This diff is too big to show here.
nixos/tests/spark/default.nix+27
This diff is too big to show here.
nixos/tests/spark/spark_sample.py+40
This diff is too big to show here.
nixos/tests/specialisation.nix+43
This diff is too big to show here.
nixos/tests/ssh-keys.nix+1−1
This diff is too big to show here.
nixos/tests/sslh.nix+83
This diff is too big to show here.
nixos/tests/sssd-ldap.nix+94
This diff is too big to show here.
nixos/tests/sssd.nix+17
This diff is too big to show here.