Compare commits
7 Commits
2.13.2
...
cache-getf
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
5e07e4b281 | ||
|
|
5d058d81f1 | ||
|
|
531cc6593a | ||
|
|
7568cbe344 | ||
|
|
357e095a7b | ||
|
|
007c4a7f3a | ||
|
|
188ed75d54 |
15
.github/CODEOWNERS
vendored
15
.github/CODEOWNERS
vendored
@@ -1,15 +0,0 @@
|
||||
# Pull requests concerning the listed files will automatically invite the respective maintainers as reviewers.
|
||||
# This file is not used for denoting any kind of ownership, but is merely a tool for handling notifications.
|
||||
#
|
||||
# Merge permissions are required for maintaining an entry in this file.
|
||||
# For documentation on this mechanism, see https://help.github.com/articles/about-codeowners/
|
||||
|
||||
# Default reviewers if nothing else matches
|
||||
* @edolstra @thufschmitt
|
||||
|
||||
# This file
|
||||
.github/CODEOWNERS @edolstra
|
||||
|
||||
# Public documentation
|
||||
/doc @fricklerhandwerk
|
||||
*.md @fricklerhandwerk
|
||||
4
.github/ISSUE_TEMPLATE/bug_report.md
vendored
4
.github/ISSUE_TEMPLATE/bug_report.md
vendored
@@ -30,7 +30,3 @@ A clear and concise description of what you expected to happen.
|
||||
**Additional context**
|
||||
|
||||
Add any other context about the problem here.
|
||||
|
||||
**Priorities**
|
||||
|
||||
Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
|
||||
|
||||
6
.github/ISSUE_TEMPLATE/feature_request.md
vendored
6
.github/ISSUE_TEMPLATE/feature_request.md
vendored
@@ -2,7 +2,7 @@
|
||||
name: Feature request
|
||||
about: Suggest an idea for this project
|
||||
title: ''
|
||||
labels: feature
|
||||
labels: improvement
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
@@ -18,7 +18,3 @@ A clear and concise description of any alternative solutions or features you've
|
||||
|
||||
**Additional context**
|
||||
Add any other context or screenshots about the feature request here.
|
||||
|
||||
**Priorities**
|
||||
|
||||
Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
|
||||
|
||||
36
.github/ISSUE_TEMPLATE/installer.md
vendored
36
.github/ISSUE_TEMPLATE/installer.md
vendored
@@ -1,36 +0,0 @@
|
||||
---
|
||||
name: Installer issue
|
||||
about: Report problems with installation
|
||||
title: ''
|
||||
labels: installer
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
## Platform
|
||||
|
||||
<!-- select the platform on which you tried to install Nix -->
|
||||
|
||||
- [ ] Linux: <!-- state your distribution, e.g. Arch Linux, Ubuntu, ... -->
|
||||
- [ ] macOS
|
||||
- [ ] WSL
|
||||
|
||||
## Additional information
|
||||
|
||||
<!-- state special circumstances on your system or additional steps you have taken prior to installation -->
|
||||
|
||||
## Output
|
||||
|
||||
<details><summary>Output</summary>
|
||||
|
||||
```log
|
||||
|
||||
<!-- paste console output here and remove this comment -->
|
||||
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Priorities
|
||||
|
||||
Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
|
||||
31
.github/ISSUE_TEMPLATE/missing_documentation.md
vendored
31
.github/ISSUE_TEMPLATE/missing_documentation.md
vendored
@@ -1,31 +0,0 @@
|
||||
---
|
||||
name: Missing or incorrect documentation
|
||||
about: Help us improve the reference manual
|
||||
title: ''
|
||||
labels: documentation
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
## Problem
|
||||
|
||||
<!-- describe your problem -->
|
||||
|
||||
## Checklist
|
||||
|
||||
<!-- make sure this issue is not redundant or obsolete -->
|
||||
|
||||
- [ ] checked [latest Nix manual] \([source])
|
||||
- [ ] checked [open documentation issues and pull requests] for possible duplicates
|
||||
|
||||
[latest Nix manual]: https://nixos.org/manual/nix/unstable/
|
||||
[source]: https://github.com/NixOS/nix/tree/master/doc/manual/src
|
||||
[open documentation issues and pull requests]: https://github.com/NixOS/nix/labels/documentation
|
||||
|
||||
## Proposal
|
||||
|
||||
<!-- propose a solution -->
|
||||
|
||||
## Priorities
|
||||
|
||||
Add :+1: to [issues you find important](https://github.com/NixOS/nix/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).
|
||||
@@ -1,11 +0,0 @@
|
||||
**Release Notes**
|
||||
Please include relevant [release notes](https://github.com/NixOS/nix/blob/master/doc/manual/src/release-notes/rl-next.md) as needed.
|
||||
|
||||
|
||||
**Testing**
|
||||
|
||||
If this issue is a regression or something that should block release, please consider including a test either in the [testsuite](https://github.com/NixOS/nix/tree/master/tests) or as a [hydraJob]( https://github.com/NixOS/nix/blob/master/flake.nix#L396) so that it can be part of the [automatic checks](https://hydra.nixos.org/jobset/nix/master).
|
||||
|
||||
**Priorities**
|
||||
|
||||
Add :+1: to [pull requests you find important](https://github.com/NixOS/nix/pulls?q=is%3Aopen+sort%3Areactions-%2B1-desc).
|
||||
2
.github/STALE-BOT.md
vendored
2
.github/STALE-BOT.md
vendored
@@ -3,7 +3,7 @@
|
||||
- Thanks for your contribution!
|
||||
- To remove the stale label, just leave a new comment.
|
||||
- _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.)
|
||||
- You can always ask for help on [our Discourse Forum](https://discourse.nixos.org/) or on [Matrix - #nix:nixos.org](https://matrix.to/#/#nix:nixos.org).
|
||||
- You can always ask for help on [our Discourse Forum](https://discourse.nixos.org/) or on the [#nixos IRC channel](https://webchat.freenode.net/#nixos).
|
||||
|
||||
## Suggestions for PRs
|
||||
|
||||
|
||||
9
.github/stale.yml
vendored
9
.github/stale.yml
vendored
@@ -1,9 +1,10 @@
|
||||
# Configuration for probot-stale - https://github.com/probot/stale
|
||||
daysUntilStale: 180
|
||||
daysUntilClose: false
|
||||
daysUntilClose: 365
|
||||
exemptLabels:
|
||||
- "critical"
|
||||
- "never-stale"
|
||||
staleLabel: "stale"
|
||||
markComment: false
|
||||
closeComment: false
|
||||
markComment: |
|
||||
I marked this as stale due to inactivity. → [More info](https://github.com/NixOS/nix/blob/master/.github/STALE-BOT.md)
|
||||
closeComment: |
|
||||
I closed this issue due to inactivity. → [More info](https://github.com/NixOS/nix/blob/master/.github/STALE-BOT.md)
|
||||
|
||||
32
.github/workflows/backport.yml
vendored
32
.github/workflows/backport.yml
vendored
@@ -1,32 +0,0 @@
|
||||
name: Backport
|
||||
on:
|
||||
pull_request_target:
|
||||
types: [closed, labeled]
|
||||
permissions:
|
||||
contents: read
|
||||
jobs:
|
||||
backport:
|
||||
name: Backport Pull Request
|
||||
permissions:
|
||||
# for zeebe-io/backport-action
|
||||
contents: write
|
||||
pull-requests: write
|
||||
if: github.repository_owner == 'NixOS' && github.event.pull_request.merged == true && (github.event_name != 'labeled' || startsWith('backport', github.event.label.name))
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
ref: ${{ github.event.pull_request.head.sha }}
|
||||
# required to find all branches
|
||||
fetch-depth: 0
|
||||
- name: Create backport PRs
|
||||
# should be kept in sync with `version`
|
||||
uses: zeebe-io/backport-action@v1.0.1
|
||||
with:
|
||||
# Config README: https://github.com/zeebe-io/backport-action#backport-action
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
github_workspace: ${{ github.workspace }}
|
||||
pull_description: |-
|
||||
Bot-based backport to `${target_branch}`, triggered by a label in #${pull_number}.
|
||||
# should be kept in sync with `uses`
|
||||
version: v0.0.5
|
||||
124
.github/workflows/ci.yml
vendored
124
.github/workflows/ci.yml
vendored
@@ -1,124 +0,0 @@
|
||||
name: "CI"
|
||||
|
||||
on:
|
||||
pull_request:
|
||||
push:
|
||||
|
||||
permissions: read-all
|
||||
|
||||
jobs:
|
||||
|
||||
tests:
|
||||
needs: [check_secrets]
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, macos-latest]
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 60
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: cachix/install-nix-action@v18
|
||||
- run: echo CACHIX_NAME="$(echo $GITHUB_REPOSITORY-install-tests | tr "[A-Z]/" "[a-z]-")" >> $GITHUB_ENV
|
||||
- uses: cachix/cachix-action@v12
|
||||
if: needs.check_secrets.outputs.cachix == 'true'
|
||||
with:
|
||||
name: '${{ env.CACHIX_NAME }}'
|
||||
signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
|
||||
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
|
||||
- run: nix --experimental-features 'nix-command flakes' flake check -L
|
||||
|
||||
check_secrets:
|
||||
permissions:
|
||||
contents: none
|
||||
name: Check Cachix and Docker secrets present for installer tests
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
cachix: ${{ steps.secret.outputs.cachix }}
|
||||
docker: ${{ steps.secret.outputs.docker }}
|
||||
steps:
|
||||
- name: Check for secrets
|
||||
id: secret
|
||||
env:
|
||||
_CACHIX_SECRETS: ${{ secrets.CACHIX_SIGNING_KEY }}${{ secrets.CACHIX_AUTH_TOKEN }}
|
||||
_DOCKER_SECRETS: ${{ secrets.DOCKERHUB_USERNAME }}${{ secrets.DOCKERHUB_TOKEN }}
|
||||
run: |
|
||||
echo "::set-output name=cachix::${{ env._CACHIX_SECRETS != '' }}"
|
||||
echo "::set-output name=docker::${{ env._DOCKER_SECRETS != '' }}"
|
||||
|
||||
installer:
|
||||
needs: [tests, check_secrets]
|
||||
if: github.event_name == 'push' && needs.check_secrets.outputs.cachix == 'true'
|
||||
runs-on: ubuntu-latest
|
||||
outputs:
|
||||
installerURL: ${{ steps.prepare-installer.outputs.installerURL }}
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- run: echo CACHIX_NAME="$(echo $GITHUB_REPOSITORY-install-tests | tr "[A-Z]/" "[a-z]-")" >> $GITHUB_ENV
|
||||
- uses: cachix/install-nix-action@v18
|
||||
- uses: cachix/cachix-action@v12
|
||||
with:
|
||||
name: '${{ env.CACHIX_NAME }}'
|
||||
signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
|
||||
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
|
||||
- id: prepare-installer
|
||||
run: scripts/prepare-installer-for-github-actions
|
||||
|
||||
installer_test:
|
||||
needs: [installer, check_secrets]
|
||||
if: github.event_name == 'push' && needs.check_secrets.outputs.cachix == 'true'
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, macos-latest]
|
||||
runs-on: ${{ matrix.os }}
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- run: echo CACHIX_NAME="$(echo $GITHUB_REPOSITORY-install-tests | tr "[A-Z]/" "[a-z]-")" >> $GITHUB_ENV
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
install_url: '${{needs.installer.outputs.installerURL}}'
|
||||
install_options: "--tarball-url-prefix https://${{ env.CACHIX_NAME }}.cachix.org/serve"
|
||||
- run: sudo apt install fish zsh
|
||||
if: matrix.os == 'ubuntu-latest'
|
||||
- run: brew install fish
|
||||
if: matrix.os == 'macos-latest'
|
||||
- run: exec bash -c "nix-instantiate -E 'builtins.currentTime' --eval"
|
||||
- run: exec sh -c "nix-instantiate -E 'builtins.currentTime' --eval"
|
||||
- run: exec zsh -c "nix-instantiate -E 'builtins.currentTime' --eval"
|
||||
- run: exec fish -c "nix-instantiate -E 'builtins.currentTime' --eval"
|
||||
|
||||
docker_push_image:
|
||||
needs: [check_secrets, tests]
|
||||
if: >-
|
||||
github.event_name == 'push' &&
|
||||
github.ref_name == 'master' &&
|
||||
needs.check_secrets.outputs.cachix == 'true' &&
|
||||
needs.check_secrets.outputs.docker == 'true'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: cachix/install-nix-action@v18
|
||||
- run: echo CACHIX_NAME="$(echo $GITHUB_REPOSITORY-install-tests | tr "[A-Z]/" "[a-z]-")" >> $GITHUB_ENV
|
||||
- run: echo NIX_VERSION="$(nix --experimental-features 'nix-command flakes' eval .\#default.version | tr -d \")" >> $GITHUB_ENV
|
||||
- uses: cachix/cachix-action@v12
|
||||
if: needs.check_secrets.outputs.cachix == 'true'
|
||||
with:
|
||||
name: '${{ env.CACHIX_NAME }}'
|
||||
signingKey: '${{ secrets.CACHIX_SIGNING_KEY }}'
|
||||
authToken: '${{ secrets.CACHIX_AUTH_TOKEN }}'
|
||||
- run: nix --experimental-features 'nix-command flakes' build .#dockerImage -L
|
||||
- run: docker load -i ./result/image.tar.gz
|
||||
- run: docker tag nix:$NIX_VERSION nixos/nix:$NIX_VERSION
|
||||
- run: docker tag nix:$NIX_VERSION nixos/nix:master
|
||||
- name: Login to Docker Hub
|
||||
uses: docker/login-action@v2
|
||||
with:
|
||||
username: ${{ secrets.DOCKERHUB_USERNAME }}
|
||||
password: ${{ secrets.DOCKERHUB_TOKEN }}
|
||||
- run: docker push nixos/nix:$NIX_VERSION
|
||||
- run: docker push nixos/nix:master
|
||||
20
.github/workflows/hydra_status.yml
vendored
20
.github/workflows/hydra_status.yml
vendored
@@ -1,20 +0,0 @@
|
||||
name: Hydra status
|
||||
|
||||
permissions: read-all
|
||||
|
||||
on:
|
||||
schedule:
|
||||
- cron: "12,42 * * * *"
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
check_hydra_status:
|
||||
name: Check Hydra status
|
||||
if: github.repository_owner == 'NixOS'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- run: bash scripts/check-hydra-status.sh
|
||||
|
||||
17
.github/workflows/test.yml
vendored
Normal file
17
.github/workflows/test.yml
vendored
Normal file
@@ -0,0 +1,17 @@
|
||||
name: "Test"
|
||||
on:
|
||||
pull_request:
|
||||
push:
|
||||
jobs:
|
||||
tests:
|
||||
strategy:
|
||||
matrix:
|
||||
os: [ubuntu-latest, macos-latest]
|
||||
runs-on: ${{ matrix.os }}
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- uses: cachix/install-nix-action@v12
|
||||
#- run: nix flake check
|
||||
- run: nix-build -A checks.$(if [[ `uname` = Linux ]]; then echo x86_64-linux; else echo x86_64-darwin; fi)
|
||||
20
.gitignore
vendored
20
.gitignore
vendored
@@ -15,20 +15,19 @@ perl/Makefile.config
|
||||
/doc/manual/*.1
|
||||
/doc/manual/*.5
|
||||
/doc/manual/*.8
|
||||
/doc/manual/generated/*
|
||||
/doc/manual/nix.json
|
||||
/doc/manual/conf-file.json
|
||||
/doc/manual/builtins.json
|
||||
/doc/manual/src/SUMMARY.md
|
||||
/doc/manual/src/command-ref/new-cli
|
||||
/doc/manual/src/command-ref/conf-file.md
|
||||
/doc/manual/src/language/builtins.md
|
||||
/doc/manual/src/expressions/builtins.md
|
||||
|
||||
# /scripts/
|
||||
/scripts/nix-profile.sh
|
||||
/scripts/nix-reduce-build
|
||||
/scripts/nix-http-export.cgi
|
||||
/scripts/nix-profile-daemon.sh
|
||||
/scripts/nix-profile.fish
|
||||
/scripts/nix-profile-daemon.fish
|
||||
|
||||
# /src/libexpr/
|
||||
/src/libexpr/lexer-tab.cc
|
||||
@@ -37,11 +36,9 @@ perl/Makefile.config
|
||||
/src/libexpr/parser-tab.hh
|
||||
/src/libexpr/parser-tab.output
|
||||
/src/libexpr/nix.tbl
|
||||
/src/libexpr/tests/libexpr-tests
|
||||
|
||||
# /src/libstore/
|
||||
*.gen.*
|
||||
/src/libstore/tests/libstore-tests
|
||||
|
||||
# /src/libutil/
|
||||
/src/libutil/tests/libutil-tests
|
||||
@@ -59,6 +56,9 @@ perl/Makefile.config
|
||||
|
||||
/src/nix-prefetch-url/nix-prefetch-url
|
||||
|
||||
# /src/nix-daemon/
|
||||
/src/nix-daemon/nix-daemon
|
||||
|
||||
/src/nix-collect-garbage/nix-collect-garbage
|
||||
|
||||
# /src/nix-channel/
|
||||
@@ -76,13 +76,12 @@ perl/Makefile.config
|
||||
# /tests/
|
||||
/tests/test-tmp
|
||||
/tests/common.sh
|
||||
/tests/dummy
|
||||
/tests/result*
|
||||
/tests/restricted-innocent
|
||||
/tests/shell
|
||||
/tests/shell.drv
|
||||
/tests/config.nix
|
||||
/tests/ca/config.nix
|
||||
/tests/repl-result-out
|
||||
|
||||
# /tests/lang/
|
||||
/tests/lang/*.out
|
||||
@@ -94,7 +93,6 @@ perl/Makefile.config
|
||||
|
||||
/misc/systemd/nix-daemon.service
|
||||
/misc/systemd/nix-daemon.socket
|
||||
/misc/systemd/nix-daemon.conf
|
||||
/misc/upstart/nix-daemon.conf
|
||||
|
||||
/src/resolve-system-dependencies/resolve-system-dependencies
|
||||
@@ -125,7 +123,3 @@ GTAGS
|
||||
compile_commands.json
|
||||
|
||||
nix-rust/target
|
||||
|
||||
result
|
||||
|
||||
.vscode/
|
||||
|
||||
9
Makefile
9
Makefile
@@ -4,18 +4,14 @@ makefiles = \
|
||||
src/libutil/local.mk \
|
||||
src/libutil/tests/local.mk \
|
||||
src/libstore/local.mk \
|
||||
src/libstore/tests/local.mk \
|
||||
src/libfetchers/local.mk \
|
||||
src/libmain/local.mk \
|
||||
src/libexpr/local.mk \
|
||||
src/libexpr/tests/local.mk \
|
||||
src/libcmd/local.mk \
|
||||
src/nix/local.mk \
|
||||
src/resolve-system-dependencies/local.mk \
|
||||
scripts/local.mk \
|
||||
misc/bash/local.mk \
|
||||
misc/fish/local.mk \
|
||||
misc/zsh/local.mk \
|
||||
misc/systemd/local.mk \
|
||||
misc/launchd/local.mk \
|
||||
misc/upstart/local.mk \
|
||||
@@ -28,12 +24,11 @@ makefiles = \
|
||||
OPTIMIZE = 1
|
||||
|
||||
ifeq ($(OPTIMIZE), 1)
|
||||
GLOBAL_CXXFLAGS += -O3 $(CXXLTO)
|
||||
GLOBAL_LDFLAGS += $(CXXLTO)
|
||||
GLOBAL_CXXFLAGS += -O3
|
||||
else
|
||||
GLOBAL_CXXFLAGS += -O0 -U_FORTIFY_SOURCE
|
||||
endif
|
||||
|
||||
include mk/lib.mk
|
||||
|
||||
GLOBAL_CXXFLAGS += -g -Wall -include config.h -std=c++17 -I src
|
||||
GLOBAL_CXXFLAGS += -g -Wall -include config.h -std=c++17
|
||||
|
||||
@@ -6,19 +6,15 @@ CC = @CC@
|
||||
CFLAGS = @CFLAGS@
|
||||
CXX = @CXX@
|
||||
CXXFLAGS = @CXXFLAGS@
|
||||
CXXLTO = @CXXLTO@
|
||||
EDITLINE_LIBS = @EDITLINE_LIBS@
|
||||
ENABLE_S3 = @ENABLE_S3@
|
||||
GTEST_LIBS = @GTEST_LIBS@
|
||||
HAVE_LIBCPUID = @HAVE_LIBCPUID@
|
||||
HAVE_SECCOMP = @HAVE_SECCOMP@
|
||||
HOST_OS = @host_os@
|
||||
LDFLAGS = @LDFLAGS@
|
||||
LIBARCHIVE_LIBS = @LIBARCHIVE_LIBS@
|
||||
LIBBROTLI_LIBS = @LIBBROTLI_LIBS@
|
||||
LIBCURL_LIBS = @LIBCURL_LIBS@
|
||||
LIBSECCOMP_LIBS = @LIBSECCOMP_LIBS@
|
||||
LOWDOWN_LIBS = @LOWDOWN_LIBS@
|
||||
LIBLZMA_LIBS = @LIBLZMA_LIBS@
|
||||
OPENSSL_LIBS = @OPENSSL_LIBS@
|
||||
PACKAGE_NAME = @PACKAGE_NAME@
|
||||
PACKAGE_VERSION = @PACKAGE_VERSION@
|
||||
@@ -31,7 +27,6 @@ datadir = @datadir@
|
||||
datarootdir = @datarootdir@
|
||||
doc_generate = @doc_generate@
|
||||
docdir = @docdir@
|
||||
embedded_sandbox_shell = @embedded_sandbox_shell@
|
||||
exec_prefix = @exec_prefix@
|
||||
includedir = @includedir@
|
||||
libdir = @libdir@
|
||||
|
||||
@@ -20,7 +20,7 @@ Information on additional installation methods is available on the [Nix download
|
||||
|
||||
## Building And Developing
|
||||
|
||||
See our [Hacking guide](https://nixos.org/manual/nix/stable/contributing/hacking.html) in our manual for instruction on how to
|
||||
See our [Hacking guide](https://hydra.nixos.org/job/nix/master/build.x86_64-linux/latest/download-by-type/doc/manual/contributing/hacking.html) in our manual for instruction on how to
|
||||
build nix from source with nix-build or how to get a development environment.
|
||||
|
||||
## Additional Resources
|
||||
@@ -28,8 +28,7 @@ build nix from source with nix-build or how to get a development environment.
|
||||
- [Nix manual](https://nixos.org/nix/manual)
|
||||
- [Nix jobsets on hydra.nixos.org](https://hydra.nixos.org/project/nix)
|
||||
- [NixOS Discourse](https://discourse.nixos.org/)
|
||||
- [Matrix - #nix:nixos.org](https://matrix.to/#/#nix:nixos.org)
|
||||
- [IRC - #nixos on libera.chat](irc://irc.libera.chat/#nixos)
|
||||
- [IRC - #nixos on freenode.net](irc://irc.freenode.net/#nixos)
|
||||
|
||||
## License
|
||||
|
||||
|
||||
@@ -1,77 +0,0 @@
|
||||
diff --git a/darwin_stop_world.c b/darwin_stop_world.c
|
||||
index 3dbaa3fb..36a1d1f7 100644
|
||||
--- a/darwin_stop_world.c
|
||||
+++ b/darwin_stop_world.c
|
||||
@@ -352,6 +352,7 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
int nthreads = 0;
|
||||
word total_size = 0;
|
||||
mach_msg_type_number_t listcount = (mach_msg_type_number_t)THREAD_TABLE_SZ;
|
||||
+ size_t stack_limit;
|
||||
if (!EXPECT(GC_thr_initialized, TRUE))
|
||||
GC_thr_init();
|
||||
|
||||
@@ -407,6 +408,19 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
GC_push_all_stack_sections(lo, hi, p->traced_stack_sect);
|
||||
}
|
||||
if (altstack_lo) {
|
||||
+ // When a thread goes into a coroutine, we lose its original sp until
|
||||
+ // control flow returns to the thread.
|
||||
+ // While in the coroutine, the sp points outside the thread stack,
|
||||
+ // so we can detect this and push the entire thread stack instead,
|
||||
+ // as an approximation.
|
||||
+ // We assume that the coroutine has similarly added its entire stack.
|
||||
+ // This could be made accurate by cooperating with the application
|
||||
+ // via new functions and/or callbacks.
|
||||
+ stack_limit = pthread_get_stacksize_np(p->id);
|
||||
+ if (altstack_lo >= altstack_hi || altstack_lo < altstack_hi - stack_limit) { // sp outside stack
|
||||
+ altstack_lo = altstack_hi - stack_limit;
|
||||
+ }
|
||||
+
|
||||
total_size += altstack_hi - altstack_lo;
|
||||
GC_push_all_stack(altstack_lo, altstack_hi);
|
||||
}
|
||||
diff --git a/pthread_stop_world.c b/pthread_stop_world.c
|
||||
index b5d71e62..aed7b0bf 100644
|
||||
--- a/pthread_stop_world.c
|
||||
+++ b/pthread_stop_world.c
|
||||
@@ -768,6 +768,8 @@ STATIC void GC_restart_handler(int sig)
|
||||
/* world is stopped. Should not fail if it isn't. */
|
||||
GC_INNER void GC_push_all_stacks(void)
|
||||
{
|
||||
+ size_t stack_limit;
|
||||
+ pthread_attr_t pattr;
|
||||
GC_bool found_me = FALSE;
|
||||
size_t nthreads = 0;
|
||||
int i;
|
||||
@@ -851,6 +853,31 @@ GC_INNER void GC_push_all_stacks(void)
|
||||
hi = p->altstack + p->altstack_size;
|
||||
/* FIXME: Need to scan the normal stack too, but how ? */
|
||||
/* FIXME: Assume stack grows down */
|
||||
+ } else {
|
||||
+ if (pthread_getattr_np(p->id, &pattr)) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_getattr_np failed!");
|
||||
+ }
|
||||
+ if (pthread_attr_getstacksize(&pattr, &stack_limit)) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_attr_getstacksize failed!");
|
||||
+ }
|
||||
+ if (pthread_attr_destroy(&pattr)) {
|
||||
+ ABORT("GC_push_all_stacks: pthread_attr_destroy failed!");
|
||||
+ }
|
||||
+ // When a thread goes into a coroutine, we lose its original sp until
|
||||
+ // control flow returns to the thread.
|
||||
+ // While in the coroutine, the sp points outside the thread stack,
|
||||
+ // so we can detect this and push the entire thread stack instead,
|
||||
+ // as an approximation.
|
||||
+ // We assume that the coroutine has similarly added its entire stack.
|
||||
+ // This could be made accurate by cooperating with the application
|
||||
+ // via new functions and/or callbacks.
|
||||
+ #ifndef STACK_GROWS_UP
|
||||
+ if (lo >= hi || lo < hi - stack_limit) { // sp outside stack
|
||||
+ lo = hi - stack_limit;
|
||||
+ }
|
||||
+ #else
|
||||
+ #error "STACK_GROWS_UP not supported in boost_coroutine2 (as of june 2021), so we don't support it in Nix."
|
||||
+ #endif
|
||||
}
|
||||
GC_push_all_stack_sections(lo, hi, traced_stack_sect);
|
||||
# ifdef STACK_GROWS_UP
|
||||
20
config/config.guess
vendored
20
config/config.guess
vendored
@@ -1,8 +1,8 @@
|
||||
#! /bin/sh
|
||||
# Attempt to guess a canonical system name.
|
||||
# Copyright 1992-2021 Free Software Foundation, Inc.
|
||||
# Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
timestamp='2021-01-25'
|
||||
timestamp='2020-11-19'
|
||||
|
||||
# This file is free software; you can redistribute it and/or modify it
|
||||
# under the terms of the GNU General Public License as published by
|
||||
@@ -50,7 +50,7 @@ version="\
|
||||
GNU config.guess ($timestamp)
|
||||
|
||||
Originally written by Per Bothner.
|
||||
Copyright 1992-2021 Free Software Foundation, Inc.
|
||||
Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
This is free software; see the source for copying conditions. There is NO
|
||||
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
|
||||
@@ -188,9 +188,10 @@ case "$UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION" in
|
||||
#
|
||||
# Note: NetBSD doesn't particularly care about the vendor
|
||||
# portion of the name. We always set it to "unknown".
|
||||
sysctl="sysctl -n hw.machine_arch"
|
||||
UNAME_MACHINE_ARCH=$( (uname -p 2>/dev/null || \
|
||||
/sbin/sysctl -n hw.machine_arch 2>/dev/null || \
|
||||
/usr/sbin/sysctl -n hw.machine_arch 2>/dev/null || \
|
||||
"/sbin/$sysctl" 2>/dev/null || \
|
||||
"/usr/sbin/$sysctl" 2>/dev/null || \
|
||||
echo unknown))
|
||||
case "$UNAME_MACHINE_ARCH" in
|
||||
aarch64eb) machine=aarch64_be-unknown ;;
|
||||
@@ -995,9 +996,6 @@ EOF
|
||||
k1om:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
loongarch32:Linux:*:* | loongarch64:Linux:*:* | loongarchx32:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
m32r*:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
@@ -1086,7 +1084,7 @@ EOF
|
||||
ppcle:Linux:*:*)
|
||||
echo powerpcle-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
riscv32:Linux:*:* | riscv32be:Linux:*:* | riscv64:Linux:*:* | riscv64be:Linux:*:*)
|
||||
riscv32:Linux:*:* | riscv64:Linux:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-linux-"$LIBC"
|
||||
exit ;;
|
||||
s390:Linux:*:* | s390x:Linux:*:*)
|
||||
@@ -1482,8 +1480,8 @@ EOF
|
||||
i*86:rdos:*:*)
|
||||
echo "$UNAME_MACHINE"-pc-rdos
|
||||
exit ;;
|
||||
*:AROS:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-aros
|
||||
i*86:AROS:*:*)
|
||||
echo "$UNAME_MACHINE"-pc-aros
|
||||
exit ;;
|
||||
x86_64:VMkernel:*:*)
|
||||
echo "$UNAME_MACHINE"-unknown-esx
|
||||
|
||||
20
config/config.sub
vendored
20
config/config.sub
vendored
@@ -1,8 +1,8 @@
|
||||
#! /bin/sh
|
||||
# Configuration validation subroutine script.
|
||||
# Copyright 1992-2021 Free Software Foundation, Inc.
|
||||
# Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
timestamp='2021-01-08'
|
||||
timestamp='2020-12-02'
|
||||
|
||||
# This file is free software; you can redistribute it and/or modify it
|
||||
# under the terms of the GNU General Public License as published by
|
||||
@@ -67,7 +67,7 @@ Report bugs and patches to <config-patches@gnu.org>."
|
||||
version="\
|
||||
GNU config.sub ($timestamp)
|
||||
|
||||
Copyright 1992-2021 Free Software Foundation, Inc.
|
||||
Copyright 1992-2020 Free Software Foundation, Inc.
|
||||
|
||||
This is free software; see the source for copying conditions. There is NO
|
||||
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
|
||||
@@ -1185,7 +1185,6 @@ case $cpu-$vendor in
|
||||
| k1om \
|
||||
| le32 | le64 \
|
||||
| lm32 \
|
||||
| loongarch32 | loongarch64 | loongarchx32 \
|
||||
| m32c | m32r | m32rle \
|
||||
| m5200 | m68000 | m680[012346]0 | m68360 | m683?2 | m68k \
|
||||
| m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x \
|
||||
@@ -1230,7 +1229,7 @@ case $cpu-$vendor in
|
||||
| powerpc | powerpc64 | powerpc64le | powerpcle | powerpcspe \
|
||||
| pru \
|
||||
| pyramid \
|
||||
| riscv | riscv32 | riscv32be | riscv64 | riscv64be \
|
||||
| riscv | riscv32 | riscv64 \
|
||||
| rl78 | romp | rs6000 | rx \
|
||||
| s390 | s390x \
|
||||
| score \
|
||||
@@ -1683,14 +1682,11 @@ fi
|
||||
|
||||
# Now, validate our (potentially fixed-up) OS.
|
||||
case $os in
|
||||
# Sometimes we do "kernel-libc", so those need to count as OSes.
|
||||
# Sometimes we do "kernel-abi", so those need to count as OSes.
|
||||
musl* | newlib* | uclibc*)
|
||||
;;
|
||||
# Likewise for "kernel-abi"
|
||||
eabi* | gnueabi*)
|
||||
;;
|
||||
# VxWorks passes extra cpu info in the 4th filed.
|
||||
simlinux | simwindows | spe)
|
||||
# Likewise for "kernel-libc"
|
||||
eabi | eabihf | gnueabi | gnueabihf)
|
||||
;;
|
||||
# Now accept the basic system types.
|
||||
# The portable systems comes first.
|
||||
@@ -1754,8 +1750,6 @@ case $kernel-$os in
|
||||
;;
|
||||
kfreebsd*-gnu* | kopensolaris*-gnu*)
|
||||
;;
|
||||
vxworks-simlinux | vxworks-simwindows | vxworks-spe)
|
||||
;;
|
||||
nto-qnx*)
|
||||
;;
|
||||
os2-emx)
|
||||
|
||||
169
configure.ac
169
configure.ac
@@ -1,4 +1,4 @@
|
||||
AC_INIT([nix],[m4_esyscmd(bash -c "echo -n $(cat ./.version)$VERSION_SUFFIX")])
|
||||
AC_INIT(nix, m4_esyscmd([bash -c "echo -n $(cat ./.version)$VERSION_SUFFIX"]))
|
||||
AC_CONFIG_MACRO_DIRS([m4])
|
||||
AC_CONFIG_SRCDIR(README.md)
|
||||
AC_CONFIG_AUX_DIR(config)
|
||||
@@ -9,7 +9,8 @@ AC_PROG_SED
|
||||
AC_CANONICAL_HOST
|
||||
AC_MSG_CHECKING([for the canonical Nix system name])
|
||||
|
||||
AC_ARG_WITH(system, AS_HELP_STRING([--with-system=SYSTEM],[Platform identifier (e.g., `i686-linux').]),
|
||||
AC_ARG_WITH(system, AC_HELP_STRING([--with-system=SYSTEM],
|
||||
[Platform identifier (e.g., `i686-linux').]),
|
||||
[system=$withval],
|
||||
[case "$host_cpu" in
|
||||
i*86)
|
||||
@@ -32,6 +33,14 @@ AC_ARG_WITH(system, AS_HELP_STRING([--with-system=SYSTEM],[Platform identifier (
|
||||
system="$machine_name-`echo $host_os | "$SED" -e's/@<:@0-9.@:>@*$//g'`";;
|
||||
esac])
|
||||
|
||||
sys_name=$(uname -s | tr 'A-Z ' 'a-z_')
|
||||
|
||||
case $sys_name in
|
||||
cygwin*)
|
||||
sys_name=cygwin
|
||||
;;
|
||||
esac
|
||||
|
||||
AC_MSG_RESULT($system)
|
||||
AC_SUBST(system)
|
||||
AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier ('cpu-os')])
|
||||
@@ -41,6 +50,8 @@ AC_DEFINE_UNQUOTED(SYSTEM, ["$system"], [platform identifier ('cpu-os')])
|
||||
test "$localstatedir" = '${prefix}/var' && localstatedir=/nix/var
|
||||
|
||||
|
||||
CFLAGS=
|
||||
CXXFLAGS=
|
||||
AC_PROG_CC
|
||||
AC_PROG_CXX
|
||||
AC_PROG_CPP
|
||||
@@ -53,12 +64,10 @@ AC_SYS_LARGEFILE
|
||||
|
||||
# Solaris-specific stuff.
|
||||
AC_STRUCT_DIRENT_D_TYPE
|
||||
case "$host_os" in
|
||||
solaris*)
|
||||
if test "$sys_name" = sunos; then
|
||||
# Solaris requires -lsocket -lnsl for network functions
|
||||
LDFLAGS="-lsocket -lnsl $LDFLAGS"
|
||||
;;
|
||||
esac
|
||||
LIBS="-lsocket -lnsl $LIBS"
|
||||
fi
|
||||
|
||||
|
||||
# Check for pubsetbuf.
|
||||
@@ -118,7 +127,8 @@ NEED_PROG(jq, jq)
|
||||
AC_SUBST(coreutils, [$(dirname $(type -p cat))])
|
||||
|
||||
|
||||
AC_ARG_WITH(store-dir, AS_HELP_STRING([--with-store-dir=PATH],[path of the Nix store (defaults to /nix/store)]),
|
||||
AC_ARG_WITH(store-dir, AC_HELP_STRING([--with-store-dir=PATH],
|
||||
[path of the Nix store (defaults to /nix/store)]),
|
||||
storedir=$withval, storedir='/nix/store')
|
||||
AC_SUBST(storedir)
|
||||
|
||||
@@ -142,26 +152,13 @@ int main() {
|
||||
}]])], GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=no, GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC=yes)
|
||||
AC_MSG_RESULT($GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC)
|
||||
if test "x$GCC_ATOMIC_BUILTINS_NEED_LIBATOMIC" = xyes; then
|
||||
LDFLAGS="-latomic $LDFLAGS"
|
||||
fi
|
||||
|
||||
# LTO is currently broken with clang for unknown reasons; ld segfaults in the llvm plugin
|
||||
AC_ARG_ENABLE(lto, AS_HELP_STRING([--enable-lto],[Enable LTO (only supported with GCC) [default=no]]),
|
||||
lto=$enableval, lto=no)
|
||||
if test "$lto" = yes; then
|
||||
if $CXX --version | grep -q GCC; then
|
||||
AC_SUBST(CXXLTO, [-flto=jobserver])
|
||||
else
|
||||
echo "error: LTO is only supported with GCC at the moment" >&2
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
AC_SUBST(CXXLTO, [""])
|
||||
LIBS="-latomic $LIBS"
|
||||
fi
|
||||
|
||||
PKG_PROG_PKG_CONFIG
|
||||
|
||||
AC_ARG_ENABLE(shared, AS_HELP_STRING([--enable-shared],[Build shared libraries for Nix [default=yes]]),
|
||||
AC_ARG_ENABLE(shared, AC_HELP_STRING([--enable-shared],
|
||||
[Build shared libraries for Nix [default=yes]]),
|
||||
shared=$enableval, shared=yes)
|
||||
if test "$shared" = yes; then
|
||||
AC_SUBST(BUILD_SHARED_LIBS, 1, [Whether to build shared libraries.])
|
||||
@@ -175,7 +172,12 @@ fi
|
||||
PKG_CHECK_MODULES([OPENSSL], [libcrypto], [CXXFLAGS="$OPENSSL_CFLAGS $CXXFLAGS"])
|
||||
|
||||
|
||||
# Look for libarchive.
|
||||
# Look for libbz2, a required dependency.
|
||||
AC_CHECK_LIB([bz2], [BZ2_bzWriteOpen], [true],
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://sourceware.org/bzip2/.])])
|
||||
AC_CHECK_HEADERS([bzlib.h], [true],
|
||||
[AC_MSG_ERROR([Nix requires libbz2, which is part of bzip2. See https://sourceware.org/bzip2/.])])
|
||||
# Checks for libarchive
|
||||
PKG_CHECK_MODULES([LIBARCHIVE], [libarchive >= 3.1.2], [CXXFLAGS="$LIBARCHIVE_CFLAGS $CXXFLAGS"])
|
||||
# Workaround until https://github.com/libarchive/libarchive/issues/1446 is fixed
|
||||
if test "$shared" != yes; then
|
||||
@@ -200,55 +202,48 @@ PKG_CHECK_MODULES([EDITLINE], [libeditline], [CXXFLAGS="$EDITLINE_CFLAGS $CXXFLA
|
||||
[AC_MSG_ERROR([Nix requires libeditline; it was not found via pkg-config, but via its header, but required functions do not work. Maybe it is too old? >= 1.14 is required.])])
|
||||
])
|
||||
|
||||
# Look for libsodium.
|
||||
# Look for libsodium, an optional dependency.
|
||||
PKG_CHECK_MODULES([SODIUM], [libsodium], [CXXFLAGS="$SODIUM_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for liblzma, a required dependency.
|
||||
PKG_CHECK_MODULES([LIBLZMA], [liblzma], [CXXFLAGS="$LIBLZMA_CFLAGS $CXXFLAGS"])
|
||||
AC_CHECK_LIB([lzma], [lzma_stream_encoder_mt],
|
||||
[AC_DEFINE([HAVE_LZMA_MT], [1], [xz multithreaded compression support])])
|
||||
|
||||
# Look for zlib, a required dependency.
|
||||
PKG_CHECK_MODULES([ZLIB], [zlib], [CXXFLAGS="$ZLIB_CFLAGS $CXXFLAGS"])
|
||||
AC_CHECK_HEADER([zlib.h],[:],[AC_MSG_ERROR([could not find the zlib.h header])])
|
||||
LDFLAGS="-lz $LDFLAGS"
|
||||
|
||||
# Look for libbrotli{enc,dec}.
|
||||
PKG_CHECK_MODULES([LIBBROTLI], [libbrotlienc libbrotlidec], [CXXFLAGS="$LIBBROTLI_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Look for libcpuid.
|
||||
have_libcpuid=
|
||||
if test "$machine_name" = "x86_64"; then
|
||||
AC_ARG_ENABLE([cpuid],
|
||||
AS_HELP_STRING([--disable-cpuid], [Do not determine microarchitecture levels with libcpuid (relevant to x86_64 only)]))
|
||||
if test "x$enable_cpuid" != "xno"; then
|
||||
PKG_CHECK_MODULES([LIBCPUID], [libcpuid],
|
||||
[CXXFLAGS="$LIBCPUID_CFLAGS $CXXFLAGS"
|
||||
have_libcpuid=1
|
||||
AC_DEFINE([HAVE_LIBCPUID], [1], [Use libcpuid])]
|
||||
)
|
||||
fi
|
||||
fi
|
||||
AC_SUBST(HAVE_LIBCPUID, [$have_libcpuid])
|
||||
|
||||
|
||||
# Look for libseccomp, required for Linux sandboxing.
|
||||
case "$host_os" in
|
||||
linux*)
|
||||
AC_ARG_ENABLE([seccomp-sandboxing],
|
||||
AS_HELP_STRING([--disable-seccomp-sandboxing],[Don't build support for seccomp sandboxing (only recommended if your arch doesn't support libseccomp yet!)
|
||||
]))
|
||||
if test "x$enable_seccomp_sandboxing" != "xno"; then
|
||||
PKG_CHECK_MODULES([LIBSECCOMP], [libseccomp],
|
||||
[CXXFLAGS="$LIBSECCOMP_CFLAGS $CXXFLAGS"])
|
||||
have_seccomp=1
|
||||
AC_DEFINE([HAVE_SECCOMP], [1], [Whether seccomp is available and should be used for sandboxing.])
|
||||
else
|
||||
have_seccomp=
|
||||
fi
|
||||
;;
|
||||
*)
|
||||
if test "$sys_name" = linux; then
|
||||
AC_ARG_ENABLE([seccomp-sandboxing],
|
||||
AC_HELP_STRING([--disable-seccomp-sandboxing],
|
||||
[Don't build support for seccomp sandboxing (only recommended if your arch doesn't support libseccomp yet!)]
|
||||
))
|
||||
if test "x$enable_seccomp_sandboxing" != "xno"; then
|
||||
PKG_CHECK_MODULES([LIBSECCOMP], [libseccomp],
|
||||
[CXXFLAGS="$LIBSECCOMP_CFLAGS $CXXFLAGS"])
|
||||
have_seccomp=1
|
||||
AC_DEFINE([HAVE_SECCOMP], [1], [Whether seccomp is available and should be used for sandboxing.])
|
||||
else
|
||||
have_seccomp=
|
||||
;;
|
||||
esac
|
||||
fi
|
||||
else
|
||||
have_seccomp=
|
||||
fi
|
||||
AC_SUBST(HAVE_SECCOMP, [$have_seccomp])
|
||||
|
||||
|
||||
# Look for aws-cpp-sdk-s3.
|
||||
AC_LANG_PUSH(C++)
|
||||
AC_CHECK_HEADERS([aws/s3/S3Client.h],
|
||||
[AC_DEFINE([ENABLE_S3], [1], [Whether to enable S3 support via aws-sdk-cpp.]) enable_s3=1],
|
||||
[AC_DEFINE([ENABLE_S3], [0], [Whether to enable S3 support via aws-sdk-cpp.]) enable_s3=])
|
||||
[AC_DEFINE([ENABLE_S3], [1], [Whether to enable S3 support via aws-sdk-cpp.])
|
||||
enable_s3=1], [enable_s3=])
|
||||
AC_SUBST(ENABLE_S3, [$enable_s3])
|
||||
AC_LANG_POP(C++)
|
||||
|
||||
@@ -261,7 +256,8 @@ fi
|
||||
|
||||
|
||||
# Whether to use the Boehm garbage collector.
|
||||
AC_ARG_ENABLE(gc, AS_HELP_STRING([--enable-gc],[enable garbage collection in the Nix expression evaluator (requires Boehm GC) [default=yes]]),
|
||||
AC_ARG_ENABLE(gc, AC_HELP_STRING([--enable-gc],
|
||||
[enable garbage collection in the Nix expression evaluator (requires Boehm GC) [default=yes]]),
|
||||
gc=$enableval, gc=yes)
|
||||
if test "$gc" = yes; then
|
||||
PKG_CHECK_MODULES([BDW_GC], [bdw-gc])
|
||||
@@ -274,17 +270,12 @@ fi
|
||||
PKG_CHECK_MODULES([GTEST], [gtest_main])
|
||||
|
||||
|
||||
# Look for nlohmann/json.
|
||||
PKG_CHECK_MODULES([NLOHMANN_JSON], [nlohmann_json >= 3.9])
|
||||
|
||||
|
||||
# documentation generation switch
|
||||
AC_ARG_ENABLE(doc-gen, AS_HELP_STRING([--disable-doc-gen],[disable documentation generation]),
|
||||
AC_ARG_ENABLE(doc-gen, AC_HELP_STRING([--disable-doc-gen],
|
||||
[disable documentation generation]),
|
||||
doc_generate=$enableval, doc_generate=yes)
|
||||
AC_SUBST(doc_generate)
|
||||
|
||||
# Look for lowdown library.
|
||||
PKG_CHECK_MODULES([LOWDOWN], [lowdown >= 0.9.0], [CXXFLAGS="$LOWDOWN_CFLAGS $CXXFLAGS"])
|
||||
|
||||
# Setuid installations.
|
||||
AC_CHECK_FUNCS([setresuid setreuid lchown])
|
||||
@@ -294,28 +285,28 @@ AC_CHECK_FUNCS([setresuid setreuid lchown])
|
||||
AC_CHECK_FUNCS([strsignal posix_fallocate sysconf])
|
||||
|
||||
|
||||
AC_ARG_WITH(sandbox-shell, AS_HELP_STRING([--with-sandbox-shell=PATH],[path of a statically-linked shell to use as /bin/sh in sandboxes]),
|
||||
# This is needed if bzip2 is a static library, and the Nix libraries
|
||||
# are dynamic.
|
||||
if test "$(uname)" = "Darwin"; then
|
||||
LDFLAGS="-all_load $LDFLAGS"
|
||||
fi
|
||||
|
||||
|
||||
# Do we have GNU tar?
|
||||
AC_MSG_CHECKING([if you have a recent GNU tar])
|
||||
if $tar --version 2> /dev/null | grep -q GNU && tar cvf /dev/null --warning=no-timestamp ./config.log > /dev/null; then
|
||||
AC_MSG_RESULT(yes)
|
||||
tarFlags="--warning=no-timestamp"
|
||||
else
|
||||
AC_MSG_RESULT(no)
|
||||
fi
|
||||
AC_SUBST(tarFlags)
|
||||
|
||||
|
||||
AC_ARG_WITH(sandbox-shell, AC_HELP_STRING([--with-sandbox-shell=PATH],
|
||||
[path of a statically-linked shell to use as /bin/sh in sandboxes]),
|
||||
sandbox_shell=$withval)
|
||||
AC_SUBST(sandbox_shell)
|
||||
if test ${cross_compiling:-no} = no && ! test -z ${sandbox_shell+x}; then
|
||||
AC_MSG_CHECKING([whether sandbox-shell has the standalone feature])
|
||||
# busybox shell sometimes allows executing other busybox applets,
|
||||
# even if they are not in the path, breaking our sandbox
|
||||
if PATH= $sandbox_shell -c "busybox" 2>&1 | grep -qv "not found"; then
|
||||
AC_MSG_RESULT(enabled)
|
||||
AC_MSG_ERROR([Please disable busybox FEATURE_SH_STANDALONE])
|
||||
else
|
||||
AC_MSG_RESULT(disabled)
|
||||
fi
|
||||
fi
|
||||
|
||||
AC_ARG_ENABLE(embedded-sandbox-shell, AS_HELP_STRING([--enable-embedded-sandbox-shell],[include the sandbox shell in the Nix binary [default=no]]),
|
||||
embedded_sandbox_shell=$enableval, embedded_sandbox_shell=no)
|
||||
AC_SUBST(embedded_sandbox_shell)
|
||||
if test "$embedded_sandbox_shell" = yes; then
|
||||
AC_DEFINE(HAVE_EMBEDDED_SANDBOX_SHELL, 1, [Include the sandbox shell in the Nix binary.])
|
||||
fi
|
||||
|
||||
|
||||
# Expand all variables in config.status.
|
||||
test "$prefix" = NONE && prefix=$ac_default_prefix
|
||||
@@ -328,6 +319,6 @@ done
|
||||
|
||||
rm -f Makefile.config
|
||||
|
||||
AC_CONFIG_HEADERS([config.h])
|
||||
AC_CONFIG_HEADER([config.h])
|
||||
AC_CONFIG_FILES([])
|
||||
AC_OUTPUT
|
||||
|
||||
@@ -1,3 +1,3 @@
|
||||
(import (fetchTarball "https://github.com/edolstra/flake-compat/archive/master.tar.gz") {
|
||||
(import (fetchTarball https://github.com/edolstra/flake-compat/archive/master.tar.gz) {
|
||||
src = ./.;
|
||||
}).defaultNix
|
||||
|
||||
@@ -1,31 +0,0 @@
|
||||
"\\[\\]\\{#(?<anchor>[^\\}]+?)\\}" as $empty_anchor_regex |
|
||||
"\\[(?<text>[^\\]]+?)\\]\\{#(?<anchor>[^\\}]+?)\\}" as $anchor_regex |
|
||||
|
||||
|
||||
def transform_anchors_html:
|
||||
. | gsub($empty_anchor_regex; "<a name=\"" + .anchor + "\"></a>")
|
||||
| gsub($anchor_regex; "<a href=\"#" + .anchor + "\" id=\"" + .anchor + "\">" + .text + "</a>");
|
||||
|
||||
|
||||
def transform_anchors_strip:
|
||||
. | gsub($empty_anchor_regex; "")
|
||||
| gsub($anchor_regex; .text);
|
||||
|
||||
|
||||
def map_contents_recursively(transformer):
|
||||
. + {
|
||||
Chapter: (.Chapter + {
|
||||
content: .Chapter.content | transformer,
|
||||
sub_items: .Chapter.sub_items | map(map_contents_recursively(transformer)),
|
||||
}),
|
||||
};
|
||||
|
||||
|
||||
def process_command:
|
||||
.[0] as $context |
|
||||
.[1] as $body |
|
||||
$body + {
|
||||
sections: $body.sections | map(map_contents_recursively(if $context.renderer == "html" then transform_anchors_html else transform_anchors_strip end)),
|
||||
};
|
||||
|
||||
process_command
|
||||
@@ -1,21 +1,2 @@
|
||||
[book]
|
||||
title = "Nix Reference Manual"
|
||||
|
||||
[output.html]
|
||||
additional-css = ["custom.css"]
|
||||
additional-js = ["redirects.js"]
|
||||
edit-url-template = "https://github.com/NixOS/nix/tree/master/doc/manual/{path}"
|
||||
git-repository-url = "https://github.com/NixOS/nix"
|
||||
|
||||
[preprocessor.anchors]
|
||||
renderers = ["html"]
|
||||
command = "jq --from-file doc/manual/anchors.jq"
|
||||
|
||||
[output.linkcheck]
|
||||
# no Internet during the build (in the sandbox)
|
||||
follow-web-links = false
|
||||
|
||||
# mdbook-linkcheck does not understand [foo]{#bar} style links, resulting in
|
||||
# excessive "Potential incomplete link" warnings. No other kind of warning was
|
||||
# produced at the time of writing.
|
||||
warning-policy = "ignore"
|
||||
|
||||
@@ -1,20 +1,14 @@
|
||||
builtinsDump:
|
||||
let
|
||||
showBuiltin = name:
|
||||
let
|
||||
inherit (builtinsDump.${name}) doc args;
|
||||
in
|
||||
''
|
||||
<dt id="builtins-${name}">
|
||||
<a href="#builtins-${name}"><code>${name} ${listArgs args}</code></a>
|
||||
</dt>
|
||||
<dd>
|
||||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
${doc}
|
||||
builtins:
|
||||
|
||||
</dd>
|
||||
'';
|
||||
listArgs = args: builtins.concatStringsSep " " (map (s: "<var>${s}</var>") args);
|
||||
in
|
||||
with builtins; concatStringsSep "\n" (map showBuiltin (attrNames builtinsDump))
|
||||
concatStrings (map
|
||||
(name:
|
||||
let builtin = builtins.${name}; in
|
||||
" - `builtins.${name}` " + concatStringsSep " " (map (s: "*${s}*") builtin.args)
|
||||
+ " \n\n"
|
||||
+ concatStrings (map (s: " ${s}\n") (splitLines builtin.doc)) + "\n\n"
|
||||
)
|
||||
(attrNames builtins))
|
||||
|
||||
|
||||
@@ -1,115 +1,92 @@
|
||||
{ toplevel }:
|
||||
command:
|
||||
|
||||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
let
|
||||
|
||||
showCommand = { command, details, filename, toplevel }:
|
||||
let
|
||||
result = ''
|
||||
> **Warning** \
|
||||
> This program is **experimental** and its interface is subject to change.
|
||||
|
||||
# Name
|
||||
|
||||
`${command}` - ${details.description}
|
||||
|
||||
# Synopsis
|
||||
|
||||
${showSynopsis command details.args}
|
||||
|
||||
${maybeSubcommands}
|
||||
|
||||
${maybeDocumentation}
|
||||
|
||||
${maybeOptions}
|
||||
'';
|
||||
showSynopsis = command: args:
|
||||
let
|
||||
showArgument = arg: "*${arg.label}*" + (if arg ? arity then "" else "...");
|
||||
arguments = concatStringsSep " " (map showArgument args);
|
||||
in ''
|
||||
`${command}` [*option*...] ${arguments}
|
||||
'';
|
||||
maybeSubcommands = if details ? commands && details.commands != {}
|
||||
then ''
|
||||
where *subcommand* is one of the following:
|
||||
|
||||
${subcommands}
|
||||
''
|
||||
else "";
|
||||
subcommands = if length categories > 1
|
||||
then listCategories
|
||||
else listSubcommands details.commands;
|
||||
categories = sort (x: y: x.id < y.id) (unique (map (cmd: cmd.category) (attrValues details.commands)));
|
||||
listCategories = concatStrings (map showCategory categories);
|
||||
showCategory = cat: ''
|
||||
**${toString cat.description}:**
|
||||
|
||||
${listSubcommands (filterAttrs (n: v: v.category == cat) details.commands)}
|
||||
'';
|
||||
listSubcommands = cmds: concatStrings (attrValues (mapAttrs showSubcommand cmds));
|
||||
showSubcommand = name: subcmd: ''
|
||||
* [`${command} ${name}`](./${appendName filename name}.md) - ${subcmd.description}
|
||||
'';
|
||||
maybeDocumentation = if details ? doc then details.doc else "";
|
||||
maybeOptions = if details.flags == {} then "" else ''
|
||||
# Options
|
||||
|
||||
${showOptions details.flags toplevel.flags}
|
||||
'';
|
||||
showOptions = options: commonOptions:
|
||||
let
|
||||
allOptions = options // commonOptions;
|
||||
showCategory = cat: ''
|
||||
${if cat != "" then "**${cat}:**" else ""}
|
||||
|
||||
${listOptions (filterAttrs (n: v: v.category == cat) allOptions)}
|
||||
'';
|
||||
listOptions = opts: concatStringsSep "\n" (attrValues (mapAttrs showOption opts));
|
||||
showOption = name: option:
|
||||
let
|
||||
shortName = if option ? shortName then "/ `-${option.shortName}`" else "";
|
||||
labels = if option ? labels then (concatStringsSep " " (map (s: "*${s}*") option.labels)) else "";
|
||||
in trim ''
|
||||
- `--${name}` ${shortName} ${labels}
|
||||
|
||||
${option.description}
|
||||
'';
|
||||
categories = sort builtins.lessThan (unique (map (cmd: cmd.category) (attrValues allOptions)));
|
||||
in concatStrings (map showCategory categories);
|
||||
in squash result;
|
||||
showCommand =
|
||||
{ command, def, filename }:
|
||||
"# Name\n\n"
|
||||
+ "`${command}` - ${def.description}\n\n"
|
||||
+ "# Synopsis\n\n"
|
||||
+ showSynopsis { inherit command; args = def.args; }
|
||||
+ (if def.commands or {} != {}
|
||||
then
|
||||
let
|
||||
categories = sort (x: y: x.id < y.id) (unique (map (cmd: cmd.category) (attrValues def.commands)));
|
||||
listCommands = cmds:
|
||||
concatStrings (map (name:
|
||||
"* [`${command} ${name}`](./${appendName filename name}.md) - ${cmds.${name}.description}\n")
|
||||
(attrNames cmds));
|
||||
in
|
||||
"where *subcommand* is one of the following:\n\n"
|
||||
# FIXME: group by category
|
||||
+ (if length categories > 1
|
||||
then
|
||||
concatStrings (map
|
||||
(cat:
|
||||
"**${toString cat.description}:**\n\n"
|
||||
+ listCommands (filterAttrs (n: v: v.category == cat) def.commands)
|
||||
+ "\n"
|
||||
) categories)
|
||||
+ "\n"
|
||||
else
|
||||
listCommands def.commands
|
||||
+ "\n")
|
||||
else "")
|
||||
+ (if def ? doc
|
||||
then def.doc + "\n\n"
|
||||
else "")
|
||||
+ (let s = showOptions def.flags; in
|
||||
if s != ""
|
||||
then "# Options\n\n${s}"
|
||||
else "")
|
||||
;
|
||||
|
||||
appendName = filename: name: (if filename == "nix" then "nix3" else filename) + "-" + name;
|
||||
|
||||
processCommand = { command, details, filename, toplevel }:
|
||||
showOptions = flags:
|
||||
let
|
||||
cmd = {
|
||||
inherit command;
|
||||
name = filename + ".md";
|
||||
value = showCommand { inherit command details filename toplevel; };
|
||||
};
|
||||
subcommand = subCmd: processCommand {
|
||||
command = command + " " + subCmd;
|
||||
details = details.commands.${subCmd};
|
||||
filename = appendName filename subCmd;
|
||||
inherit toplevel;
|
||||
};
|
||||
in [ cmd ] ++ concatMap subcommand (attrNames details.commands or {});
|
||||
categories = sort builtins.lessThan (unique (map (cmd: cmd.category) (attrValues flags)));
|
||||
in
|
||||
concatStrings (map
|
||||
(cat:
|
||||
(if cat != ""
|
||||
then "**${cat}:**\n\n"
|
||||
else "")
|
||||
+ concatStrings
|
||||
(map (longName:
|
||||
let
|
||||
flag = flags.${longName};
|
||||
in
|
||||
" - `--${longName}`"
|
||||
+ (if flag ? shortName then " / `-${flag.shortName}`" else "")
|
||||
+ (if flag ? labels then " " + (concatStringsSep " " (map (s: "*${s}*") flag.labels)) else "")
|
||||
+ " \n"
|
||||
+ " " + flag.description + "\n\n"
|
||||
) (attrNames (filterAttrs (n: v: v.category == cat) flags))))
|
||||
categories);
|
||||
|
||||
parsedToplevel = builtins.fromJSON toplevel;
|
||||
|
||||
manpages = processCommand {
|
||||
command = "nix";
|
||||
details = parsedToplevel;
|
||||
filename = "nix";
|
||||
toplevel = parsedToplevel;
|
||||
};
|
||||
showSynopsis =
|
||||
{ command, args }:
|
||||
"`${command}` [*option*...] ${concatStringsSep " "
|
||||
(map (arg: "*${arg.label}*" + (if arg ? arity then "" else "...")) args)}\n\n";
|
||||
|
||||
tableOfContents = let
|
||||
showEntry = page:
|
||||
" - [${page.command}](command-ref/new-cli/${page.name})";
|
||||
in concatStringsSep "\n" (map showEntry manpages) + "\n";
|
||||
processCommand = { command, def, filename }:
|
||||
[ { name = filename + ".md"; value = showCommand { inherit command def filename; }; inherit command; } ]
|
||||
++ concatMap
|
||||
(name: processCommand {
|
||||
filename = appendName filename name;
|
||||
command = command + " " + name;
|
||||
def = def.commands.${name};
|
||||
})
|
||||
(attrNames def.commands or {});
|
||||
|
||||
in (listToAttrs manpages) // { "SUMMARY.md" = tableOfContents; }
|
||||
in
|
||||
|
||||
let
|
||||
manpages = processCommand { filename = "nix"; command = "nix"; def = command; };
|
||||
summary = concatStrings (map (manpage: " - [${manpage.command}](command-ref/new-cli/${manpage.name})\n") manpages);
|
||||
in
|
||||
(listToAttrs manpages) // { "SUMMARY.md" = summary; }
|
||||
|
||||
@@ -1,41 +1,26 @@
|
||||
let
|
||||
inherit (builtins) attrNames concatStringsSep isAttrs isBool;
|
||||
inherit (import ./utils.nix) concatStrings squash splitLines;
|
||||
in
|
||||
with builtins;
|
||||
with import ./utils.nix;
|
||||
|
||||
optionsInfo:
|
||||
let
|
||||
showOption = name:
|
||||
let
|
||||
inherit (optionsInfo.${name}) description documentDefault defaultValue aliases;
|
||||
result = squash ''
|
||||
- <span id="conf-${name}">[`${name}`](#conf-${name})</span>
|
||||
options:
|
||||
|
||||
${indent " " body}
|
||||
'';
|
||||
# separate body to cleanly handle indentation
|
||||
body = ''
|
||||
${description}
|
||||
|
||||
**Default:** ${showDefault documentDefault defaultValue}
|
||||
|
||||
${showAliases aliases}
|
||||
'';
|
||||
showDefault = documentDefault: defaultValue:
|
||||
if documentDefault then
|
||||
# a StringMap value type is specified as a string, but
|
||||
# this shows the value type. The empty stringmap is `null` in
|
||||
# JSON, but that converts to `{ }` here.
|
||||
if defaultValue == "" || defaultValue == [] || isAttrs defaultValue
|
||||
then "*empty*"
|
||||
else if isBool defaultValue then
|
||||
if defaultValue then "`true`" else "`false`"
|
||||
else "`${toString defaultValue}`"
|
||||
else "*machine-specific*";
|
||||
showAliases = aliases:
|
||||
if aliases == [] then "" else
|
||||
"**Deprecated alias:** ${(concatStringsSep ", " (map (s: "`${s}`") aliases))}";
|
||||
indent = prefix: s:
|
||||
concatStringsSep "\n" (map (x: if x == "" then x else "${prefix}${x}") (splitLines s));
|
||||
in result;
|
||||
in concatStrings (map showOption (attrNames optionsInfo))
|
||||
concatStrings (map
|
||||
(name:
|
||||
let option = options.${name}; in
|
||||
" - `${name}` \n\n"
|
||||
+ concatStrings (map (s: " ${s}\n") (splitLines option.description)) + "\n\n"
|
||||
+ " **Default:** " + (
|
||||
if option.value == "" || option.value == []
|
||||
then "*empty*"
|
||||
else if isBool option.value
|
||||
then (if option.value then "`true`" else "`false`")
|
||||
else
|
||||
# n.b. a StringMap value type is specified as a string, but
|
||||
# this shows the value type. The empty stringmap is "null" in
|
||||
# JSON, but that converts to "{ }" here.
|
||||
(if isAttrs option.value then "`\"\"`"
|
||||
else "`" + toString option.value + "`")) + "\n\n"
|
||||
+ (if option.aliases != []
|
||||
then " **Deprecated alias:** " + (concatStringsSep ", " (map (s: "`${s}`") option.aliases)) + "\n\n"
|
||||
else "")
|
||||
)
|
||||
(attrNames options))
|
||||
|
||||
@@ -1,8 +1,6 @@
|
||||
ifeq ($(doc_generate),yes)
|
||||
|
||||
MANUAL_SRCS := \
|
||||
$(call rwildcard, $(d)/src, *.md) \
|
||||
$(call rwildcard, $(d)/src, */*.md)
|
||||
MANUAL_SRCS := $(call rwildcard, $(d)/src, *.md)
|
||||
|
||||
# Generate man pages.
|
||||
man-pages := $(foreach n, \
|
||||
@@ -16,32 +14,30 @@ man-pages := $(foreach n, \
|
||||
clean-files += $(d)/*.1 $(d)/*.5 $(d)/*.8
|
||||
|
||||
# Provide a dummy environment for nix, so that it will not access files outside the macOS sandbox.
|
||||
# Set cores to 0 because otherwise nix show-config resolves the cores based on the current machine
|
||||
dummy-env = env -i \
|
||||
HOME=/dummy \
|
||||
NIX_CONF_DIR=/dummy \
|
||||
NIX_SSL_CERT_FILE=/dummy/no-ca-bundle.crt \
|
||||
NIX_STATE_DIR=/dummy \
|
||||
NIX_CONFIG='cores = 0'
|
||||
NIX_STATE_DIR=/dummy
|
||||
|
||||
nix-eval = $(dummy-env) $(bindir)/nix eval --experimental-features nix-command -I nix/corepkgs=corepkgs --store dummy:// --impure --raw
|
||||
|
||||
$(d)/%.1: $(d)/src/command-ref/%.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .1)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man --nroff-nolinks -M section=1 $^.tmp -o $@
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/%.8: $(d)/src/command-ref/%.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .8)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man --nroff-nolinks -M section=8 $^.tmp -o $@
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/nix.conf.5: $(d)/src/command-ref/conf-file.md
|
||||
@printf "Title: %s\n\n" "$$(basename $@ .5)" > $^.tmp
|
||||
@cat $^ >> $^.tmp
|
||||
$(trace-gen) lowdown -sT man --nroff-nolinks -M section=5 $^.tmp -o $@
|
||||
$(trace-gen) lowdown -sT man $^.tmp -o $@
|
||||
@rm $^.tmp
|
||||
|
||||
$(d)/src/SUMMARY.md: $(d)/src/SUMMARY.md.in $(d)/src/command-ref/new-cli
|
||||
@@ -50,16 +46,11 @@ $(d)/src/SUMMARY.md: $(d)/src/SUMMARY.md.in $(d)/src/command-ref/new-cli
|
||||
|
||||
$(d)/src/command-ref/new-cli: $(d)/nix.json $(d)/generate-manpage.nix $(bindir)/nix
|
||||
@rm -rf $@
|
||||
$(trace-gen) $(nix-eval) --write-to $@.tmp --expr 'import doc/manual/generate-manpage.nix { toplevel = builtins.readFile $<; }'
|
||||
# @docroot@: https://nixos.org/manual/nix/unstable/contributing/hacking.html#docroot-variable
|
||||
$(trace-gen) sed -i $@.tmp/*.md -e 's^@docroot@^../..^g'
|
||||
@mv $@.tmp $@
|
||||
$(trace-gen) $(nix-eval) --write-to $@ --expr 'import doc/manual/generate-manpage.nix (builtins.fromJSON (builtins.readFile $<))'
|
||||
|
||||
$(d)/src/command-ref/conf-file.md: $(d)/conf-file.json $(d)/generate-options.nix $(d)/src/command-ref/conf-file-prefix.md $(bindir)/nix
|
||||
@cat doc/manual/src/command-ref/conf-file-prefix.md > $@.tmp
|
||||
# @docroot@: https://nixos.org/manual/nix/unstable/contributing/hacking.html#docroot-variable
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-options.nix (builtins.fromJSON (builtins.readFile $<))' \
|
||||
| sed -e 's^@docroot@^..^g'>> $@.tmp
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-options.nix (builtins.fromJSON (builtins.readFile $<))' >> $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/nix.json: $(bindir)/nix
|
||||
@@ -70,12 +61,9 @@ $(d)/conf-file.json: $(bindir)/nix
|
||||
$(trace-gen) $(dummy-env) $(bindir)/nix show-config --json --experimental-features nix-command > $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/src/language/builtins.md: $(d)/builtins.json $(d)/generate-builtins.nix $(d)/src/language/builtins-prefix.md $(bindir)/nix
|
||||
@cat doc/manual/src/language/builtins-prefix.md > $@.tmp
|
||||
# @docroot@: https://nixos.org/manual/nix/unstable/contributing/hacking.html#docroot-variable
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-builtins.nix (builtins.fromJSON (builtins.readFile $<))' \
|
||||
| sed -e 's^@docroot@^..^g' >> $@.tmp
|
||||
@cat doc/manual/src/language/builtins-suffix.md >> $@.tmp
|
||||
$(d)/src/expressions/builtins.md: $(d)/builtins.json $(d)/generate-builtins.nix $(d)/src/expressions/builtins-prefix.md $(bindir)/nix
|
||||
@cat doc/manual/src/expressions/builtins-prefix.md > $@.tmp
|
||||
$(trace-gen) $(nix-eval) --expr 'import doc/manual/generate-builtins.nix (builtins.fromJSON (builtins.readFile $<))' >> $@.tmp
|
||||
@mv $@.tmp $@
|
||||
|
||||
$(d)/builtins.json: $(bindir)/nix
|
||||
@@ -83,38 +71,20 @@ $(d)/builtins.json: $(bindir)/nix
|
||||
@mv $@.tmp $@
|
||||
|
||||
# Generate the HTML manual.
|
||||
html: $(docdir)/manual/index.html
|
||||
install: $(docdir)/manual/index.html
|
||||
|
||||
# Generate 'nix' manpages.
|
||||
install: $(mandir)/man1/nix3-manpages
|
||||
man: doc/manual/generated/man1/nix3-manpages
|
||||
all: doc/manual/generated/man1/nix3-manpages
|
||||
|
||||
$(mandir)/man1/nix3-manpages: doc/manual/generated/man1/nix3-manpages
|
||||
@mkdir -p $(DESTDIR)$$(dirname $@)
|
||||
$(trace-install) install -m 0644 $$(dirname $<)/* $(DESTDIR)$$(dirname $@)
|
||||
|
||||
doc/manual/generated/man1/nix3-manpages: $(d)/src/command-ref/new-cli
|
||||
@mkdir -p $(DESTDIR)$$(dirname $@)
|
||||
install: $(d)/src/command-ref/new-cli
|
||||
$(trace-gen) for i in doc/manual/src/command-ref/new-cli/*.md; do \
|
||||
name=$$(basename $$i .md); \
|
||||
tmpFile=$$(mktemp); \
|
||||
if [[ $$name = SUMMARY ]]; then continue; fi; \
|
||||
printf "Title: %s\n\n" "$$name" > $$tmpFile; \
|
||||
cat $$i >> $$tmpFile; \
|
||||
lowdown -sT man --nroff-nolinks -M section=1 $$tmpFile -o $(DESTDIR)$$(dirname $@)/$$name.1; \
|
||||
rm $$tmpFile; \
|
||||
printf "Title: %s\n\n" "$$name" > $$i.tmp; \
|
||||
cat $$i >> $$i.tmp; \
|
||||
lowdown -sT man $$i.tmp -o $(mandir)/man1/$$name.1; \
|
||||
done
|
||||
@touch $@
|
||||
|
||||
$(docdir)/manual/index.html: $(MANUAL_SRCS) $(d)/book.toml $(d)/anchors.jq $(d)/custom.css $(d)/src/SUMMARY.md $(d)/src/command-ref/new-cli $(d)/src/command-ref/conf-file.md $(d)/src/language/builtins.md
|
||||
$(trace-gen) \
|
||||
set -euo pipefail; \
|
||||
RUST_LOG=warn mdbook build doc/manual -d $(DESTDIR)$(docdir)/manual.tmp 2>&1 \
|
||||
| { grep -Fv "because fragment resolution isn't implemented" || :; }
|
||||
@rm -rf $(DESTDIR)$(docdir)/manual
|
||||
@mv $(DESTDIR)$(docdir)/manual.tmp/html $(DESTDIR)$(docdir)/manual
|
||||
@rm -rf $(DESTDIR)$(docdir)/manual.tmp
|
||||
$(docdir)/manual/index.html: $(MANUAL_SRCS) $(d)/book.toml $(d)/custom.css $(d)/src/SUMMARY.md $(d)/src/command-ref/new-cli $(d)/src/command-ref/conf-file.md $(d)/src/expressions/builtins.md
|
||||
$(trace-gen) RUST_LOG=warn mdbook build doc/manual -d $(docdir)/manual
|
||||
@cp doc/manual/highlight.pack.js $(docdir)/manual/highlight.js
|
||||
|
||||
endif
|
||||
|
||||
@@ -1,421 +0,0 @@
|
||||
// redirect rules for anchors ensure backwards compatibility of URLs.
|
||||
// this must be done on the client side, as web servers do not see the anchor part of the URL.
|
||||
|
||||
// redirections are declared as follows:
|
||||
// each entry has as its key a path matching the requested URL path, relative to the mdBook document root.
|
||||
//
|
||||
// IMPORTANT: it must specify the full path with file name and suffix
|
||||
//
|
||||
// each entry is itself a set of key-value pairs, where
|
||||
// - keys are anchors on the matched path.
|
||||
// - values are redirection targets relative to the current path.
|
||||
|
||||
const redirects = {
|
||||
"index.html": {
|
||||
"part-advanced-topics": "advanced-topics/advanced-topics.html",
|
||||
"chap-tuning-cores-and-jobs": "advanced-topics/cores-vs-jobs.html",
|
||||
"chap-diff-hook": "advanced-topics/diff-hook.html",
|
||||
"check-dirs-are-unregistered": "advanced-topics/diff-hook.html#check-dirs-are-unregistered",
|
||||
"chap-distributed-builds": "advanced-topics/distributed-builds.html",
|
||||
"chap-post-build-hook": "advanced-topics/post-build-hook.html",
|
||||
"chap-post-build-hook-caveats": "advanced-topics/post-build-hook.html#implementation-caveats",
|
||||
"part-command-ref": "command-ref/command-ref.html",
|
||||
"conf-allow-import-from-derivation": "command-ref/conf-file.html#conf-allow-import-from-derivation",
|
||||
"conf-allow-new-privileges": "command-ref/conf-file.html#conf-allow-new-privileges",
|
||||
"conf-allowed-uris": "command-ref/conf-file.html#conf-allowed-uris",
|
||||
"conf-allowed-users": "command-ref/conf-file.html#conf-allowed-users",
|
||||
"conf-auto-optimise-store": "command-ref/conf-file.html#conf-auto-optimise-store",
|
||||
"conf-binary-cache-public-keys": "command-ref/conf-file.html#conf-binary-cache-public-keys",
|
||||
"conf-binary-caches": "command-ref/conf-file.html#conf-binary-caches",
|
||||
"conf-build-compress-log": "command-ref/conf-file.html#conf-build-compress-log",
|
||||
"conf-build-cores": "command-ref/conf-file.html#conf-build-cores",
|
||||
"conf-build-extra-chroot-dirs": "command-ref/conf-file.html#conf-build-extra-chroot-dirs",
|
||||
"conf-build-extra-sandbox-paths": "command-ref/conf-file.html#conf-build-extra-sandbox-paths",
|
||||
"conf-build-fallback": "command-ref/conf-file.html#conf-build-fallback",
|
||||
"conf-build-max-jobs": "command-ref/conf-file.html#conf-build-max-jobs",
|
||||
"conf-build-max-log-size": "command-ref/conf-file.html#conf-build-max-log-size",
|
||||
"conf-build-max-silent-time": "command-ref/conf-file.html#conf-build-max-silent-time",
|
||||
"conf-build-timeout": "command-ref/conf-file.html#conf-build-timeout",
|
||||
"conf-build-use-chroot": "command-ref/conf-file.html#conf-build-use-chroot",
|
||||
"conf-build-use-sandbox": "command-ref/conf-file.html#conf-build-use-sandbox",
|
||||
"conf-build-use-substitutes": "command-ref/conf-file.html#conf-build-use-substitutes",
|
||||
"conf-build-users-group": "command-ref/conf-file.html#conf-build-users-group",
|
||||
"conf-builders": "command-ref/conf-file.html#conf-builders",
|
||||
"conf-builders-use-substitutes": "command-ref/conf-file.html#conf-builders-use-substitutes",
|
||||
"conf-compress-build-log": "command-ref/conf-file.html#conf-compress-build-log",
|
||||
"conf-connect-timeout": "command-ref/conf-file.html#conf-connect-timeout",
|
||||
"conf-cores": "command-ref/conf-file.html#conf-cores",
|
||||
"conf-diff-hook": "command-ref/conf-file.html#conf-diff-hook",
|
||||
"conf-env-keep-derivations": "command-ref/conf-file.html#conf-env-keep-derivations",
|
||||
"conf-extra-binary-caches": "command-ref/conf-file.html#conf-extra-binary-caches",
|
||||
"conf-extra-platforms": "command-ref/conf-file.html#conf-extra-platforms",
|
||||
"conf-extra-sandbox-paths": "command-ref/conf-file.html#conf-extra-sandbox-paths",
|
||||
"conf-extra-substituters": "command-ref/conf-file.html#conf-extra-substituters",
|
||||
"conf-fallback": "command-ref/conf-file.html#conf-fallback",
|
||||
"conf-fsync-metadata": "command-ref/conf-file.html#conf-fsync-metadata",
|
||||
"conf-gc-keep-derivations": "command-ref/conf-file.html#conf-gc-keep-derivations",
|
||||
"conf-gc-keep-outputs": "command-ref/conf-file.html#conf-gc-keep-outputs",
|
||||
"conf-hashed-mirrors": "command-ref/conf-file.html#conf-hashed-mirrors",
|
||||
"conf-http-connections": "command-ref/conf-file.html#conf-http-connections",
|
||||
"conf-keep-build-log": "command-ref/conf-file.html#conf-keep-build-log",
|
||||
"conf-keep-derivations": "command-ref/conf-file.html#conf-keep-derivations",
|
||||
"conf-keep-env-derivations": "command-ref/conf-file.html#conf-keep-env-derivations",
|
||||
"conf-keep-outputs": "command-ref/conf-file.html#conf-keep-outputs",
|
||||
"conf-max-build-log-size": "command-ref/conf-file.html#conf-max-build-log-size",
|
||||
"conf-max-free": "command-ref/conf-file.html#conf-max-free",
|
||||
"conf-max-jobs": "command-ref/conf-file.html#conf-max-jobs",
|
||||
"conf-max-silent-time": "command-ref/conf-file.html#conf-max-silent-time",
|
||||
"conf-min-free": "command-ref/conf-file.html#conf-min-free",
|
||||
"conf-narinfo-cache-negative-ttl": "command-ref/conf-file.html#conf-narinfo-cache-negative-ttl",
|
||||
"conf-narinfo-cache-positive-ttl": "command-ref/conf-file.html#conf-narinfo-cache-positive-ttl",
|
||||
"conf-netrc-file": "command-ref/conf-file.html#conf-netrc-file",
|
||||
"conf-plugin-files": "command-ref/conf-file.html#conf-plugin-files",
|
||||
"conf-post-build-hook": "command-ref/conf-file.html#conf-post-build-hook",
|
||||
"conf-pre-build-hook": "command-ref/conf-file.html#conf-pre-build-hook",
|
||||
"conf-require-sigs": "command-ref/conf-file.html#conf-require-sigs",
|
||||
"conf-restrict-eval": "command-ref/conf-file.html#conf-restrict-eval",
|
||||
"conf-run-diff-hook": "command-ref/conf-file.html#conf-run-diff-hook",
|
||||
"conf-sandbox": "command-ref/conf-file.html#conf-sandbox",
|
||||
"conf-sandbox-dev-shm-size": "command-ref/conf-file.html#conf-sandbox-dev-shm-size",
|
||||
"conf-sandbox-paths": "command-ref/conf-file.html#conf-sandbox-paths",
|
||||
"conf-secret-key-files": "command-ref/conf-file.html#conf-secret-key-files",
|
||||
"conf-show-trace": "command-ref/conf-file.html#conf-show-trace",
|
||||
"conf-stalled-download-timeout": "command-ref/conf-file.html#conf-stalled-download-timeout",
|
||||
"conf-substitute": "command-ref/conf-file.html#conf-substitute",
|
||||
"conf-substituters": "command-ref/conf-file.html#conf-substituters",
|
||||
"conf-system": "command-ref/conf-file.html#conf-system",
|
||||
"conf-system-features": "command-ref/conf-file.html#conf-system-features",
|
||||
"conf-tarball-ttl": "command-ref/conf-file.html#conf-tarball-ttl",
|
||||
"conf-timeout": "command-ref/conf-file.html#conf-timeout",
|
||||
"conf-trace-function-calls": "command-ref/conf-file.html#conf-trace-function-calls",
|
||||
"conf-trusted-binary-caches": "command-ref/conf-file.html#conf-trusted-binary-caches",
|
||||
"conf-trusted-public-keys": "command-ref/conf-file.html#conf-trusted-public-keys",
|
||||
"conf-trusted-substituters": "command-ref/conf-file.html#conf-trusted-substituters",
|
||||
"conf-trusted-users": "command-ref/conf-file.html#conf-trusted-users",
|
||||
"extra-sandbox-paths": "command-ref/conf-file.html#extra-sandbox-paths",
|
||||
"sec-conf-file": "command-ref/conf-file.html",
|
||||
"env-NIX_PATH": "command-ref/env-common.html#env-NIX_PATH",
|
||||
"env-common": "command-ref/env-common.html",
|
||||
"envar-remote": "command-ref/env-common.html#env-NIX_REMOTE",
|
||||
"sec-common-env": "command-ref/env-common.html",
|
||||
"ch-files": "command-ref/files.html",
|
||||
"ch-main-commands": "command-ref/main-commands.html",
|
||||
"opt-out-link": "command-ref/nix-build.html#opt-out-link",
|
||||
"sec-nix-build": "command-ref/nix-build.html",
|
||||
"sec-nix-channel": "command-ref/nix-channel.html",
|
||||
"sec-nix-collect-garbage": "command-ref/nix-collect-garbage.html",
|
||||
"sec-nix-copy-closure": "command-ref/nix-copy-closure.html",
|
||||
"sec-nix-daemon": "command-ref/nix-daemon.html",
|
||||
"refsec-nix-env-install-examples": "command-ref/nix-env.html#examples",
|
||||
"rsec-nix-env-install": "command-ref/nix-env.html#operation---install",
|
||||
"rsec-nix-env-set": "command-ref/nix-env.html#operation---set",
|
||||
"rsec-nix-env-set-flag": "command-ref/nix-env.html#operation---set-flag",
|
||||
"rsec-nix-env-upgrade": "command-ref/nix-env.html#operation---upgrade",
|
||||
"sec-nix-env": "command-ref/nix-env.html",
|
||||
"ssec-version-comparisons": "command-ref/nix-env.html#versions",
|
||||
"sec-nix-hash": "command-ref/nix-hash.html",
|
||||
"sec-nix-instantiate": "command-ref/nix-instantiate.html",
|
||||
"sec-nix-prefetch-url": "command-ref/nix-prefetch-url.html",
|
||||
"sec-nix-shell": "command-ref/nix-shell.html",
|
||||
"ssec-nix-shell-shebang": "command-ref/nix-shell.html#use-as-a--interpreter",
|
||||
"nixref-queries": "command-ref/nix-store.html#queries",
|
||||
"opt-add-root": "command-ref/nix-store.html#opt-add-root",
|
||||
"refsec-nix-store-dump": "command-ref/nix-store.html#operation---dump",
|
||||
"refsec-nix-store-export": "command-ref/nix-store.html#operation---export",
|
||||
"refsec-nix-store-import": "command-ref/nix-store.html#operation---import",
|
||||
"refsec-nix-store-query": "command-ref/nix-store.html#operation---query",
|
||||
"refsec-nix-store-verify": "command-ref/nix-store.html#operation---verify",
|
||||
"rsec-nix-store-gc": "command-ref/nix-store.html#operation---gc",
|
||||
"rsec-nix-store-generate-binary-cache-key": "command-ref/nix-store.html#operation---generate-binary-cache-key",
|
||||
"rsec-nix-store-realise": "command-ref/nix-store.html#operation---realise",
|
||||
"rsec-nix-store-serve": "command-ref/nix-store.html#operation---serve",
|
||||
"sec-nix-store": "command-ref/nix-store.html",
|
||||
"opt-I": "command-ref/opt-common.html#opt-I",
|
||||
"opt-attr": "command-ref/opt-common.html#opt-attr",
|
||||
"opt-common": "command-ref/opt-common.html",
|
||||
"opt-cores": "command-ref/opt-common.html#opt-cores",
|
||||
"opt-log-format": "command-ref/opt-common.html#opt-log-format",
|
||||
"opt-max-jobs": "command-ref/opt-common.html#opt-max-jobs",
|
||||
"opt-max-silent-time": "command-ref/opt-common.html#opt-max-silent-time",
|
||||
"opt-timeout": "command-ref/opt-common.html#opt-timeout",
|
||||
"sec-common-options": "command-ref/opt-common.html",
|
||||
"ch-utilities": "command-ref/utilities.html",
|
||||
"chap-hacking": "contributing/hacking.html",
|
||||
"adv-attr-allowSubstitutes": "language/advanced-attributes.html#adv-attr-allowSubstitutes",
|
||||
"adv-attr-allowedReferences": "language/advanced-attributes.html#adv-attr-allowedReferences",
|
||||
"adv-attr-allowedRequisites": "language/advanced-attributes.html#adv-attr-allowedRequisites",
|
||||
"adv-attr-disallowedReferences": "language/advanced-attributes.html#adv-attr-disallowedReferences",
|
||||
"adv-attr-disallowedRequisites": "language/advanced-attributes.html#adv-attr-disallowedRequisites",
|
||||
"adv-attr-exportReferencesGraph": "language/advanced-attributes.html#adv-attr-exportReferencesGraph",
|
||||
"adv-attr-impureEnvVars": "language/advanced-attributes.html#adv-attr-impureEnvVars",
|
||||
"adv-attr-outputHash": "language/advanced-attributes.html#adv-attr-outputHash",
|
||||
"adv-attr-outputHashAlgo": "language/advanced-attributes.html#adv-attr-outputHashAlgo",
|
||||
"adv-attr-outputHashMode": "language/advanced-attributes.html#adv-attr-outputHashMode",
|
||||
"adv-attr-passAsFile": "language/advanced-attributes.html#adv-attr-passAsFile",
|
||||
"adv-attr-preferLocalBuild": "language/advanced-attributes.html#adv-attr-preferLocalBuild",
|
||||
"fixed-output-drvs": "language/advanced-attributes.html#adv-attr-outputHash",
|
||||
"sec-advanced-attributes": "language/advanced-attributes.html",
|
||||
"builtin-abort": "language/builtins.html#builtins-abort",
|
||||
"builtin-add": "language/builtins.html#builtins-add",
|
||||
"builtin-all": "language/builtins.html#builtins-all",
|
||||
"builtin-any": "language/builtins.html#builtins-any",
|
||||
"builtin-attrNames": "language/builtins.html#builtins-attrNames",
|
||||
"builtin-attrValues": "language/builtins.html#builtins-attrValues",
|
||||
"builtin-baseNameOf": "language/builtins.html#builtins-baseNameOf",
|
||||
"builtin-bitAnd": "language/builtins.html#builtins-bitAnd",
|
||||
"builtin-bitOr": "language/builtins.html#builtins-bitOr",
|
||||
"builtin-bitXor": "language/builtins.html#builtins-bitXor",
|
||||
"builtin-builtins": "language/builtins.html#builtins-builtins",
|
||||
"builtin-compareVersions": "language/builtins.html#builtins-compareVersions",
|
||||
"builtin-concatLists": "language/builtins.html#builtins-concatLists",
|
||||
"builtin-concatStringsSep": "language/builtins.html#builtins-concatStringsSep",
|
||||
"builtin-currentSystem": "language/builtins.html#builtins-currentSystem",
|
||||
"builtin-deepSeq": "language/builtins.html#builtins-deepSeq",
|
||||
"builtin-derivation": "language/builtins.html#builtins-derivation",
|
||||
"builtin-dirOf": "language/builtins.html#builtins-dirOf",
|
||||
"builtin-div": "language/builtins.html#builtins-div",
|
||||
"builtin-elem": "language/builtins.html#builtins-elem",
|
||||
"builtin-elemAt": "language/builtins.html#builtins-elemAt",
|
||||
"builtin-fetchGit": "language/builtins.html#builtins-fetchGit",
|
||||
"builtin-fetchTarball": "language/builtins.html#builtins-fetchTarball",
|
||||
"builtin-fetchurl": "language/builtins.html#builtins-fetchurl",
|
||||
"builtin-filterSource": "language/builtins.html#builtins-filterSource",
|
||||
"builtin-foldl-prime": "language/builtins.html#builtins-foldl-prime",
|
||||
"builtin-fromJSON": "language/builtins.html#builtins-fromJSON",
|
||||
"builtin-functionArgs": "language/builtins.html#builtins-functionArgs",
|
||||
"builtin-genList": "language/builtins.html#builtins-genList",
|
||||
"builtin-getAttr": "language/builtins.html#builtins-getAttr",
|
||||
"builtin-getEnv": "language/builtins.html#builtins-getEnv",
|
||||
"builtin-hasAttr": "language/builtins.html#builtins-hasAttr",
|
||||
"builtin-hashFile": "language/builtins.html#builtins-hashFile",
|
||||
"builtin-hashString": "language/builtins.html#builtins-hashString",
|
||||
"builtin-head": "language/builtins.html#builtins-head",
|
||||
"builtin-import": "language/builtins.html#builtins-import",
|
||||
"builtin-intersectAttrs": "language/builtins.html#builtins-intersectAttrs",
|
||||
"builtin-isAttrs": "language/builtins.html#builtins-isAttrs",
|
||||
"builtin-isBool": "language/builtins.html#builtins-isBool",
|
||||
"builtin-isFloat": "language/builtins.html#builtins-isFloat",
|
||||
"builtin-isFunction": "language/builtins.html#builtins-isFunction",
|
||||
"builtin-isInt": "language/builtins.html#builtins-isInt",
|
||||
"builtin-isList": "language/builtins.html#builtins-isList",
|
||||
"builtin-isNull": "language/builtins.html#builtins-isNull",
|
||||
"builtin-isString": "language/builtins.html#builtins-isString",
|
||||
"builtin-length": "language/builtins.html#builtins-length",
|
||||
"builtin-lessThan": "language/builtins.html#builtins-lessThan",
|
||||
"builtin-listToAttrs": "language/builtins.html#builtins-listToAttrs",
|
||||
"builtin-map": "language/builtins.html#builtins-map",
|
||||
"builtin-match": "language/builtins.html#builtins-match",
|
||||
"builtin-mul": "language/builtins.html#builtins-mul",
|
||||
"builtin-parseDrvName": "language/builtins.html#builtins-parseDrvName",
|
||||
"builtin-path": "language/builtins.html#builtins-path",
|
||||
"builtin-pathExists": "language/builtins.html#builtins-pathExists",
|
||||
"builtin-placeholder": "language/builtins.html#builtins-placeholder",
|
||||
"builtin-readDir": "language/builtins.html#builtins-readDir",
|
||||
"builtin-readFile": "language/builtins.html#builtins-readFile",
|
||||
"builtin-removeAttrs": "language/builtins.html#builtins-removeAttrs",
|
||||
"builtin-replaceStrings": "language/builtins.html#builtins-replaceStrings",
|
||||
"builtin-seq": "language/builtins.html#builtins-seq",
|
||||
"builtin-sort": "language/builtins.html#builtins-sort",
|
||||
"builtin-split": "language/builtins.html#builtins-split",
|
||||
"builtin-splitVersion": "language/builtins.html#builtins-splitVersion",
|
||||
"builtin-stringLength": "language/builtins.html#builtins-stringLength",
|
||||
"builtin-sub": "language/builtins.html#builtins-sub",
|
||||
"builtin-substring": "language/builtins.html#builtins-substring",
|
||||
"builtin-tail": "language/builtins.html#builtins-tail",
|
||||
"builtin-throw": "language/builtins.html#builtins-throw",
|
||||
"builtin-toFile": "language/builtins.html#builtins-toFile",
|
||||
"builtin-toJSON": "language/builtins.html#builtins-toJSON",
|
||||
"builtin-toPath": "language/builtins.html#builtins-toPath",
|
||||
"builtin-toString": "language/builtins.html#builtins-toString",
|
||||
"builtin-toXML": "language/builtins.html#builtins-toXML",
|
||||
"builtin-trace": "language/builtins.html#builtins-trace",
|
||||
"builtin-tryEval": "language/builtins.html#builtins-tryEval",
|
||||
"builtin-typeOf": "language/builtins.html#builtins-typeOf",
|
||||
"ssec-builtins": "language/builtins.html",
|
||||
"attr-system": "language/derivations.html#attr-system",
|
||||
"ssec-derivation": "language/derivations.html",
|
||||
"ch-expression-language": "language/index.html",
|
||||
"sec-constructs": "language/constructs.html",
|
||||
"sect-let-language": "language/constructs.html#let-language",
|
||||
"ss-functions": "language/constructs.html#functions",
|
||||
"sec-language-operators": "language/operators.html",
|
||||
"table-operators": "language/operators.html",
|
||||
"ssec-values": "language/values.html",
|
||||
"gloss-closure": "glossary.html#gloss-closure",
|
||||
"gloss-derivation": "glossary.html#gloss-derivation",
|
||||
"gloss-deriver": "glossary.html#gloss-deriver",
|
||||
"gloss-nar": "glossary.html#gloss-nar",
|
||||
"gloss-output-path": "glossary.html#gloss-output-path",
|
||||
"gloss-profile": "glossary.html#gloss-profile",
|
||||
"gloss-reachable": "glossary.html#gloss-reachable",
|
||||
"gloss-reference": "glossary.html#gloss-reference",
|
||||
"gloss-substitute": "glossary.html#gloss-substitute",
|
||||
"gloss-user-env": "glossary.html#gloss-user-env",
|
||||
"gloss-validity": "glossary.html#gloss-validity",
|
||||
"part-glossary": "glossary.html",
|
||||
"sec-building-source": "installation/building-source.html",
|
||||
"ch-env-variables": "installation/env-variables.html",
|
||||
"sec-installer-proxy-settings": "installation/env-variables.html#proxy-environment-variables",
|
||||
"sec-nix-ssl-cert-file": "installation/env-variables.html#nix_ssl_cert_file",
|
||||
"sec-nix-ssl-cert-file-with-nix-daemon-and-macos": "installation/env-variables.html#nix_ssl_cert_file-with-macos-and-the-nix-daemon",
|
||||
"chap-installation": "installation/installation.html",
|
||||
"ch-installing-binary": "installation/installing-binary.html",
|
||||
"sect-macos-installation": "installation/installing-binary.html#macos-installation",
|
||||
"sect-macos-installation-change-store-prefix": "installation/installing-binary.html#macos-installation",
|
||||
"sect-macos-installation-encrypted-volume": "installation/installing-binary.html#macos-installation",
|
||||
"sect-macos-installation-recommended-notes": "installation/installing-binary.html#macos-installation",
|
||||
"sect-macos-installation-symlink": "installation/installing-binary.html#macos-installation",
|
||||
"sect-multi-user-installation": "installation/installing-binary.html#multi-user-installation",
|
||||
"sect-nix-install-binary-tarball": "installation/installing-binary.html#installing-from-a-binary-tarball",
|
||||
"sect-nix-install-pinned-version-url": "installation/installing-binary.html#installing-a-pinned-nix-version-from-a-url",
|
||||
"sect-single-user-installation": "installation/installing-binary.html#single-user-installation",
|
||||
"ch-installing-source": "installation/installing-source.html",
|
||||
"ssec-multi-user": "installation/multi-user.html",
|
||||
"ch-nix-security": "installation/nix-security.html",
|
||||
"sec-obtaining-source": "installation/obtaining-source.html",
|
||||
"sec-prerequisites-source": "installation/prerequisites-source.html",
|
||||
"sec-single-user": "installation/single-user.html",
|
||||
"ch-supported-platforms": "installation/supported-platforms.html",
|
||||
"ch-upgrading-nix": "installation/upgrading.html",
|
||||
"ch-about-nix": "introduction.html",
|
||||
"chap-introduction": "introduction.html",
|
||||
"ch-basic-package-mgmt": "package-management/basic-package-mgmt.html",
|
||||
"ssec-binary-cache-substituter": "package-management/binary-cache-substituter.html",
|
||||
"sec-channels": "package-management/channels.html",
|
||||
"ssec-copy-closure": "package-management/copy-closure.html",
|
||||
"sec-garbage-collection": "package-management/garbage-collection.html",
|
||||
"ssec-gc-roots": "package-management/garbage-collector-roots.html",
|
||||
"chap-package-management": "package-management/package-management.html",
|
||||
"sec-profiles": "package-management/profiles.html",
|
||||
"ssec-s3-substituter": "package-management/s3-substituter.html",
|
||||
"ssec-s3-substituter-anonymous-reads": "package-management/s3-substituter.html#anonymous-reads-to-your-s3-compatible-binary-cache",
|
||||
"ssec-s3-substituter-authenticated-reads": "package-management/s3-substituter.html#authenticated-reads-to-your-s3-binary-cache",
|
||||
"ssec-s3-substituter-authenticated-writes": "package-management/s3-substituter.html#authenticated-writes-to-your-s3-compatible-binary-cache",
|
||||
"sec-sharing-packages": "package-management/sharing-packages.html",
|
||||
"ssec-ssh-substituter": "package-management/ssh-substituter.html",
|
||||
"chap-quick-start": "quick-start.html",
|
||||
"sec-relnotes": "release-notes/release-notes.html",
|
||||
"ch-relnotes-0.10.1": "release-notes/rl-0.10.1.html",
|
||||
"ch-relnotes-0.10": "release-notes/rl-0.10.html",
|
||||
"ssec-relnotes-0.11": "release-notes/rl-0.11.html",
|
||||
"ssec-relnotes-0.12": "release-notes/rl-0.12.html",
|
||||
"ssec-relnotes-0.13": "release-notes/rl-0.13.html",
|
||||
"ssec-relnotes-0.14": "release-notes/rl-0.14.html",
|
||||
"ssec-relnotes-0.15": "release-notes/rl-0.15.html",
|
||||
"ssec-relnotes-0.16": "release-notes/rl-0.16.html",
|
||||
"ch-relnotes-0.5": "release-notes/rl-0.5.html",
|
||||
"ch-relnotes-0.6": "release-notes/rl-0.6.html",
|
||||
"ch-relnotes-0.7": "release-notes/rl-0.7.html",
|
||||
"ch-relnotes-0.8.1": "release-notes/rl-0.8.1.html",
|
||||
"ch-relnotes-0.8": "release-notes/rl-0.8.html",
|
||||
"ch-relnotes-0.9.1": "release-notes/rl-0.9.1.html",
|
||||
"ch-relnotes-0.9.2": "release-notes/rl-0.9.2.html",
|
||||
"ch-relnotes-0.9": "release-notes/rl-0.9.html",
|
||||
"ssec-relnotes-1.0": "release-notes/rl-1.0.html",
|
||||
"ssec-relnotes-1.1": "release-notes/rl-1.1.html",
|
||||
"ssec-relnotes-1.10": "release-notes/rl-1.10.html",
|
||||
"ssec-relnotes-1.11.10": "release-notes/rl-1.11.10.html",
|
||||
"ssec-relnotes-1.11": "release-notes/rl-1.11.html",
|
||||
"ssec-relnotes-1.2": "release-notes/rl-1.2.html",
|
||||
"ssec-relnotes-1.3": "release-notes/rl-1.3.html",
|
||||
"ssec-relnotes-1.4": "release-notes/rl-1.4.html",
|
||||
"ssec-relnotes-1.5.1": "release-notes/rl-1.5.1.html",
|
||||
"ssec-relnotes-1.5.2": "release-notes/rl-1.5.2.html",
|
||||
"ssec-relnotes-1.5": "release-notes/rl-1.5.html",
|
||||
"ssec-relnotes-1.6.1": "release-notes/rl-1.6.1.html",
|
||||
"ssec-relnotes-1.6.0": "release-notes/rl-1.6.html",
|
||||
"ssec-relnotes-1.7": "release-notes/rl-1.7.html",
|
||||
"ssec-relnotes-1.8": "release-notes/rl-1.8.html",
|
||||
"ssec-relnotes-1.9": "release-notes/rl-1.9.html",
|
||||
"ssec-relnotes-2.0": "release-notes/rl-2.0.html",
|
||||
"ssec-relnotes-2.1": "release-notes/rl-2.1.html",
|
||||
"ssec-relnotes-2.2": "release-notes/rl-2.2.html",
|
||||
"ssec-relnotes-2.3": "release-notes/rl-2.3.html"
|
||||
},
|
||||
"language/values.html": {
|
||||
"simple-values": "#primitives",
|
||||
"lists": "#list",
|
||||
"strings": "#string",
|
||||
"lists": "#list",
|
||||
"attribute-sets": "#attribute-set"
|
||||
}
|
||||
};
|
||||
|
||||
// the following code matches the current page's URL against the set of redirects.
|
||||
//
|
||||
// it is written to minimize the latency between page load and redirect.
|
||||
// therefore we avoid function calls, copying data, and unnecessary loops.
|
||||
// IMPORTANT: we use stateful array operations and their order matters!
|
||||
//
|
||||
// matching URLs is more involved than it should be:
|
||||
//
|
||||
// 1. `document.location.pathname` can have an arbitrary prefix.
|
||||
//
|
||||
// 2. `path_to_root` is set by mdBook. it consists only of `../`s and
|
||||
// determines the depth of `<path>` relative to the prefix:
|
||||
//
|
||||
// `document.location.pathname`
|
||||
// |------------------------------|
|
||||
// /<prefix>/<path>/[<file>[.html]][#<anchor>]
|
||||
// |----|
|
||||
// `path_to_root` has same number of path segments
|
||||
//
|
||||
// source: https://phaiax.github.io/mdBook/format/theme/index-hbs.html#data
|
||||
//
|
||||
// 3. the following paths are equivalent:
|
||||
//
|
||||
// /foo/bar/
|
||||
// /foo/bar/index.html
|
||||
// /foo/bar/index
|
||||
//
|
||||
// 4. the following paths are also equivalent:
|
||||
//
|
||||
// /foo/bar/baz
|
||||
// /foo/bar/baz.html
|
||||
//
|
||||
|
||||
let segments = document.location.pathname.split('/');
|
||||
|
||||
let file = segments.pop();
|
||||
|
||||
// normalize file name
|
||||
if (file === '') { file = "index.html"; }
|
||||
else if (!file.endsWith('.html')) { file = file + '.html'; }
|
||||
|
||||
segments.push(file);
|
||||
|
||||
// use `path_to_root` to discern prefix from path.
|
||||
const depth = path_to_root.split('/').length;
|
||||
|
||||
// remove segments containing prefix. the following works because
|
||||
// 1. the original `document.location.pathname` is absolute,
|
||||
// hence first element of `segments` is always empty.
|
||||
// 2. last element of splitting `path_to_root` is also always empty.
|
||||
// 3. last element of `segments` is the file name.
|
||||
//
|
||||
// visual example:
|
||||
//
|
||||
// '/foo/bar/baz.html'.split('/') -> [ '', 'foo', 'bar', 'baz.html' ]
|
||||
// '../'.split('/') -> [ '..', '' ]
|
||||
//
|
||||
// the following operations will then result in
|
||||
//
|
||||
// path = 'bar/baz.html'
|
||||
//
|
||||
segments.splice(0, segments.length - depth);
|
||||
const path = segments.join('/');
|
||||
|
||||
// anchor starts with the hash character (`#`),
|
||||
// but our redirect declarations don't, so we strip it.
|
||||
// example:
|
||||
// document.location.hash -> '#foo'
|
||||
// document.location.hash.substring(1) -> 'foo'
|
||||
const anchor = document.location.hash.substring(1);
|
||||
|
||||
const redirect = redirects[path];
|
||||
if (redirect) {
|
||||
const target = redirect[anchor];
|
||||
if (target) {
|
||||
document.location.href = target;
|
||||
}
|
||||
}
|
||||
@@ -9,7 +9,6 @@
|
||||
- [Prerequisites](installation/prerequisites-source.md)
|
||||
- [Obtaining a Source Distribution](installation/obtaining-source.md)
|
||||
- [Building Nix from Source](installation/building-source.md)
|
||||
- [Using Nix within Docker](installation/installing-docker.md)
|
||||
- [Security](installation/nix-security.md)
|
||||
- [Single-User Mode](installation/single-user.md)
|
||||
- [Multi-User Mode](installation/multi-user.md)
|
||||
@@ -26,15 +25,21 @@
|
||||
- [Copying Closures via SSH](package-management/copy-closure.md)
|
||||
- [Serving a Nix store via SSH](package-management/ssh-substituter.md)
|
||||
- [Serving a Nix store via S3](package-management/s3-substituter.md)
|
||||
- [Nix Language](language/index.md)
|
||||
- [Data Types](language/values.md)
|
||||
- [Language Constructs](language/constructs.md)
|
||||
- [String interpolation](language/string-interpolation.md)
|
||||
- [Operators](language/operators.md)
|
||||
- [Derivations](language/derivations.md)
|
||||
- [Advanced Attributes](language/advanced-attributes.md)
|
||||
- [Built-in Constants](language/builtin-constants.md)
|
||||
- [Built-in Functions](language/builtins.md)
|
||||
- [Writing Nix Expressions](expressions/writing-nix-expressions.md)
|
||||
- [A Simple Nix Expression](expressions/simple-expression.md)
|
||||
- [Expression Syntax](expressions/expression-syntax.md)
|
||||
- [Build Script](expressions/build-script.md)
|
||||
- [Arguments and Variables](expressions/arguments-variables.md)
|
||||
- [Building and Testing](expressions/simple-building-testing.md)
|
||||
- [Generic Builder Syntax](expressions/generic-builder.md)
|
||||
- [Writing Nix Expressions](expressions/expression-language.md)
|
||||
- [Values](expressions/language-values.md)
|
||||
- [Language Constructs](expressions/language-constructs.md)
|
||||
- [Operators](expressions/language-operators.md)
|
||||
- [Derivations](expressions/derivations.md)
|
||||
- [Advanced Attributes](expressions/advanced-attributes.md)
|
||||
- [Built-in Constants](expressions/builtin-constants.md)
|
||||
- [Built-in Functions](expressions/builtins.md)
|
||||
- [Advanced Topics](advanced-topics/advanced-topics.md)
|
||||
- [Remote Builds](advanced-topics/distributed-builds.md)
|
||||
- [Tuning Cores and Jobs](advanced-topics/cores-vs-jobs.md)
|
||||
@@ -60,22 +65,11 @@
|
||||
@manpages@
|
||||
- [Files](command-ref/files.md)
|
||||
- [nix.conf](command-ref/conf-file.md)
|
||||
- [Architecture](architecture/architecture.md)
|
||||
- [Glossary](glossary.md)
|
||||
- [Contributing](contributing/contributing.md)
|
||||
- [Hacking](contributing/hacking.md)
|
||||
- [CLI guideline](contributing/cli-guideline.md)
|
||||
- [Release Notes](release-notes/release-notes.md)
|
||||
- [Release 2.13 (2023-01-17)](release-notes/rl-2.13.md)
|
||||
- [Release 2.12 (2022-12-06)](release-notes/rl-2.12.md)
|
||||
- [Release 2.11 (2022-08-25)](release-notes/rl-2.11.md)
|
||||
- [Release 2.10 (2022-07-11)](release-notes/rl-2.10.md)
|
||||
- [Release 2.9 (2022-05-30)](release-notes/rl-2.9.md)
|
||||
- [Release 2.8 (2022-04-19)](release-notes/rl-2.8.md)
|
||||
- [Release 2.7 (2022-03-07)](release-notes/rl-2.7.md)
|
||||
- [Release 2.6 (2022-01-24)](release-notes/rl-2.6.md)
|
||||
- [Release 2.5 (2021-12-13)](release-notes/rl-2.5.md)
|
||||
- [Release 2.4 (2021-11-01)](release-notes/rl-2.4.md)
|
||||
- [Release 2.3 (2019-09-04)](release-notes/rl-2.3.md)
|
||||
- [Release 2.2 (2019-01-11)](release-notes/rl-2.2.md)
|
||||
- [Release 2.1 (2018-09-02)](release-notes/rl-2.1.md)
|
||||
|
||||
@@ -4,13 +4,13 @@ Nix has two relevant settings with regards to how your CPU cores will
|
||||
be utilized: `cores` and `max-jobs`. This chapter will talk about what
|
||||
they are, how they interact, and their configuration trade-offs.
|
||||
|
||||
- `max-jobs`\
|
||||
- `max-jobs`
|
||||
Dictates how many separate derivations will be built at the same
|
||||
time. If you set this to zero, the local machine will do no
|
||||
builds. Nix will still substitute from binary caches, and build
|
||||
remotely if remote builders are configured.
|
||||
|
||||
- `cores`\
|
||||
- `cores`
|
||||
Suggests how many cores each derivation should use. Similar to
|
||||
`make -j`.
|
||||
|
||||
|
||||
@@ -101,7 +101,7 @@ In particular, notice the
|
||||
`/nix/store/krpqk0l9ib0ibi1d2w52z293zw455cap-unstable.check` output. Nix
|
||||
has copied the build results to that directory where you can examine it.
|
||||
|
||||
> []{#check-dirs-are-unregistered} **Note**
|
||||
> **Note**
|
||||
>
|
||||
> Check paths are not protected against garbage collection, and this
|
||||
> path will be deleted on the next garbage collection.
|
||||
@@ -121,3 +121,37 @@ error:
|
||||
are not valid, so checking is not possible
|
||||
|
||||
Run the build without `--check`, and then try with `--check` again.
|
||||
|
||||
# Automatic and Optionally Enforced Determinism Verification
|
||||
|
||||
Automatically verify every build at build time by executing the build
|
||||
multiple times.
|
||||
|
||||
Setting `repeat` and `enforce-determinism` in your `nix.conf` permits
|
||||
the automated verification of every build Nix performs.
|
||||
|
||||
The following configuration will run each build three times, and will
|
||||
require the build to be deterministic:
|
||||
|
||||
enforce-determinism = true
|
||||
repeat = 2
|
||||
|
||||
Setting `enforce-determinism` to false as in the following
|
||||
configuration will run the build multiple times, execute the build
|
||||
hook, but will allow the build to succeed even if it does not build
|
||||
reproducibly:
|
||||
|
||||
enforce-determinism = false
|
||||
repeat = 1
|
||||
|
||||
An example output of this configuration:
|
||||
|
||||
```console
|
||||
$ nix-build ./test.nix -A unstable
|
||||
this derivation will be built:
|
||||
/nix/store/ch6llwpr2h8c3jmnf3f2ghkhx59aa97f-unstable.drv
|
||||
building '/nix/store/ch6llwpr2h8c3jmnf3f2ghkhx59aa97f-unstable.drv' (round 1/2)...
|
||||
building '/nix/store/ch6llwpr2h8c3jmnf3f2ghkhx59aa97f-unstable.drv' (round 2/2)...
|
||||
output '/nix/store/6xg356v9gl03hpbbg8gws77n19qanh02-unstable' of '/nix/store/ch6llwpr2h8c3jmnf3f2ghkhx59aa97f-unstable.drv' differs from '/nix/store/6xg356v9gl03hpbbg8gws77n19qanh02-unstable.check' from previous round
|
||||
/nix/store/6xg356v9gl03hpbbg8gws77n19qanh02-unstable
|
||||
```
|
||||
|
||||
@@ -12,14 +12,14 @@ machine is accessible via SSH and that it has Nix installed. You can
|
||||
test whether connecting to the remote Nix instance works, e.g.
|
||||
|
||||
```console
|
||||
$ nix store ping --store ssh://mac
|
||||
$ nix ping-store --store ssh://mac
|
||||
```
|
||||
|
||||
will try to connect to the machine named `mac`. It is possible to
|
||||
specify an SSH identity file as part of the remote store URI, e.g.
|
||||
|
||||
```console
|
||||
$ nix store ping --store ssh://mac?ssh-key=/home/alice/my-key
|
||||
$ nix ping-store --store ssh://mac?ssh-key=/home/alice/my-key
|
||||
```
|
||||
|
||||
Since builds should be non-interactive, the key should not have a
|
||||
@@ -37,7 +37,7 @@ then you need to ensure that the `PATH` of non-interactive login shells
|
||||
contains Nix.
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
>
|
||||
> If you are building via the Nix daemon, it is the Nix daemon user
|
||||
> account (that is, `root`) that should have SSH access to the remote
|
||||
> machine. If you can’t or don’t want to configure `root` to be able to
|
||||
@@ -52,9 +52,9 @@ example, the following command allows you to build a derivation for
|
||||
```console
|
||||
$ uname
|
||||
Linux
|
||||
|
||||
$ nix build --impure \
|
||||
--expr '(with import <nixpkgs> { system = "x86_64-darwin"; }; runCommand "foo" {} "uname > $out")' \
|
||||
|
||||
$ nix build \
|
||||
'(with import <nixpkgs> { system = "x86_64-darwin"; }; runCommand "foo" {} "uname > $out")' \
|
||||
--builders 'ssh://mac x86_64-darwin'
|
||||
[1/0/1 built, 0.0 MiB DL] building foo on ssh://mac
|
||||
|
||||
@@ -103,18 +103,14 @@ default, set it to `-`.
|
||||
```nix
|
||||
requiredSystemFeatures = [ "kvm" ];
|
||||
```
|
||||
|
||||
|
||||
will cause the build to be performed on a machine that has the `kvm`
|
||||
feature.
|
||||
|
||||
7. A comma-separated list of *mandatory features*. A machine will only
|
||||
be used to build a derivation if all of the machine’s mandatory
|
||||
features appear in the derivation’s `requiredSystemFeatures`
|
||||
attribute.
|
||||
|
||||
8. The (base64-encoded) public host key of the remote machine. If omitted, SSH
|
||||
will use its regular known-hosts file. Specifically, the field is calculated
|
||||
via `base64 -w0 /etc/ssh/ssh_host_ed25519_key.pub`.
|
||||
attribute..
|
||||
|
||||
For example, the machine specification
|
||||
|
||||
|
||||
@@ -33,17 +33,12 @@ distribute the public key for verifying the authenticity of the paths.
|
||||
example-nix-cache-1:1/cKDz3QCCOmwcztD2eV6Coggp6rqc9DGjWv7C0G+rM=
|
||||
```
|
||||
|
||||
Then update [`nix.conf`](../command-ref/conf-file.md) on any machine that will access the cache.
|
||||
Add the cache URL to [`substituters`](../command-ref/conf-file.md#conf-substituters) and the public key to [`trusted-public-keys`](../command-ref/conf-file.md#conf-trusted-public-keys):
|
||||
Then, add the public key and the cache URL to your `nix.conf`'s
|
||||
`trusted-public-keys` and `substituters` options:
|
||||
|
||||
substituters = https://cache.nixos.org/ s3://example-nix-cache
|
||||
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= example-nix-cache-1:1/cKDz3QCCOmwcztD2eV6Coggp6rqc9DGjWv7C0G+rM=
|
||||
|
||||
Machines that build for the cache must sign derivations using the private key.
|
||||
On those machines, add the path to the key file to the [`secret-key-files`](../command-ref/conf-file.md#conf-secret-key-files) field in their [`nix.conf`](../command-ref/conf-file.md):
|
||||
|
||||
secret-key-files = /etc/nix/key.private
|
||||
|
||||
We will restart the Nix daemon in a later step.
|
||||
|
||||
# Implementing the build hook
|
||||
@@ -57,12 +52,14 @@ set -eu
|
||||
set -f # disable globbing
|
||||
export IFS=' '
|
||||
|
||||
echo "Signing paths" $OUT_PATHS
|
||||
nix store sign --key-file /etc/nix/key.private $OUT_PATHS
|
||||
echo "Uploading paths" $OUT_PATHS
|
||||
exec nix copy --to "s3://example-nix-cache" $OUT_PATHS
|
||||
exec nix copy --to 's3://example-nix-cache' $OUT_PATHS
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
>
|
||||
> The `$OUT_PATHS` variable is a space-separated list of Nix store
|
||||
> paths. In this case, we expect and want the shell to perform word
|
||||
> splitting to make each output path its own argument to `nix
|
||||
|
||||
@@ -1,115 +0,0 @@
|
||||
# Architecture
|
||||
|
||||
This chapter describes how Nix works.
|
||||
It should help users understand why Nix behaves as it does, and it should help developers understand how to modify Nix and how to write similar tools.
|
||||
|
||||
## Overview
|
||||
|
||||
Nix consists of [hierarchical layers].
|
||||
|
||||
[hierarchical layers]: https://en.m.wikipedia.org/wiki/Multitier_architecture#Layers
|
||||
|
||||
The following [concept map] shows its main components (rectangles), the objects they operate on (rounded rectangles), and their interactions (connecting phrases):
|
||||
|
||||
[concept map]: https://en.m.wikipedia.org/wiki/Concept_map
|
||||
|
||||
```
|
||||
|
||||
.----------------.
|
||||
| Nix expression |----------.
|
||||
'----------------' |
|
||||
| passed to
|
||||
| |
|
||||
+----------|-------------------|--------------------------------+
|
||||
| Nix | V |
|
||||
| | +-------------------------+ |
|
||||
| | | commmand line interface |------. |
|
||||
| | +-------------------------+ | |
|
||||
| | | | |
|
||||
| evaluated by calls manages |
|
||||
| | | | |
|
||||
| | V | |
|
||||
| | +--------------------+ | |
|
||||
| '-------->| language evaluator | | |
|
||||
| +--------------------+ | |
|
||||
| | | |
|
||||
| produces | |
|
||||
| | V |
|
||||
| +----------------------------|------------------------------+ |
|
||||
| | store | | |
|
||||
| | referenced by V builds | |
|
||||
| | .-------------. .------------. .--------------. | |
|
||||
| | | build input |----->| build plan |----->| build result | | |
|
||||
| | '-------------' '------------' '--------------' | |
|
||||
| +-------------------------------------------------|---------+ |
|
||||
+---------------------------------------------------|-----------+
|
||||
|
|
||||
represented as
|
||||
|
|
||||
V
|
||||
.---------------.
|
||||
| file |
|
||||
'---------------'
|
||||
```
|
||||
|
||||
At the top is the [command line interface](../command-ref/command-ref.md) that drives the underlying layers.
|
||||
|
||||
The [Nix language](../language/index.md) evaluator transforms Nix expressions into self-contained *build plans*, which are used to derive *build results* from referenced *build inputs*.
|
||||
|
||||
The command line interface and Nix expressions are what users deal with most.
|
||||
|
||||
> **Note**
|
||||
> The Nix language itself does not have a notion of *packages* or *configurations*.
|
||||
> As far as we are concerned here, the inputs and results of a build plan are just data.
|
||||
|
||||
Underlying the command line interface and the Nix language evaluator is the [Nix store](../glossary.md#gloss-store), a mechanism to keep track of build plans, data, and references between them.
|
||||
It can also execute build plans to produce new data, which are made available to the operating system as files.
|
||||
|
||||
A build plan itself is a series of *build tasks*, together with their build inputs.
|
||||
|
||||
> **Important**
|
||||
> A build task in Nix is called [derivation](../glossary.md#gloss-derivation).
|
||||
|
||||
Each build task has a special build input executed as *build instructions* in order to perform the build.
|
||||
The result of a build task can be input to another build task.
|
||||
|
||||
The following [data flow diagram] shows a build plan for illustration.
|
||||
Build inputs used as instructions to a build task are marked accordingly:
|
||||
|
||||
[data flow diagram]: https://en.m.wikipedia.org/wiki/Data-flow_diagram
|
||||
|
||||
```
|
||||
+--------------------------------------------------------------------+
|
||||
| build plan |
|
||||
| |
|
||||
| .-------------. |
|
||||
| | build input |---------. |
|
||||
| '-------------' | |
|
||||
| instructions |
|
||||
| | |
|
||||
| v |
|
||||
| .-------------. .----------. |
|
||||
| | build input |-->( build task )-------. |
|
||||
| '-------------' '----------' | |
|
||||
| instructions |
|
||||
| | |
|
||||
| v |
|
||||
| .-------------. .----------. .--------------. |
|
||||
| | build input |---------. ( build task )--->| build result | |
|
||||
| '-------------' | '----------' '--------------' |
|
||||
| instructions ^ |
|
||||
| | | |
|
||||
| v | |
|
||||
| .-------------. .----------. | |
|
||||
| | build input |-->( build task )-------' |
|
||||
| '-------------' '----------' |
|
||||
| ^ |
|
||||
| | |
|
||||
| | |
|
||||
| .-------------. | |
|
||||
| | build input |---------' |
|
||||
| '-------------' |
|
||||
| |
|
||||
+--------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
@@ -16,9 +16,8 @@ By default Nix reads settings from the following places:
|
||||
will be loaded in reverse order.
|
||||
|
||||
Otherwise it will look for `nix/nix.conf` files in `XDG_CONFIG_DIRS`
|
||||
and `XDG_CONFIG_HOME`. If unset, `XDG_CONFIG_DIRS` defaults to
|
||||
`/etc/xdg`, and `XDG_CONFIG_HOME` defaults to `$HOME/.config`
|
||||
as per [XDG Base Directory Specification](https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html).
|
||||
and `XDG_CONFIG_HOME`. If these are unset, it will look in
|
||||
`$HOME/.config/nix.conf`.
|
||||
|
||||
- If `NIX_CONFIG` is set, its contents is treated as the contents of
|
||||
a configuration file.
|
||||
|
||||
@@ -2,18 +2,45 @@
|
||||
|
||||
Most Nix commands interpret the following environment variables:
|
||||
|
||||
- [`IN_NIX_SHELL`]{#env-IN_NIX_SHELL}\
|
||||
- `IN_NIX_SHELL`
|
||||
Indicator that tells if the current environment was set up by
|
||||
`nix-shell`. It can have the values `pure` or `impure`.
|
||||
`nix-shell`. Since Nix 2.0 the values are `"pure"` and `"impure"`
|
||||
|
||||
- [`NIX_PATH`]{#env-NIX_PATH}\
|
||||
A colon-separated list of directories used to look up the location of Nix
|
||||
expressions using [paths](../language/values.md#type-path)
|
||||
enclosed in angle brackets (i.e., `<path>`),
|
||||
e.g. `/home/eelco/Dev:/etc/nixos`. It can be extended using the
|
||||
[`-I` option](./opt-common.md#opt-I).
|
||||
- `NIX_PATH`
|
||||
A colon-separated list of directories used to look up Nix
|
||||
expressions enclosed in angle brackets (i.e., `<path>`). For
|
||||
instance, the value
|
||||
|
||||
/home/eelco/Dev:/etc/nixos
|
||||
|
||||
will cause Nix to look for paths relative to `/home/eelco/Dev` and
|
||||
`/etc/nixos`, in this order. It is also possible to match paths
|
||||
against a prefix. For example, the value
|
||||
|
||||
nixpkgs=/home/eelco/Dev/nixpkgs-branch:/etc/nixos
|
||||
|
||||
will cause Nix to search for `<nixpkgs/path>` in
|
||||
`/home/eelco/Dev/nixpkgs-branch/path` and `/etc/nixos/nixpkgs/path`.
|
||||
|
||||
If a path in the Nix search path starts with `http://` or
|
||||
`https://`, it is interpreted as the URL of a tarball that will be
|
||||
downloaded and unpacked to a temporary location. The tarball must
|
||||
consist of a single top-level directory. For example, setting
|
||||
`NIX_PATH` to
|
||||
|
||||
nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-15.09.tar.gz
|
||||
|
||||
tells Nix to download the latest revision in the Nixpkgs/NixOS 15.09
|
||||
channel.
|
||||
|
||||
A following shorthand can be used to refer to the official channels:
|
||||
|
||||
nixpkgs=channel:nixos-15.09
|
||||
|
||||
The search path can be extended using the `-I` option, which takes
|
||||
precedence over `NIX_PATH`.
|
||||
|
||||
- [`NIX_IGNORE_SYMLINK_STORE`]{#env-NIX_IGNORE_SYMLINK_STORE}\
|
||||
- `NIX_IGNORE_SYMLINK_STORE`
|
||||
Normally, the Nix store directory (typically `/nix/store`) is not
|
||||
allowed to contain any symlink components. This is to prevent
|
||||
“impure” builds. Builders sometimes “canonicalise” paths by
|
||||
@@ -23,7 +50,7 @@ Most Nix commands interpret the following environment variables:
|
||||
builds are deployed to machines where `/nix/store` resolves
|
||||
differently. If you are sure that you’re not going to do that, you
|
||||
can set `NIX_IGNORE_SYMLINK_STORE` to `1`.
|
||||
|
||||
|
||||
Note that if you’re symlinking the Nix store so that you can put it
|
||||
on another file system than the root file system, on Linux you’re
|
||||
better off using `bind` mount points, e.g.,
|
||||
@@ -32,44 +59,44 @@ Most Nix commands interpret the following environment variables:
|
||||
$ mkdir /nix
|
||||
$ mount -o bind /mnt/otherdisk/nix /nix
|
||||
```
|
||||
|
||||
|
||||
Consult the mount 8 manual page for details.
|
||||
|
||||
- [`NIX_STORE_DIR`]{#env-NIX_STORE_DIR}\
|
||||
- `NIX_STORE_DIR`
|
||||
Overrides the location of the Nix store (default `prefix/store`).
|
||||
|
||||
- [`NIX_DATA_DIR`]{#env-NIX_DATA_DIR}\
|
||||
- `NIX_DATA_DIR`
|
||||
Overrides the location of the Nix static data directory (default
|
||||
`prefix/share`).
|
||||
|
||||
- [`NIX_LOG_DIR`]{#env-NIX_LOG_DIR}\
|
||||
- `NIX_LOG_DIR`
|
||||
Overrides the location of the Nix log directory (default
|
||||
`prefix/var/log/nix`).
|
||||
|
||||
- [`NIX_STATE_DIR`]{#env-NIX_STATE_DIR}\
|
||||
- `NIX_STATE_DIR`
|
||||
Overrides the location of the Nix state directory (default
|
||||
`prefix/var/nix`).
|
||||
|
||||
- [`NIX_CONF_DIR`]{#env-NIX_CONF_DIR}\
|
||||
- `NIX_CONF_DIR`
|
||||
Overrides the location of the system Nix configuration directory
|
||||
(default `prefix/etc/nix`).
|
||||
|
||||
- [`NIX_CONFIG`]{#env-NIX_CONFIG}\
|
||||
- `NIX_CONFIG`
|
||||
Applies settings from Nix configuration from the environment.
|
||||
The content is treated as if it was read from a Nix configuration file.
|
||||
Settings are separated by the newline character.
|
||||
|
||||
- [`NIX_USER_CONF_FILES`]{#env-NIX_USER_CONF_FILES}\
|
||||
- `NIX_USER_CONF_FILES`
|
||||
Overrides the location of the user Nix configuration files to load
|
||||
from (defaults to the XDG spec locations). The variable is treated
|
||||
as a list separated by the `:` token.
|
||||
|
||||
- [`TMPDIR`]{#env-TMPDIR}\
|
||||
- `TMPDIR`
|
||||
Use the specified directory to store temporary files. In particular,
|
||||
this includes temporary build directories; these can take up
|
||||
substantial amounts of disk space. The default is `/tmp`.
|
||||
|
||||
- [`NIX_REMOTE`]{#env-NIX_REMOTE}\
|
||||
- `NIX_REMOTE`
|
||||
This variable should be set to `daemon` if you want to use the Nix
|
||||
daemon to execute Nix operations. This is necessary in [multi-user
|
||||
Nix installations](../installation/multi-user.md). If the Nix
|
||||
@@ -77,16 +104,16 @@ Most Nix commands interpret the following environment variables:
|
||||
should be set to `unix://path/to/socket`. Otherwise, it should be
|
||||
left unset.
|
||||
|
||||
- [`NIX_SHOW_STATS`]{#env-NIX_SHOW_STATS}\
|
||||
- `NIX_SHOW_STATS`
|
||||
If set to `1`, Nix will print some evaluation statistics, such as
|
||||
the number of values allocated.
|
||||
|
||||
- [`NIX_COUNT_CALLS`]{#env-NIX_COUNT_CALLS}\
|
||||
- `NIX_COUNT_CALLS`
|
||||
If set to `1`, Nix will print how often functions were called during
|
||||
Nix expression evaluation. This is useful for profiling your Nix
|
||||
expressions.
|
||||
|
||||
- [`GC_INITIAL_HEAP_SIZE`]{#env-GC_INITIAL_HEAP_SIZE}\
|
||||
- `GC_INITIAL_HEAP_SIZE`
|
||||
If Nix has been configured to use the Boehm garbage collector, this
|
||||
variable sets the initial size of the heap in bytes. It defaults to
|
||||
384 MiB. Setting it to a low value reduces memory consumption, but
|
||||
|
||||
@@ -12,12 +12,6 @@
|
||||
[`--dry-run`]
|
||||
[{`--out-link` | `-o`} *outlink*]
|
||||
|
||||
# Disambiguation
|
||||
|
||||
This man page describes the command `nix-build`, which is distinct from `nix
|
||||
build`. For documentation on the latter, run `nix build --help` or see `man
|
||||
nix3-build`.
|
||||
|
||||
# Description
|
||||
|
||||
The `nix-build` command builds the derivations described by the Nix
|
||||
@@ -37,12 +31,10 @@ directory containing at least a file named `default.nix`.
|
||||
|
||||
`nix-build` is essentially a wrapper around
|
||||
[`nix-instantiate`](nix-instantiate.md) (to translate a high-level Nix
|
||||
expression to a low-level [store derivation]) and [`nix-store
|
||||
expression to a low-level store derivation) and [`nix-store
|
||||
--realise`](nix-store.md#operation---realise) (to build the store
|
||||
derivation).
|
||||
|
||||
[store derivation]: ../glossary.md#gloss-store-derivation
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> The result of the build is automatically registered as a root of the
|
||||
@@ -55,18 +47,16 @@ All options not listed here are passed to `nix-store
|
||||
--realise`, except for `--arg` and `--attr` / `-A` which are passed to
|
||||
`nix-instantiate`.
|
||||
|
||||
- <span id="opt-no-out-link">[`--no-out-link`](#opt-no-out-link)<span>
|
||||
|
||||
- `--no-out-link`
|
||||
Do not create a symlink to the output path. Note that as a result
|
||||
the output does not become a root of the garbage collector, and so
|
||||
might be deleted by `nix-store --gc`.
|
||||
|
||||
- <span id="opt-dry-run">[`--dry-run`](#opt-dry-run)</span>
|
||||
might be deleted by `nix-store
|
||||
--gc`.
|
||||
|
||||
- `--dry-run`
|
||||
Show what store paths would be built or downloaded.
|
||||
|
||||
- <span id="opt-out-link">[`--out-link`](#opt-out-link)</span> / `-o` *outlink*
|
||||
|
||||
- `--out-link` / `-o` *outlink*
|
||||
Change the name of the symlink to the output path created from
|
||||
`result` to *outlink*.
|
||||
|
||||
|
||||
@@ -17,26 +17,26 @@ To see the list of official NixOS channels, visit
|
||||
|
||||
This command has the following operations:
|
||||
|
||||
- `--add` *url* \[*name*\]\
|
||||
- `--add` *url* \[*name*\]
|
||||
Adds a channel named *name* with URL *url* to the list of subscribed
|
||||
channels. If *name* is omitted, it defaults to the last component of
|
||||
*url*, with the suffixes `-stable` or `-unstable` removed.
|
||||
|
||||
- `--remove` *name*\
|
||||
- `--remove` *name*
|
||||
Removes the channel named *name* from the list of subscribed
|
||||
channels.
|
||||
|
||||
- `--list`\
|
||||
- `--list`
|
||||
Prints the names and URLs of all subscribed channels on standard
|
||||
output.
|
||||
|
||||
- `--update` \[*names*…\]\
|
||||
- `--update` \[*names*…\]
|
||||
Downloads the Nix expressions of all subscribed channels (or only
|
||||
those included in *names* if specified) and makes them the default
|
||||
for `nix-env` operations (by symlinking them from the directory
|
||||
`~/.nix-defexpr`).
|
||||
|
||||
- `--rollback` \[*generation*\]\
|
||||
- `--rollback` \[*generation*\]
|
||||
Reverts the previous call to `nix-channel
|
||||
--update`. Optionally, you can specify a specific channel generation
|
||||
number to restore.
|
||||
@@ -70,14 +70,14 @@ $ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'
|
||||
|
||||
# Files
|
||||
|
||||
- `/nix/var/nix/profiles/per-user/username/channels`\
|
||||
- `/nix/var/nix/profiles/per-user/username/channels`
|
||||
`nix-channel` uses a `nix-env` profile to keep track of previous
|
||||
versions of the subscribed channels. Every time you run `nix-channel
|
||||
--update`, a new channel generation (that is, a symlink to the
|
||||
channel Nix expressions in the Nix store) is created. This enables
|
||||
`nix-channel --rollback` to revert to previous versions.
|
||||
|
||||
- `~/.nix-defexpr/channels`\
|
||||
- `~/.nix-defexpr/channels`
|
||||
This is a symlink to
|
||||
`/nix/var/nix/profiles/per-user/username/channels`. It ensures that
|
||||
`nix-env` can find your channels. In a multi-user installation, you
|
||||
@@ -89,7 +89,7 @@ $ nix-instantiate --eval -E '(import <nixpkgs> {}).lib.version'
|
||||
A channel URL should point to a directory containing the following
|
||||
files:
|
||||
|
||||
- `nixexprs.tar.xz`\
|
||||
- `nixexprs.tar.xz`
|
||||
A tarball containing Nix expressions and files referenced by them
|
||||
(such as build scripts and patches). At the top level, the tarball
|
||||
should contain a single directory. That directory must contain a
|
||||
|
||||
@@ -30,28 +30,26 @@ Since `nix-copy-closure` calls `ssh`, you may be asked to type in the
|
||||
appropriate password or passphrase. In fact, you may be asked _twice_
|
||||
because `nix-copy-closure` currently connects twice to the remote
|
||||
machine, first to get the set of paths missing on the target machine,
|
||||
and second to send the dump of those paths. When using public key
|
||||
authentication, you can avoid typing the passphrase with `ssh-agent`.
|
||||
and second to send the dump of those paths. If this bothers you, use
|
||||
`ssh-agent`.
|
||||
|
||||
# Options
|
||||
|
||||
- `--to`\
|
||||
- `--to`
|
||||
Copy the closure of _paths_ from the local Nix store to the Nix
|
||||
store on _machine_. This is the default.
|
||||
|
||||
- `--from`\
|
||||
- `--from`
|
||||
Copy the closure of _paths_ from the Nix store on _machine_ to the
|
||||
local Nix store.
|
||||
|
||||
- `--gzip`\
|
||||
- `--gzip`
|
||||
Enable compression of the SSH connection.
|
||||
|
||||
- `--include-outputs`\
|
||||
Also copy the outputs of [store derivation]s included in the closure.
|
||||
- `--include-outputs`
|
||||
Also copy the outputs of store derivations included in the closure.
|
||||
|
||||
[store derivation]: ../glossary.md#gloss-store-derivation
|
||||
|
||||
- `--use-substitutes` / `-s`\
|
||||
- `--use-substitutes` / `-s`
|
||||
Attempt to download missing paths on the target machine using Nix’s
|
||||
substitute mechanism. Any paths that cannot be substituted on the
|
||||
target are still copied normally from the source. This is useful,
|
||||
@@ -60,12 +58,12 @@ authentication, you can avoid typing the passphrase with `ssh-agent`.
|
||||
`nixos.org` (the default binary cache server) is
|
||||
fast.
|
||||
|
||||
- `-v`\
|
||||
- `-v`
|
||||
Show verbose output.
|
||||
|
||||
# Environment variables
|
||||
|
||||
- `NIX_SSHOPTS`\
|
||||
- `NIX_SSHOPTS`
|
||||
Additional options to be passed to `ssh` on the command
|
||||
line.
|
||||
|
||||
|
||||
@@ -8,6 +8,6 @@
|
||||
|
||||
# Description
|
||||
|
||||
The Nix daemon is necessary in multi-user Nix installations. It runs
|
||||
build tasks and other operations on the Nix store on behalf of
|
||||
The Nix daemon is necessary in multi-user Nix installations. It performs
|
||||
build actions and other operations on the Nix store on behalf of
|
||||
unprivileged users.
|
||||
|
||||
@@ -31,32 +31,32 @@ subcommand to be performed. These are documented below.
|
||||
Several commands, such as `nix-env -q` and `nix-env -i`, take a list of
|
||||
arguments that specify the packages on which to operate. These are
|
||||
extended regular expressions that must match the entire name of the
|
||||
package. (For details on regular expressions, see **regex**(7).) The match is
|
||||
package. (For details on regular expressions, see regex7.) The match is
|
||||
case-sensitive. The regular expression can optionally be followed by a
|
||||
dash and a version number; if omitted, any version of the package will
|
||||
match. Here are some examples:
|
||||
|
||||
- `firefox`\
|
||||
- `firefox`
|
||||
Matches the package name `firefox` and any version.
|
||||
|
||||
- `firefox-32.0`\
|
||||
- `firefox-32.0`
|
||||
Matches the package name `firefox` and version `32.0`.
|
||||
|
||||
- `gtk\\+`\
|
||||
- `gtk\\+`
|
||||
Matches the package name `gtk+`. The `+` character must be escaped
|
||||
using a backslash to prevent it from being interpreted as a
|
||||
quantifier, and the backslash must be escaped in turn with another
|
||||
backslash to ensure that the shell passes it on.
|
||||
|
||||
- `.\*`\
|
||||
- `.\*`
|
||||
Matches any package name. This is the default for most commands.
|
||||
|
||||
- `'.*zip.*'`\
|
||||
- `'.*zip.*'`
|
||||
Matches any package name containing the string `zip`. Note the dots:
|
||||
`'*zip*'` does not work, because in a regular expression, the
|
||||
character `*` is interpreted as a quantifier.
|
||||
|
||||
- `'.*(firefox|chromium).*'`\
|
||||
- `'.*(firefox|chromium).*'`
|
||||
Matches any package name containing the strings `firefox` or
|
||||
`chromium`.
|
||||
|
||||
@@ -66,7 +66,7 @@ This section lists the options that are common to all operations. These
|
||||
options are allowed for every subcommand, though they may not always
|
||||
have an effect.
|
||||
|
||||
- `--file` / `-f` *path*\
|
||||
- `--file` / `-f` *path*
|
||||
Specifies the Nix expression (designated below as the *active Nix
|
||||
expression*) used by the `--install`, `--upgrade`, and `--query
|
||||
--available` operations to obtain derivations. The default is
|
||||
@@ -77,13 +77,13 @@ have an effect.
|
||||
unpacked to a temporary location. The tarball must include a single
|
||||
top-level directory containing at least a file named `default.nix`.
|
||||
|
||||
- `--profile` / `-p` *path*\
|
||||
- `--profile` / `-p` *path*
|
||||
Specifies the profile to be used by those operations that operate on
|
||||
a profile (designated below as the *active profile*). A profile is a
|
||||
sequence of user environments called *generations*, one of which is
|
||||
the *current generation*.
|
||||
|
||||
- `--dry-run`\
|
||||
- `--dry-run`
|
||||
For the `--install`, `--upgrade`, `--uninstall`,
|
||||
`--switch-generation`, `--delete-generations` and `--rollback`
|
||||
operations, this flag will cause `nix-env` to print what *would* be
|
||||
@@ -93,7 +93,7 @@ have an effect.
|
||||
[substituted](../glossary.md) (i.e., downloaded) and which paths
|
||||
will be built from source (because no substitute is available).
|
||||
|
||||
- `--system-filter` *system*\
|
||||
- `--system-filter` *system*
|
||||
By default, operations such as `--query
|
||||
--available` show derivations matching any platform. This option
|
||||
allows you to use derivations for the specified platform *system*.
|
||||
@@ -102,7 +102,7 @@ have an effect.
|
||||
|
||||
# Files
|
||||
|
||||
- `~/.nix-defexpr`\
|
||||
- `~/.nix-defexpr`
|
||||
The source for the default Nix expressions used by the
|
||||
`--install`, `--upgrade`, and `--query --available` operations to
|
||||
obtain derivations. The `--file` option may be used to override
|
||||
@@ -140,7 +140,7 @@ have an effect.
|
||||
The command `nix-channel` places symlinks to the downloaded Nix
|
||||
expressions from each subscribed channel in this directory.
|
||||
|
||||
- `~/.nix-profile`\
|
||||
- `~/.nix-profile`
|
||||
A symbolic link to the user's current profile. By default, this
|
||||
symlink points to `prefix/var/nix/profiles/default`. The `PATH`
|
||||
environment variable should include `~/.nix-profile/bin` for the
|
||||
@@ -198,19 +198,17 @@ a number of possible ways:
|
||||
another.
|
||||
|
||||
- If `--from-expression` is given, *args* are Nix
|
||||
[functions](../language/constructs.md#functions)
|
||||
[functions](../expressions/language-constructs.md#functions)
|
||||
that are called with the active Nix expression as their single
|
||||
argument. The derivations returned by those function calls are
|
||||
installed. This allows derivations to be specified in an
|
||||
unambiguous way, which is necessary if there are multiple
|
||||
derivations with the same name.
|
||||
|
||||
- If *args* are [store derivation]s, then these are
|
||||
- If *args* are store derivations, then these are
|
||||
[realised](nix-store.md#operation---realise), and the resulting output paths
|
||||
are installed.
|
||||
|
||||
[store derivation]: ../glossary.md#gloss-store-derivation
|
||||
|
||||
- If *args* are store paths that are not store derivations, then these
|
||||
are [realised](nix-store.md#operation---realise) and installed.
|
||||
|
||||
@@ -219,13 +217,13 @@ a number of possible ways:
|
||||
|
||||
## Flags
|
||||
|
||||
- `--prebuilt-only` / `-b`\
|
||||
- `--prebuilt-only` / `-b`
|
||||
Use only derivations for which a substitute is registered, i.e.,
|
||||
there is a pre-built binary available that can be downloaded in lieu
|
||||
of building the derivation. Thus, no packages will be built from
|
||||
source.
|
||||
|
||||
- `--preserve-installed`; `-P`\
|
||||
- `--preserve-installed`; `-P`
|
||||
Do not remove derivations with a name matching one of the
|
||||
derivations being installed. Usually, trying to have two versions of
|
||||
the same package installed in the same generation of a profile will
|
||||
@@ -233,23 +231,14 @@ a number of possible ways:
|
||||
clashes between the two versions. However, this is not the case for
|
||||
all packages.
|
||||
|
||||
- `--remove-all`; `-r`\
|
||||
- `--remove-all`; `-r`
|
||||
Remove all previously installed packages first. This is equivalent
|
||||
to running `nix-env -e '.*'` first, except that everything happens
|
||||
in a single transaction.
|
||||
|
||||
## Examples
|
||||
|
||||
To install a package using a specific attribute path from the active Nix expression:
|
||||
|
||||
```console
|
||||
$ nix-env -iA gcc40mips
|
||||
installing `gcc-4.0.2'
|
||||
$ nix-env -iA xorg.xorgserver
|
||||
installing `xorg-server-1.2.0'
|
||||
```
|
||||
|
||||
To install a specific version of `gcc` using the derivation name:
|
||||
To install a specific version of `gcc` from the active Nix expression:
|
||||
|
||||
```console
|
||||
$ nix-env --install gcc-3.3.2
|
||||
@@ -257,9 +246,6 @@ installing `gcc-3.3.2'
|
||||
uninstalling `gcc-3.1'
|
||||
```
|
||||
|
||||
Using attribute path for selecting a package is preferred,
|
||||
as it is much faster and there will not be multiple matches.
|
||||
|
||||
Note the previously installed version is removed, since
|
||||
`--preserve-installed` was not specified.
|
||||
|
||||
@@ -270,6 +256,13 @@ $ nix-env --install gcc
|
||||
installing `gcc-3.3.2'
|
||||
```
|
||||
|
||||
To install using a specific attribute:
|
||||
|
||||
```console
|
||||
$ nix-env -i -A gcc40mips
|
||||
$ nix-env -i -A xorg.xorgserver
|
||||
```
|
||||
|
||||
To install all derivations in the Nix expression `foo.nix`:
|
||||
|
||||
```console
|
||||
@@ -282,7 +275,7 @@ To copy the store path with symbolic name `gcc` from another profile:
|
||||
$ nix-env -i --from-profile /nix/var/nix/profiles/foo gcc
|
||||
```
|
||||
|
||||
To install a specific [store derivation] (typically created by
|
||||
To install a specific store derivation (typically created by
|
||||
`nix-instantiate`):
|
||||
|
||||
```console
|
||||
@@ -353,24 +346,24 @@ version is installed.
|
||||
|
||||
## Flags
|
||||
|
||||
- `--lt`\
|
||||
- `--lt`
|
||||
Only upgrade a derivation to newer versions. This is the default.
|
||||
|
||||
- `--leq`\
|
||||
- `--leq`
|
||||
In addition to upgrading to newer versions, also “upgrade” to
|
||||
derivations that have the same version. Version are not a unique
|
||||
identification of a derivation, so there may be many derivations
|
||||
that have the same version. This flag may be useful to force
|
||||
“synchronisation” between the installed and available derivations.
|
||||
|
||||
- `--eq`\
|
||||
- `--eq`
|
||||
*Only* “upgrade” to derivations that have the same version. This may
|
||||
not seem very useful, but it actually is, e.g., when there is a new
|
||||
release of Nixpkgs and you want to replace installed applications
|
||||
with the same versions built against newer dependencies (to reduce
|
||||
the number of dependencies floating around on your system).
|
||||
|
||||
- `--always`\
|
||||
- `--always`
|
||||
In addition to upgrading to newer versions, also “upgrade” to
|
||||
derivations that have the same or a lower version. I.e., derivations
|
||||
may actually be downgraded depending on what is available in the
|
||||
@@ -381,29 +374,22 @@ For the other flags, see `--install`.
|
||||
## Examples
|
||||
|
||||
```console
|
||||
$ nix-env --upgrade -A nixpkgs.gcc
|
||||
$ nix-env --upgrade gcc
|
||||
upgrading `gcc-3.3.1' to `gcc-3.4'
|
||||
```
|
||||
|
||||
When there are no updates available, nothing will happen:
|
||||
|
||||
```console
|
||||
$ nix-env --upgrade -A nixpkgs.pan
|
||||
```
|
||||
|
||||
Using `-A` is preferred when possible, as it is faster and unambiguous but
|
||||
it is also possible to upgrade to a specific version by matching the derivation name:
|
||||
|
||||
```console
|
||||
$ nix-env -u gcc-3.3.2 --always
|
||||
$ nix-env -u gcc-3.3.2 --always (switch to a specific version)
|
||||
upgrading `gcc-3.4' to `gcc-3.3.2'
|
||||
```
|
||||
|
||||
To try to upgrade everything
|
||||
(matching packages based on the part of the derivation name without version):
|
||||
```console
|
||||
$ nix-env --upgrade pan
|
||||
(no upgrades available, so nothing happens)
|
||||
```
|
||||
|
||||
```console
|
||||
$ nix-env -u
|
||||
$ nix-env -u (try to upgrade everything)
|
||||
upgrading `hello-2.1.2' to `hello-2.1.3'
|
||||
upgrading `mozilla-1.2' to `mozilla-1.4'
|
||||
```
|
||||
@@ -414,8 +400,8 @@ The upgrade operation determines whether a derivation `y` is an upgrade
|
||||
of a derivation `x` by looking at their respective `name` attributes.
|
||||
The names (e.g., `gcc-3.3.1` are split into two parts: the package name
|
||||
(`gcc`), and the version (`3.3.1`). The version part starts after the
|
||||
first dash not followed by a letter. `y` is considered an upgrade of `x`
|
||||
if their package names match, and the version of `y` is higher than that
|
||||
first dash not followed by a letter. `x` is considered an upgrade of `y`
|
||||
if their package names match, and the version of `y` is higher that that
|
||||
of `x`.
|
||||
|
||||
The versions are compared by splitting them into contiguous components
|
||||
@@ -592,11 +578,11 @@ The derivations are sorted by their `name` attributes.
|
||||
The following flags specify the set of things on which the query
|
||||
operates.
|
||||
|
||||
- `--installed`\
|
||||
- `--installed`
|
||||
The query operates on the store paths that are installed in the
|
||||
current generation of the active profile. This is the default.
|
||||
|
||||
- `--available`; `-a`\
|
||||
- `--available`; `-a`
|
||||
The query operates on the derivations that are available in the
|
||||
active Nix expression.
|
||||
|
||||
@@ -607,24 +593,24 @@ selected derivations. Multiple flags may be specified, in which case the
|
||||
information is shown in the order given here. Note that the name of the
|
||||
derivation is shown unless `--no-name` is specified.
|
||||
|
||||
- `--xml`\
|
||||
- `--xml`
|
||||
Print the result in an XML representation suitable for automatic
|
||||
processing by other tools. The root element is called `items`, which
|
||||
contains a `item` element for each available or installed
|
||||
derivation. The fields discussed below are all stored in attributes
|
||||
of the `item` elements.
|
||||
|
||||
- `--json`\
|
||||
- `--json`
|
||||
Print the result in a JSON representation suitable for automatic
|
||||
processing by other tools.
|
||||
|
||||
- `--prebuilt-only` / `-b`\
|
||||
- `--prebuilt-only` / `-b`
|
||||
Show only derivations for which a substitute is registered, i.e.,
|
||||
there is a pre-built binary available that can be downloaded in lieu
|
||||
of building the derivation. Thus, this shows all packages that
|
||||
probably can be installed quickly.
|
||||
|
||||
- `--status`; `-s`\
|
||||
- `--status`; `-s`
|
||||
Print the *status* of the derivation. The status consists of three
|
||||
characters. The first is `I` or `-`, indicating whether the
|
||||
derivation is currently installed in the current generation of the
|
||||
@@ -635,49 +621,49 @@ derivation is shown unless `--no-name` is specified.
|
||||
derivation to be built. The third is `S` or `-`, indicating whether
|
||||
a substitute is available for the derivation.
|
||||
|
||||
- `--attr-path`; `-P`\
|
||||
- `--attr-path`; `-P`
|
||||
Print the *attribute path* of the derivation, which can be used to
|
||||
unambiguously select it using the `--attr` option available in
|
||||
commands that install derivations like `nix-env --install`. This
|
||||
option only works together with `--available`
|
||||
|
||||
- `--no-name`\
|
||||
- `--no-name`
|
||||
Suppress printing of the `name` attribute of each derivation.
|
||||
|
||||
- `--compare-versions` / `-c`\
|
||||
- `--compare-versions` / `-c`
|
||||
Compare installed versions to available versions, or vice versa (if
|
||||
`--available` is given). This is useful for quickly seeing whether
|
||||
upgrades for installed packages are available in a Nix expression. A
|
||||
column is added with the following meaning:
|
||||
|
||||
- `<` *version*\
|
||||
- `<` *version*
|
||||
A newer version of the package is available or installed.
|
||||
|
||||
- `=` *version*\
|
||||
- `=` *version*
|
||||
At most the same version of the package is available or
|
||||
installed.
|
||||
|
||||
- `>` *version*\
|
||||
- `>` *version*
|
||||
Only older versions of the package are available or installed.
|
||||
|
||||
- `- ?`\
|
||||
- `- ?`
|
||||
No version of the package is available or installed.
|
||||
|
||||
- `--system`\
|
||||
- `--system`
|
||||
Print the `system` attribute of the derivation.
|
||||
|
||||
- `--drv-path`\
|
||||
Print the path of the [store derivation].
|
||||
- `--drv-path`
|
||||
Print the path of the store derivation.
|
||||
|
||||
- `--out-path`\
|
||||
- `--out-path`
|
||||
Print the output path of the derivation.
|
||||
|
||||
- `--description`\
|
||||
- `--description`
|
||||
Print a short (one-line) description of the derivation, if
|
||||
available. The description is taken from the `meta.description`
|
||||
attribute of the derivation.
|
||||
|
||||
- `--meta`\
|
||||
- `--meta`
|
||||
Print all of the meta-attributes of the derivation. This option is
|
||||
only available with `--xml` or `--json`.
|
||||
|
||||
@@ -888,7 +874,7 @@ error: no generation older than the current (91) exists
|
||||
|
||||
# Environment variables
|
||||
|
||||
- `NIX_PROFILE`\
|
||||
- `NIX_PROFILE`
|
||||
Location of the Nix profile. Defaults to the target of the symlink
|
||||
`~/.nix-profile`, if it exists, or `/nix/var/nix/profiles/default`
|
||||
otherwise.
|
||||
|
||||
@@ -29,29 +29,29 @@ md5sum`.
|
||||
|
||||
# Options
|
||||
|
||||
- `--flat`\
|
||||
- `--flat`
|
||||
Print the cryptographic hash of the contents of each regular file
|
||||
*path*. That is, do not compute the hash over the dump of *path*.
|
||||
The result is identical to that produced by the GNU commands
|
||||
`md5sum` and `sha1sum`.
|
||||
|
||||
- `--base32`\
|
||||
- `--base32`
|
||||
Print the hash in a base-32 representation rather than hexadecimal.
|
||||
This base-32 representation is more compact and can be used in Nix
|
||||
expressions (such as in calls to `fetchurl`).
|
||||
|
||||
- `--truncate`\
|
||||
- `--truncate`
|
||||
Truncate hashes longer than 160 bits (such as SHA-256) to 160 bits.
|
||||
|
||||
- `--type` *hashAlgo*\
|
||||
- `--type` *hashAlgo*
|
||||
Use the specified cryptographic hash algorithm, which can be one of
|
||||
`md5`, `sha1`, `sha256`, and `sha512`.
|
||||
|
||||
- `--to-base16`\
|
||||
- `--to-base16`
|
||||
Don’t hash anything, but convert the base-32 hash representation
|
||||
*hash* to hexadecimal.
|
||||
|
||||
- `--to-base32`\
|
||||
- `--to-base32`
|
||||
Don’t hash anything, but convert the hexadecimal hash representation
|
||||
*hash* to base-32.
|
||||
|
||||
|
||||
@@ -17,59 +17,58 @@
|
||||
|
||||
# Description
|
||||
|
||||
The command `nix-instantiate` produces [store derivation]s from (high-level) Nix expressions.
|
||||
It evaluates the Nix expressions in each of *files* (which defaults to
|
||||
The command `nix-instantiate` generates [store
|
||||
derivations](../glossary.md) from (high-level) Nix expressions. It
|
||||
evaluates the Nix expressions in each of *files* (which defaults to
|
||||
*./default.nix*). Each top-level expression should evaluate to a
|
||||
derivation, a list of derivations, or a set of derivations. The paths
|
||||
of the resulting store derivations are printed on standard output.
|
||||
|
||||
[store derivation]: ../glossary.md#gloss-store-derivation
|
||||
|
||||
If *files* is the character `-`, then a Nix expression will be read from
|
||||
standard input.
|
||||
|
||||
# Options
|
||||
|
||||
- `--add-root` *path*\
|
||||
- `--add-root` *path*
|
||||
See the [corresponding option](nix-store.md) in `nix-store`.
|
||||
|
||||
- `--parse`\
|
||||
- `--parse`
|
||||
Just parse the input files, and print their abstract syntax trees on
|
||||
standard output in ATerm format.
|
||||
|
||||
- `--eval`\
|
||||
- `--eval`
|
||||
Just parse and evaluate the input files, and print the resulting
|
||||
values on standard output. No instantiation of store derivations
|
||||
takes place.
|
||||
|
||||
- `--find-file`\
|
||||
- `--find-file`
|
||||
Look up the given files in Nix’s search path (as specified by the
|
||||
`NIX_PATH` environment variable). If found, print the corresponding
|
||||
absolute paths on standard output. For instance, if `NIX_PATH` is
|
||||
`nixpkgs=/home/alice/nixpkgs`, then `nix-instantiate --find-file
|
||||
nixpkgs/default.nix` will print `/home/alice/nixpkgs/default.nix`.
|
||||
|
||||
- `--strict`\
|
||||
- `--strict`
|
||||
When used with `--eval`, recursively evaluate list elements and
|
||||
attributes. Normally, such sub-expressions are left unevaluated
|
||||
(since the Nix language is lazy).
|
||||
(since the Nix expression language is lazy).
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
> This option can cause non-termination, because lazy data
|
||||
> structures can be infinitely large.
|
||||
|
||||
- `--json`\
|
||||
- `--json`
|
||||
When used with `--eval`, print the resulting value as an JSON
|
||||
representation of the abstract syntax tree rather than as an ATerm.
|
||||
|
||||
- `--xml`\
|
||||
- `--xml`
|
||||
When used with `--eval`, print the resulting value as an XML
|
||||
representation of the abstract syntax tree rather than as an ATerm.
|
||||
The schema is the same as that used by the [`toXML`
|
||||
built-in](../language/builtins.md).
|
||||
built-in](../expressions/builtins.md).
|
||||
|
||||
- `--read-write-mode`\
|
||||
- `--read-write-mode`
|
||||
When used with `--eval`, perform evaluation in read/write mode so
|
||||
nix language features that require it will still work (at the cost
|
||||
of needing to do instantiation of every evaluated derivation). If
|
||||
@@ -80,7 +79,8 @@ standard input.
|
||||
|
||||
# Examples
|
||||
|
||||
Instantiate [store derivation]s from a Nix expression, and build them using `nix-store`:
|
||||
Instantiating store derivations from a Nix expression, and building them
|
||||
using `nix-store`:
|
||||
|
||||
```console
|
||||
$ nix-instantiate test.nix (instantiate)
|
||||
|
||||
@@ -37,22 +37,22 @@ Nix store is also printed.
|
||||
|
||||
# Options
|
||||
|
||||
- `--type` *hashAlgo*\
|
||||
- `--type` *hashAlgo*
|
||||
Use the specified cryptographic hash algorithm, which can be one of
|
||||
`md5`, `sha1`, `sha256`, and `sha512`.
|
||||
|
||||
- `--print-path`\
|
||||
- `--print-path`
|
||||
Print the store path of the downloaded file on standard output.
|
||||
|
||||
- `--unpack`\
|
||||
- `--unpack`
|
||||
Unpack the archive (which must be a tarball or zip file) and add the
|
||||
result to the Nix store. The resulting hash can be used with
|
||||
functions such as Nixpkgs’s `fetchzip` or `fetchFromGitHub`.
|
||||
|
||||
- `--executable`\
|
||||
- `--executable`
|
||||
Set the executable bit on the downloaded file.
|
||||
|
||||
- `--name` *name*\
|
||||
- `--name` *name*
|
||||
Override the name of the file in the Nix store. By default, this is
|
||||
`hash-basename`, where *basename* is the last component of *url*.
|
||||
Overriding the name is necessary when *basename* contains characters
|
||||
|
||||
@@ -11,16 +11,10 @@
|
||||
[`--command` *cmd*]
|
||||
[`--run` *cmd*]
|
||||
[`--exclude` *regexp*]
|
||||
[`--pure`]
|
||||
[`--keep` *name*]
|
||||
[--pure]
|
||||
[--keep *name*]
|
||||
{{`--packages` | `-p`} {*packages* | *expressions*} … | [*path*]}
|
||||
|
||||
# Disambiguation
|
||||
|
||||
This man page describes the command `nix-shell`, which is distinct from `nix
|
||||
shell`. For documentation on the latter, run `nix shell --help` or see `man
|
||||
nix3-shell`.
|
||||
|
||||
# Description
|
||||
|
||||
The command `nix-shell` will build the dependencies of the specified
|
||||
@@ -60,7 +54,7 @@ All options not listed here are passed to `nix-store
|
||||
--realise`, except for `--arg` and `--attr` / `-A` which are passed to
|
||||
`nix-instantiate`.
|
||||
|
||||
- `--command` *cmd*\
|
||||
- `--command` *cmd*
|
||||
In the environment of the derivation, run the shell command *cmd*.
|
||||
This command is executed in an interactive shell. (Use `--run` to
|
||||
use a non-interactive shell instead.) However, a call to `exit` is
|
||||
@@ -70,34 +64,36 @@ All options not listed here are passed to `nix-store
|
||||
drop you into the interactive shell. This can be useful for doing
|
||||
any additional initialisation.
|
||||
|
||||
- `--run` *cmd*\
|
||||
- `--run` *cmd*
|
||||
Like `--command`, but executes the command in a non-interactive
|
||||
shell. This means (among other things) that if you hit Ctrl-C while
|
||||
the command is running, the shell exits.
|
||||
|
||||
- `--exclude` *regexp*\
|
||||
- `--exclude` *regexp*
|
||||
Do not build any dependencies whose store path matches the regular
|
||||
expression *regexp*. This option may be specified multiple times.
|
||||
|
||||
- `--pure`\
|
||||
- `--pure`
|
||||
If this flag is specified, the environment is almost entirely
|
||||
cleared before the interactive shell is started, so you get an
|
||||
environment that more closely corresponds to the “real” Nix build. A
|
||||
few variables, in particular `HOME`, `USER` and `DISPLAY`, are
|
||||
retained.
|
||||
retained. Note that (depending on your Bash
|
||||
installation) `/etc/bashrc` is still sourced, so any variables set
|
||||
there will affect the interactive shell.
|
||||
|
||||
- `--packages` / `-p` *packages*…\
|
||||
- `--packages` / `-p` *packages*…
|
||||
Set up an environment in which the specified packages are present.
|
||||
The command line arguments are interpreted as attribute names inside
|
||||
the Nix Packages collection. Thus, `nix-shell -p libjpeg openjdk`
|
||||
will start a shell in which the packages denoted by the attribute
|
||||
names `libjpeg` and `openjdk` are present.
|
||||
|
||||
- `-i` *interpreter*\
|
||||
- `-i` *interpreter*
|
||||
The chained script interpreter to be invoked by `nix-shell`. Only
|
||||
applicable in `#!`-scripts (described below).
|
||||
|
||||
- `--keep` *name*\
|
||||
- `--keep` *name*
|
||||
When a `--pure` shell is started, keep the listed environment
|
||||
variables.
|
||||
|
||||
@@ -105,10 +101,9 @@ The following common options are supported:
|
||||
|
||||
# Environment variables
|
||||
|
||||
- `NIX_BUILD_SHELL`\
|
||||
- `NIX_BUILD_SHELL`
|
||||
Shell used to start the interactive environment. Defaults to the
|
||||
`bash` found in `<nixpkgs>`, falling back to the `bash` found in
|
||||
`PATH` if not found.
|
||||
`bash` found in `PATH`.
|
||||
|
||||
# Examples
|
||||
|
||||
@@ -117,19 +112,13 @@ shell in which to build it:
|
||||
|
||||
```console
|
||||
$ nix-shell '<nixpkgs>' -A pan
|
||||
[nix-shell]$ eval ${unpackPhase:-unpackPhase}
|
||||
[nix-shell]$ unpackPhase
|
||||
[nix-shell]$ cd pan-*
|
||||
[nix-shell]$ eval ${configurePhase:-configurePhase}
|
||||
[nix-shell]$ eval ${buildPhase:-buildPhase}
|
||||
[nix-shell]$ configurePhase
|
||||
[nix-shell]$ buildPhase
|
||||
[nix-shell]$ ./pan/gui/pan
|
||||
```
|
||||
|
||||
The reason we use form `eval ${configurePhase:-configurePhase}` here is because
|
||||
those packages that override these phases do so by exporting the overridden
|
||||
values in the environment variable of the same name.
|
||||
Here bash is being told to either evaluate the contents of 'configurePhase',
|
||||
if it exists as a variable, otherwise evaluate the configurePhase function.
|
||||
|
||||
To clear the environment first, and do some additional automatic
|
||||
initialisation of the interactive shell:
|
||||
|
||||
@@ -243,23 +232,22 @@ terraform apply
|
||||
> in a nix-shell shebang.
|
||||
|
||||
Finally, using the merging of multiple nix-shell shebangs the following
|
||||
Haskell script uses a specific branch of Nixpkgs/NixOS (the 20.03 stable
|
||||
Haskell script uses a specific branch of Nixpkgs/NixOS (the 18.03 stable
|
||||
branch):
|
||||
|
||||
```haskell
|
||||
#! /usr/bin/env nix-shell
|
||||
#! nix-shell -i runghc -p "haskellPackages.ghcWithPackages (ps: [ps.download-curl ps.tagsoup])"
|
||||
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-20.03.tar.gz
|
||||
#! nix-shell -i runghc -p "haskellPackages.ghcWithPackages (ps: [ps.HTTP ps.tagsoup])"
|
||||
#! nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/nixos-18.03.tar.gz
|
||||
|
||||
import Network.Curl.Download
|
||||
import Network.HTTP
|
||||
import Text.HTML.TagSoup
|
||||
import Data.Either
|
||||
import Data.ByteString.Char8 (unpack)
|
||||
|
||||
-- Fetch nixos.org and print all hrefs.
|
||||
main = do
|
||||
resp <- openURI "https://nixos.org/"
|
||||
let tags = filter (isTagOpenName "a") $ parseTags $ unpack $ fromRight undefined resp
|
||||
resp <- Network.HTTP.simpleHTTP (getRequest "http://nixos.org/")
|
||||
body <- getResponseBody resp
|
||||
let tags = filter (isTagOpenName "a") $ parseTags body
|
||||
let tags' = map (fromAttrib "href") tags
|
||||
mapM_ putStrLn $ filter (/= "") tags'
|
||||
```
|
||||
|
||||
@@ -22,8 +22,7 @@ This section lists the options that are common to all operations. These
|
||||
options are allowed for every subcommand, though they may not always
|
||||
have an effect.
|
||||
|
||||
- <span id="opt-add-root">[`--add-root`](#opt-add-root)</span> *path*
|
||||
|
||||
- `--add-root` *path*
|
||||
Causes the result of a realisation (`--realise` and
|
||||
`--force-realise`) to be registered as a root of the garbage
|
||||
collector. *path* will be created as a symlink to the resulting
|
||||
@@ -72,7 +71,7 @@ paths. Realisation is a somewhat overloaded term:
|
||||
outputs are already valid, in which case we are done
|
||||
immediately. Otherwise, there may be [substitutes](../glossary.md)
|
||||
that produce the outputs (e.g., by downloading them). Finally, the
|
||||
outputs can be produced by running the build task described
|
||||
outputs can be produced by performing the build action described
|
||||
by the derivation.
|
||||
|
||||
- If the store path is not a derivation, realisation ensures that the
|
||||
@@ -80,22 +79,22 @@ paths. Realisation is a somewhat overloaded term:
|
||||
system). If the path is already valid, we are done immediately.
|
||||
Otherwise, the path and any missing paths in its closure may be
|
||||
produced through substitutes. If there are no (successful)
|
||||
substitutes, realisation fails.
|
||||
subsitutes, realisation fails.
|
||||
|
||||
The output path of each derivation is printed on standard output. (For
|
||||
non-derivations argument, the argument itself is printed.)
|
||||
|
||||
The following flags are available:
|
||||
|
||||
- `--dry-run`\
|
||||
- `--dry-run`
|
||||
Print on standard error a description of what packages would be
|
||||
built or downloaded, without actually performing the operation.
|
||||
|
||||
- `--ignore-unknown`\
|
||||
- `--ignore-unknown`
|
||||
If a non-derivation path does not have a substitute, then silently
|
||||
ignore it.
|
||||
|
||||
- `--check`\
|
||||
- `--check`
|
||||
This option allows you to check whether a derivation is
|
||||
deterministic. It rebuilds the specified derivation and checks
|
||||
whether the result is bitwise-identical with the existing outputs,
|
||||
@@ -105,24 +104,28 @@ The following flags are available:
|
||||
previous build, the new output path is left in
|
||||
`/nix/store/name.check.`
|
||||
|
||||
See also the `build-repeat` configuration option, which repeats a
|
||||
derivation a number of times and prevents its outputs from being
|
||||
registered as “valid” in the Nix store unless they are identical.
|
||||
|
||||
Special exit codes:
|
||||
|
||||
- `100`\
|
||||
- `100`
|
||||
Generic build failure, the builder process returned with a non-zero
|
||||
exit code.
|
||||
|
||||
- `101`\
|
||||
- `101`
|
||||
Build timeout, the build was aborted because it did not complete
|
||||
within the specified `timeout`.
|
||||
|
||||
- `102`\
|
||||
- `102`
|
||||
Hash mismatch, the build output was rejected because it does not
|
||||
match the [`outputHash` attribute of the
|
||||
derivation](../language/advanced-attributes.md).
|
||||
derivation](../expressions/advanced-attributes.md).
|
||||
|
||||
- `104`\
|
||||
- `104`
|
||||
Not deterministic, the build succeeded in check mode but the
|
||||
resulting output is not binary reproducible.
|
||||
resulting output is not binary reproducable.
|
||||
|
||||
With the `--keep-going` flag it's possible for multiple failures to
|
||||
occur, in this case the 1xx status codes are or combined using binary
|
||||
@@ -137,10 +140,8 @@ or.
|
||||
|
||||
## Examples
|
||||
|
||||
This operation is typically used to build [store derivation]s produced by
|
||||
[`nix-instantiate`](./nix-instantiate.md):
|
||||
|
||||
[store derivation]: ../glossary.md#gloss-store-derivation
|
||||
This operation is typically used to build store derivations produced by
|
||||
[`nix-instantiate`](nix-instantiate.md):
|
||||
|
||||
```console
|
||||
$ nix-store -r $(nix-instantiate ./test.nix)
|
||||
@@ -155,12 +156,6 @@ To test whether a previously-built derivation is deterministic:
|
||||
$ nix-build '<nixpkgs>' -A hello --check -K
|
||||
```
|
||||
|
||||
Use [`--read-log`](#operation---read-log) to show the stderr and stdout of a build:
|
||||
|
||||
```console
|
||||
$ nix-store --read-log $(nix-instantiate ./test.nix)
|
||||
```
|
||||
|
||||
# Operation `--serve`
|
||||
|
||||
## Synopsis
|
||||
@@ -175,7 +170,7 @@ access to a restricted ssh user.
|
||||
|
||||
The following flags are available:
|
||||
|
||||
- `--write`\
|
||||
- `--write`
|
||||
Allow the connected client to request the realization of
|
||||
derivations. In effect, this can be used to make the host act as a
|
||||
remote builder.
|
||||
@@ -205,18 +200,18 @@ reachable via file system references from a set of “roots”, are deleted.
|
||||
|
||||
The following suboperations may be specified:
|
||||
|
||||
- `--print-roots`\
|
||||
- `--print-roots`
|
||||
This operation prints on standard output the set of roots used by
|
||||
the garbage collector.
|
||||
|
||||
- `--print-live`\
|
||||
- `--print-live`
|
||||
This operation prints on standard output the set of “live” store
|
||||
paths, which are all the store paths reachable from the roots. Live
|
||||
paths should never be deleted, since that would break consistency —
|
||||
it would become possible that applications are installed that
|
||||
reference things that are no longer present in the store.
|
||||
|
||||
- `--print-dead`\
|
||||
- `--print-dead`
|
||||
This operation prints out on standard output the set of “dead” store
|
||||
paths, which is just the opposite of the set of live paths: any path
|
||||
in the store that is not live (with respect to the roots) is dead.
|
||||
@@ -224,7 +219,7 @@ The following suboperations may be specified:
|
||||
By default, all unreachable paths are deleted. The following options
|
||||
control what gets deleted and in what order:
|
||||
|
||||
- `--max-freed` *bytes*\
|
||||
- `--max-freed` *bytes*
|
||||
Keep deleting paths until at least *bytes* bytes have been deleted,
|
||||
then stop. The argument *bytes* can be followed by the
|
||||
multiplicative suffix `K`, `M`, `G` or `T`, denoting KiB, MiB, GiB
|
||||
@@ -305,29 +300,29 @@ symlink.
|
||||
|
||||
## Common query options
|
||||
|
||||
- `--use-output`; `-u`\
|
||||
For each argument to the query that is a [store derivation], apply the
|
||||
- `--use-output`; `-u`
|
||||
For each argument to the query that is a store derivation, apply the
|
||||
query to the output path of the derivation instead.
|
||||
|
||||
- `--force-realise`; `-f`\
|
||||
- `--force-realise`; `-f`
|
||||
Realise each argument to the query first (see [`nix-store
|
||||
--realise`](#operation---realise)).
|
||||
|
||||
## Queries
|
||||
|
||||
- `--outputs`\
|
||||
- `--outputs`
|
||||
Prints out the [output paths](../glossary.md) of the store
|
||||
derivations *paths*. These are the paths that will be produced when
|
||||
the derivation is built.
|
||||
|
||||
- `--requisites`; `-R`\
|
||||
- `--requisites`; `-R`
|
||||
Prints out the [closure](../glossary.md) of the store path *paths*.
|
||||
|
||||
This query has one option:
|
||||
|
||||
- `--include-outputs`
|
||||
Also include the existing output paths of [store derivation]s,
|
||||
and their closures.
|
||||
Also include the output path of store derivations, and their
|
||||
closures.
|
||||
|
||||
This query can be used to implement various kinds of deployment. A
|
||||
*source deployment* is obtained by distributing the closure of a
|
||||
@@ -337,31 +332,31 @@ symlink.
|
||||
dependencies) is obtained by distributing the closure of a store
|
||||
derivation and specifying the option `--include-outputs`.
|
||||
|
||||
- `--references`\
|
||||
- `--references`
|
||||
Prints the set of [references](../glossary.md) of the store paths
|
||||
*paths*, that is, their immediate dependencies. (For *all*
|
||||
dependencies, use `--requisites`.)
|
||||
|
||||
- `--referrers`\
|
||||
- `--referrers`
|
||||
Prints the set of *referrers* of the store paths *paths*, that is,
|
||||
the store paths currently existing in the Nix store that refer to
|
||||
one of *paths*. Note that contrary to the references, the set of
|
||||
referrers is not constant; it can change as store paths are added or
|
||||
removed.
|
||||
|
||||
- `--referrers-closure`\
|
||||
- `--referrers-closure`
|
||||
Prints the closure of the set of store paths *paths* under the
|
||||
referrers relation; that is, all store paths that directly or
|
||||
indirectly refer to one of *paths*. These are all the path currently
|
||||
in the Nix store that are dependent on *paths*.
|
||||
|
||||
- `--deriver`; `-d`\
|
||||
- `--deriver`; `-d`
|
||||
Prints the [deriver](../glossary.md) of the store paths *paths*. If
|
||||
the path has no deriver (e.g., if it is a source file), or if the
|
||||
deriver is not known (e.g., in the case of a binary-only
|
||||
deployment), the string `unknown-deriver` is printed.
|
||||
|
||||
- `--graph`\
|
||||
- `--graph`
|
||||
Prints the references graph of the store paths *paths* in the format
|
||||
of the `dot` tool of AT\&T's [Graphviz
|
||||
package](http://www.graphviz.org/). This can be used to visualise
|
||||
@@ -369,39 +364,39 @@ symlink.
|
||||
this to a store derivation. To obtain a runtime dependency graph,
|
||||
apply it to an output path.
|
||||
|
||||
- `--tree`\
|
||||
- `--tree`
|
||||
Prints the references graph of the store paths *paths* as a nested
|
||||
ASCII tree. References are ordered by descending closure size; this
|
||||
tends to flatten the tree, making it more readable. The query only
|
||||
recurses into a store path when it is first encountered; this
|
||||
prevents a blowup of the tree representation of the graph.
|
||||
|
||||
- `--graphml`\
|
||||
- `--graphml`
|
||||
Prints the references graph of the store paths *paths* in the
|
||||
[GraphML](http://graphml.graphdrawing.org/) file format. This can be
|
||||
used to visualise dependency graphs. To obtain a build-time
|
||||
dependency graph, apply this to a [store derivation]. To obtain a
|
||||
dependency graph, apply this to a store derivation. To obtain a
|
||||
runtime dependency graph, apply it to an output path.
|
||||
|
||||
- `--binding` *name*; `-b` *name*\
|
||||
- `--binding` *name*; `-b` *name*
|
||||
Prints the value of the attribute *name* (i.e., environment
|
||||
variable) of the [store derivation]s *paths*. It is an error for a
|
||||
variable) of the store derivations *paths*. It is an error for a
|
||||
derivation to not have the specified attribute.
|
||||
|
||||
- `--hash`\
|
||||
- `--hash`
|
||||
Prints the SHA-256 hash of the contents of the store paths *paths*
|
||||
(that is, the hash of the output of `nix-store --dump` on the given
|
||||
paths). Since the hash is stored in the Nix database, this is a fast
|
||||
operation.
|
||||
|
||||
- `--size`\
|
||||
- `--size`
|
||||
Prints the size in bytes of the contents of the store paths *paths*
|
||||
— to be precise, the size of the output of `nix-store --dump` on
|
||||
the given paths. Note that the actual disk space required by the
|
||||
store paths may be higher, especially on filesystems with large
|
||||
cluster sizes.
|
||||
|
||||
- `--roots`\
|
||||
- `--roots`
|
||||
Prints the garbage collector roots that point, directly or
|
||||
indirectly, at the store paths *paths*.
|
||||
|
||||
@@ -518,7 +513,7 @@ public url or broke since the download expression was written.
|
||||
|
||||
This operation has the following options:
|
||||
|
||||
- `--recursive`\
|
||||
- `--recursive`
|
||||
Use recursive instead of flat hashing mode, used when adding
|
||||
directories to the store.
|
||||
|
||||
@@ -545,14 +540,14 @@ being modified by non-Nix tools, or of bugs in Nix itself.
|
||||
|
||||
This operation has the following options:
|
||||
|
||||
- `--check-contents`\
|
||||
- `--check-contents`
|
||||
Checks that the contents of every valid store path has not been
|
||||
altered by computing a SHA-256 hash of the contents and comparing it
|
||||
with the hash stored in the Nix database at build time. Paths that
|
||||
have been modified are printed out. For large stores,
|
||||
`--check-contents` is obviously quite slow.
|
||||
|
||||
- `--repair`\
|
||||
- `--repair`
|
||||
If any valid path is missing from the store, or (if
|
||||
`--check-contents` is given) the contents of a valid path has been
|
||||
modified, then try to repair the path by redownloading it. See
|
||||
|
||||
@@ -2,56 +2,56 @@
|
||||
|
||||
Most Nix commands accept the following command-line options:
|
||||
|
||||
- [`--help`]{#opt-help}\
|
||||
- `--help`
|
||||
Prints out a summary of the command syntax and exits.
|
||||
|
||||
- [`--version`]{#opt-version}\
|
||||
- `--version`
|
||||
Prints out the Nix version number on standard output and exits.
|
||||
|
||||
- [`--verbose`]{#opt-verbose} / `-v`\
|
||||
- `--verbose` / `-v`
|
||||
Increases the level of verbosity of diagnostic messages printed on
|
||||
standard error. For each Nix operation, the information printed on
|
||||
standard output is well-defined; any diagnostic information is
|
||||
printed on standard error, never on standard output.
|
||||
|
||||
|
||||
This option may be specified repeatedly. Currently, the following
|
||||
verbosity levels exist:
|
||||
|
||||
- 0\
|
||||
|
||||
- 0
|
||||
“Errors only”: only print messages explaining why the Nix
|
||||
invocation failed.
|
||||
|
||||
- 1\
|
||||
|
||||
- 1
|
||||
“Informational”: print *useful* messages about what Nix is
|
||||
doing. This is the default.
|
||||
|
||||
- 2\
|
||||
|
||||
- 2
|
||||
“Talkative”: print more informational messages.
|
||||
|
||||
- 3\
|
||||
|
||||
- 3
|
||||
“Chatty”: print even more informational messages.
|
||||
|
||||
- 4\
|
||||
|
||||
- 4
|
||||
“Debug”: print debug information.
|
||||
|
||||
- 5\
|
||||
|
||||
- 5
|
||||
“Vomit”: print vast amounts of debug information.
|
||||
|
||||
- [`--quiet`]{#opt-quiet}\
|
||||
- `--quiet`
|
||||
Decreases the level of verbosity of diagnostic messages printed on
|
||||
standard error. This is the inverse option to `-v` / `--verbose`.
|
||||
|
||||
|
||||
This option may be specified repeatedly. See the previous verbosity
|
||||
levels list.
|
||||
|
||||
- [`--log-format`]{#opt-log-format} *format*\
|
||||
- `--log-format` *format*
|
||||
This option can be used to change the output of the log format, with
|
||||
*format* being one of:
|
||||
|
||||
- raw\
|
||||
|
||||
- raw
|
||||
This is the raw format, as outputted by nix-build.
|
||||
|
||||
- internal-json\
|
||||
|
||||
- internal-json
|
||||
Outputs the logs in a structured manner.
|
||||
|
||||
> **Warning**
|
||||
@@ -60,30 +60,30 @@ Most Nix commands accept the following command-line options:
|
||||
> the error-messages (namely of the `msg`-field) can change
|
||||
> between releases.
|
||||
|
||||
- bar\
|
||||
- bar
|
||||
Only display a progress bar during the builds.
|
||||
|
||||
- bar-with-logs\
|
||||
|
||||
- bar-with-logs
|
||||
Display the raw logs, with the progress bar at the bottom.
|
||||
|
||||
- [`--no-build-output`]{#opt-no-build-output} / `-Q`\
|
||||
- `--no-build-output` / `-Q`
|
||||
By default, output written by builders to standard output and
|
||||
standard error is echoed to the Nix command's standard error. This
|
||||
option suppresses this behaviour. Note that the builder's standard
|
||||
output and error are always written to a log file in
|
||||
`prefix/nix/var/log/nix`.
|
||||
|
||||
- [`--max-jobs`]{#opt-max-jobs} / `-j` *number*\
|
||||
- `--max-jobs` / `-j` *number*
|
||||
Sets the maximum number of build jobs that Nix will perform in
|
||||
parallel to the specified number. Specify `auto` to use the number
|
||||
of CPUs in the system. The default is specified by the `max-jobs`
|
||||
configuration setting, which itself defaults to `1`. A higher
|
||||
value is useful on SMP systems or to exploit I/O latency.
|
||||
|
||||
|
||||
Setting it to `0` disallows building on the local machine, which is
|
||||
useful when you want builds to happen only on remote builders.
|
||||
|
||||
- [`--cores`]{#opt-cores}\
|
||||
- `--cores`
|
||||
Sets the value of the `NIX_BUILD_CORES` environment variable in
|
||||
the invocation of builders. Builders can use this variable at
|
||||
their discretion to control the maximum amount of parallelism. For
|
||||
@@ -94,18 +94,18 @@ Most Nix commands accept the following command-line options:
|
||||
means that the builder should use all available CPU cores in the
|
||||
system.
|
||||
|
||||
- [`--max-silent-time`]{#opt-max-silent-time}\
|
||||
- `--max-silent-time`
|
||||
Sets the maximum number of seconds that a builder can go without
|
||||
producing any data on standard output or standard error. The
|
||||
default is specified by the `max-silent-time` configuration
|
||||
setting. `0` means no time-out.
|
||||
|
||||
- [`--timeout`]{#opt-timeout}\
|
||||
- `--timeout`
|
||||
Sets the maximum number of seconds that a builder can run. The
|
||||
default is specified by the `timeout` configuration setting. `0`
|
||||
means no timeout.
|
||||
|
||||
- [`--keep-going`]{#opt-keep-going} / `-k`\
|
||||
- `--keep-going` / `-k`
|
||||
Keep going in case of failed builds, to the greatest extent
|
||||
possible. That is, if building an input of some derivation fails,
|
||||
Nix will still build the other inputs, but not the derivation
|
||||
@@ -113,17 +113,17 @@ Most Nix commands accept the following command-line options:
|
||||
for builds of substitutes), possibly killing builds in progress (in
|
||||
case of parallel or distributed builds).
|
||||
|
||||
- [`--keep-failed`]{#opt-keep-failed} / `-K`\
|
||||
- `--keep-failed` / `-K`
|
||||
Specifies that in case of a build failure, the temporary directory
|
||||
(usually in `/tmp`) in which the build takes place should not be
|
||||
deleted. The path of the build directory is printed as an
|
||||
informational message.
|
||||
|
||||
- [`--fallback`]{#opt-fallback}\
|
||||
- `--fallback`
|
||||
Whenever Nix attempts to build a derivation for which substitutes
|
||||
are known for each output path, but realising the output paths
|
||||
through the substitutes fails, fall back on building the derivation.
|
||||
|
||||
|
||||
The most common scenario in which this is useful is when we have
|
||||
registered substitutes in order to perform binary distribution from,
|
||||
say, a network repository. If the repository is down, the
|
||||
@@ -134,24 +134,33 @@ Most Nix commands accept the following command-line options:
|
||||
failure in obtaining the substitutes to lead to a full build from
|
||||
source (with the related consumption of resources).
|
||||
|
||||
- [`--readonly-mode`]{#opt-readonly-mode}\
|
||||
- `--no-build-hook`
|
||||
Disables the build hook mechanism. This allows to ignore remote
|
||||
builders if they are setup on the machine.
|
||||
|
||||
It's useful in cases where the bandwidth between the client and the
|
||||
remote builder is too low. In that case it can take more time to
|
||||
upload the sources to the remote builder and fetch back the result
|
||||
than to do the computation locally.
|
||||
|
||||
- `--readonly-mode`
|
||||
When this option is used, no attempt is made to open the Nix
|
||||
database. Most Nix operations do need database access, so those
|
||||
operations will fail.
|
||||
|
||||
- [`--arg`]{#opt-arg} *name* *value*\
|
||||
- `--arg` *name* *value*
|
||||
This option is accepted by `nix-env`, `nix-instantiate`,
|
||||
`nix-shell` and `nix-build`. When evaluating Nix expressions, the
|
||||
expression evaluator will automatically try to call functions that
|
||||
it encounters. It can automatically call functions for which every
|
||||
argument has a [default
|
||||
value](../language/constructs.md#functions) (e.g.,
|
||||
value](../expressions/language-constructs.md#functions) (e.g.,
|
||||
`{ argName ? defaultValue }: ...`). With `--arg`, you can also
|
||||
call functions that have arguments without a default value (or
|
||||
override a default value). That is, if the evaluator encounters a
|
||||
function with an argument named *name*, it will call it with value
|
||||
*value*.
|
||||
|
||||
|
||||
For instance, the top-level `default.nix` in Nixpkgs is actually a
|
||||
function:
|
||||
|
||||
@@ -161,22 +170,22 @@ Most Nix commands accept the following command-line options:
|
||||
...
|
||||
}: ...
|
||||
```
|
||||
|
||||
So if you call this Nix expression (e.g., when you do `nix-env -iA
|
||||
|
||||
So if you call this Nix expression (e.g., when you do `nix-env -i
|
||||
pkgname`), the function will be called automatically using the
|
||||
value [`builtins.currentSystem`](../language/builtins.md) for
|
||||
value [`builtins.currentSystem`](../expressions/builtins.md) for
|
||||
the `system` argument. You can override this using `--arg`, e.g.,
|
||||
`nix-env -iA pkgname --arg system \"i686-freebsd\"`. (Note that
|
||||
`nix-env -i pkgname --arg system \"i686-freebsd\"`. (Note that
|
||||
since the argument is a Nix string literal, you have to escape the
|
||||
quotes.)
|
||||
|
||||
- [`--argstr`]{#opt-argstr} *name* *value*\
|
||||
- `--argstr` *name* *value*
|
||||
This option is like `--arg`, only the value is not a Nix
|
||||
expression but a string. So instead of `--arg system
|
||||
\"i686-linux\"` (the outer quotes are to keep the shell happy) you
|
||||
can say `--argstr system i686-linux`.
|
||||
|
||||
- [`--attr`]{#opt-attr} / `-A` *attrPath*\
|
||||
- `--attr` / `-A` *attrPath*
|
||||
Select an attribute from the top-level Nix expression being
|
||||
evaluated. (`nix-env`, `nix-instantiate`, `nix-build` and
|
||||
`nix-shell` only.) The *attribute path* *attrPath* is a sequence
|
||||
@@ -185,34 +194,34 @@ Most Nix commands accept the following command-line options:
|
||||
would cause the expression `e.xorg.xorgserver` to be used. See
|
||||
[`nix-env --install`](nix-env.md#operation---install) for some
|
||||
concrete examples.
|
||||
|
||||
|
||||
In addition to attribute names, you can also specify array indices.
|
||||
For instance, the attribute path `foo.3.bar` selects the `bar`
|
||||
attribute of the fourth element of the array in the `foo` attribute
|
||||
of the top-level expression.
|
||||
|
||||
- [`--expr`]{#opt-expr} / `-E`\
|
||||
- `--expr` / `-E`
|
||||
Interpret the command line arguments as a list of Nix expressions to
|
||||
be parsed and evaluated, rather than as a list of file names of Nix
|
||||
expressions. (`nix-instantiate`, `nix-build` and `nix-shell` only.)
|
||||
|
||||
|
||||
For `nix-shell`, this option is commonly used to give you a shell in
|
||||
which you can build the packages returned by the expression. If you
|
||||
want to get a shell which contain the *built* packages ready for
|
||||
use, give your expression to the `nix-shell -p` convenience flag
|
||||
instead.
|
||||
|
||||
- [`-I`]{#opt-I} *path*\
|
||||
- `-I` *path*
|
||||
Add a path to the Nix expression search path. This option may be
|
||||
given multiple times. See the `NIX_PATH` environment variable for
|
||||
information on the semantics of the Nix search path. Paths added
|
||||
through `-I` take precedence over `NIX_PATH`.
|
||||
|
||||
- [`--option`]{#opt-option} *name* *value*\
|
||||
- `--option` *name* *value*
|
||||
Set the Nix configuration option *name* to *value*. This overrides
|
||||
settings in the Nix configuration file (see nix.conf5).
|
||||
|
||||
- [`--repair`]{#opt-repair}\
|
||||
- `--repair`
|
||||
Fix corrupted or missing store paths by redownloading or rebuilding
|
||||
them. Note that this is slow because it requires computing a
|
||||
cryptographic hash of the contents of every path in the closure of
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## Goals
|
||||
|
||||
Purpose of this document is to provide a clear direction to **help design
|
||||
delightful command line** experience. This document contains guidelines to
|
||||
delightful command line** experience. This document contain guidelines to
|
||||
follow to ensure a consistent and approachable user experience.
|
||||
|
||||
## Overview
|
||||
@@ -103,7 +103,7 @@ impacted the most by bad user experience.
|
||||
# Help is essential
|
||||
|
||||
Help should be built into your command line so that new users can gradually
|
||||
discover new features when they need them.
|
||||
discover new features when they need them.
|
||||
|
||||
## Looking for help
|
||||
|
||||
@@ -115,7 +115,7 @@ The rules are:
|
||||
|
||||
- Help is shown by using `--help` or `help` command (eg `nix` `--``help` or
|
||||
`nix help`).
|
||||
- For non-COMMANDs (eg. `nix` `--``help` and `nix store` `--``help`) we **show
|
||||
- For non-COMMANDs (eg. `nix` `--``help` and `nix store` `--``help`) we **show
|
||||
a summary** of most common use cases. Summary is presented on the STDOUT
|
||||
without any use of PAGER.
|
||||
- For COMMANDs (eg. `nix init` `--``help` or `nix help init`) we display the
|
||||
@@ -176,7 +176,7 @@ $ nix init --template=template#pyton
|
||||
------------------------------------------------------------------------
|
||||
Initializing Nix project at `/path/to/here`.
|
||||
Select a template for you new project:
|
||||
|> template#python
|
||||
|> template#pyton
|
||||
template#python-pip
|
||||
template#python-poetry
|
||||
```
|
||||
@@ -230,17 +230,17 @@ Now **Learn** part of the output is where you educate users. You should only
|
||||
show it when you know that a build will take some time and not annoy users of
|
||||
the builds that take only few seconds.
|
||||
|
||||
Every feature like this should go through an intensive review and testing to
|
||||
collect as much feedback as possible and to fine tune every little detail. If
|
||||
Every feature like this should go though a intensive review and testing to
|
||||
collect as much a feedback as possible and to fine tune every little detail. If
|
||||
done right this can be an awesome features beginners and advance users will
|
||||
love, but if not done perfectly it will annoy users and leave bad impression.
|
||||
|
||||
# Input
|
||||
|
||||
Input to a command is provided via `ARGUMENTS` and `OPTIONS`.
|
||||
Input to a command is provided via `ARGUMENTS` and `OPTIONS`.
|
||||
|
||||
`ARGUMENTS` represent a required input for a function. When choosing to use
|
||||
`ARGUMENTS` over `OPTIONS` please be aware of the downsides that come with it:
|
||||
`ARGUMENT` over function please be aware of the downsides that come with it:
|
||||
|
||||
- User will need to remember the order of `ARGUMENTS`. This is not a problem if
|
||||
there is only one `ARGUMENT`.
|
||||
@@ -253,7 +253,7 @@ developer consider the downsides and choose wisely.
|
||||
|
||||
## Naming the `OPTIONS`
|
||||
|
||||
The only naming convention - apart from the ones mentioned in Naming the
|
||||
Then only naming convention - apart from the ones mentioned in Naming the
|
||||
`COMMANDS` section is how flags are named.
|
||||
|
||||
Flags are a type of `OPTION` that represent an option that can be turned ON of
|
||||
@@ -271,12 +271,12 @@ to improve the discoverability of possible input. A new user will most likely
|
||||
not know which `ARGUMENTS` and `OPTIONS` are required or which values are
|
||||
possible for those options.
|
||||
|
||||
In case the user does not provide the input or they provide wrong input,
|
||||
rather than show the error, prompt a user with an option to find and select
|
||||
In cases, the user might not provide the input or they provide wrong input,
|
||||
rather then show the error, prompt a user with an option to find and select
|
||||
correct input (see examples).
|
||||
|
||||
Prompting is of course not required when TTY is not attached to STDIN. This
|
||||
would mean that scripts won't need to handle prompt, but rather handle errors.
|
||||
would mean that scripts wont need to handle prompt, but rather handle errors.
|
||||
|
||||
A place to use prompt and provide user with interactive select
|
||||
|
||||
@@ -300,9 +300,9 @@ going to happen.
|
||||
```shell
|
||||
$ nix build --option substitutors https://cache.example.org
|
||||
------------------------------------------------------------------------
|
||||
Warning! A security related question needs to be answered.
|
||||
Warning! A security related question need to be answered.
|
||||
------------------------------------------------------------------------
|
||||
The following substitutors will be used to in `my-project`:
|
||||
The following substitutors will be used to in `my-project`:
|
||||
- https://cache.example.org
|
||||
|
||||
Do you allow `my-project` to use above mentioned substitutors?
|
||||
@@ -311,14 +311,14 @@ $ nix build --option substitutors https://cache.example.org
|
||||
|
||||
# Output
|
||||
|
||||
Terminal output can be quite limiting in many ways. Which should force us to
|
||||
Terminal output can be quite limiting in many ways. Which should forces us to
|
||||
think about the experience even more. As with every design the output is a
|
||||
compromise between being terse and being verbose, between showing help to
|
||||
beginners and annoying advance users. For this it is important that we know
|
||||
what are the priorities.
|
||||
|
||||
Nix command line should be first and foremost written with beginners in mind.
|
||||
But users won't stay beginners for long and what was once useful might quickly
|
||||
But users wont stay beginners for long and what was once useful might quickly
|
||||
become annoying. There is no golden rule that we can give in this guideline
|
||||
that would make it easier how to draw a line and find best compromise.
|
||||
|
||||
@@ -342,7 +342,7 @@ also allowing them to redirect content to a file. For example:
|
||||
```shell
|
||||
$ nix build > build.txt
|
||||
------------------------------------------------------------------------
|
||||
Error! Attribute `bin` missing at (1:94) from string.
|
||||
Error! Atrribute `bin` missing at (1:94) from string.
|
||||
------------------------------------------------------------------------
|
||||
|
||||
1| with import <nixpkgs> { }; (pkgs.runCommandCC or pkgs.runCommand) "shell" { buildInputs = [ (surge.bin) ]; } ""
|
||||
@@ -408,7 +408,7 @@ Above command clearly states that command successfully completed. And in case
|
||||
of `nix build`, which is a command that might take some time to complete, it is
|
||||
equally important to also show that a command started.
|
||||
|
||||
## Text alignment
|
||||
## Text alignment
|
||||
|
||||
Text alignment is the number one design element that will present all of the
|
||||
Nix commands as a family and not as separate tools glued together.
|
||||
@@ -419,7 +419,7 @@ The format we should follow is:
|
||||
$ nix COMMAND
|
||||
VERB_1 NOUN and other words
|
||||
VERB__1 NOUN and other words
|
||||
|> Some details
|
||||
|> Some details
|
||||
```
|
||||
|
||||
Few rules that we can extract from above example:
|
||||
@@ -444,13 +444,13 @@ is not even notable, therefore relying on it wouldn’t make much sense.
|
||||
|
||||
**The bright text is much better supported** across terminals and color
|
||||
schemes. Most of the time the difference is perceived as if the bright text
|
||||
would be bold.
|
||||
would be bold.
|
||||
|
||||
## Colors
|
||||
|
||||
Humans are already conditioned by society to attach certain meaning to certain
|
||||
colors. While the meaning is not universal, a simple collection of colors is
|
||||
used to represent basic emotions.
|
||||
used to represent basic emotions.
|
||||
|
||||
Colors that can be used in output
|
||||
|
||||
@@ -508,7 +508,7 @@ can, with a few key strokes, be changed into and advance introspection tool.
|
||||
|
||||
### Progress
|
||||
|
||||
For longer running commands we should provide and overview the progress.
|
||||
For longer running commands we should provide and overview of the progress.
|
||||
This is shown best in `nix build` example:
|
||||
|
||||
```shell
|
||||
@@ -553,9 +553,9 @@ going to happen.
|
||||
```shell
|
||||
$ nix build --option substitutors https://cache.example.org
|
||||
------------------------------------------------------------------------
|
||||
Warning! A security related question needs to be answered.
|
||||
Warning! A security related question need to be answered.
|
||||
------------------------------------------------------------------------
|
||||
The following substitutors will be used to in `my-project`:
|
||||
The following substitutors will be used to in `my-project`:
|
||||
- https://cache.example.org
|
||||
|
||||
Do you allow `my-project` to use above mentioned substitutors?
|
||||
@@ -566,7 +566,7 @@ $ nix build --option substitutors https://cache.example.org
|
||||
|
||||
There are many ways that you can control verbosity.
|
||||
|
||||
Verbosity levels are:
|
||||
Verbosity levels are:
|
||||
|
||||
- `ERROR` (level 0)
|
||||
- `WARN` (level 1)
|
||||
@@ -586,4 +586,4 @@ There are also two shortcuts, `--debug` to run in `DEBUG` verbosity level and
|
||||
|
||||
# Appendix 1: Commands naming exceptions
|
||||
|
||||
`nix init` and `nix repl` are well established
|
||||
`nix init` and `nix repl` are well established
|
||||
|
||||
@@ -35,28 +35,6 @@ variables are set up so that those dependencies can be found:
|
||||
$ nix-shell
|
||||
```
|
||||
|
||||
or if you have a flake-enabled nix:
|
||||
|
||||
```console
|
||||
$ nix develop
|
||||
```
|
||||
|
||||
To get a shell with a different compilation environment (e.g. stdenv,
|
||||
gccStdenv, clangStdenv, clang11Stdenv, ccacheStdenv):
|
||||
|
||||
```console
|
||||
$ nix-shell -A devShells.x86_64-linux.clang11StdenvPackages
|
||||
```
|
||||
|
||||
or if you have a flake-enabled nix:
|
||||
|
||||
```console
|
||||
$ nix develop .#clang11StdenvPackages
|
||||
```
|
||||
|
||||
Note: you can use `ccacheStdenv` to drastically improve rebuild
|
||||
time. By default, ccache keeps artifacts in `~/.cache/ccache/`.
|
||||
|
||||
To build Nix itself in this shell:
|
||||
|
||||
```console
|
||||
@@ -74,6 +52,18 @@ To install it in `$(pwd)/outputs` and test it:
|
||||
nix (Nix) 3.0
|
||||
```
|
||||
|
||||
To run a functional test:
|
||||
|
||||
```console
|
||||
make tests/test-name-should-auto-complete.sh.test
|
||||
```
|
||||
|
||||
To run the unit-tests for C++ code:
|
||||
|
||||
```
|
||||
make check
|
||||
```
|
||||
|
||||
If you have a flakes-enabled Nix you can replace:
|
||||
|
||||
```console
|
||||
@@ -85,200 +75,3 @@ by:
|
||||
```console
|
||||
$ nix develop
|
||||
```
|
||||
|
||||
## Running tests
|
||||
|
||||
### Unit-tests
|
||||
|
||||
The unit-tests for each Nix library (`libexpr`, `libstore`, etc..) are defined
|
||||
under `src/{library_name}/tests` using the
|
||||
[googletest](https://google.github.io/googletest/) framework.
|
||||
|
||||
You can run the whole testsuite with `make check`, or the tests for a specific component with `make libfoo-tests_RUN`. Finer-grained filtering is also possible using the [--gtest_filter](https://google.github.io/googletest/advanced.html#running-a-subset-of-the-tests) command-line option.
|
||||
|
||||
### Functional tests
|
||||
|
||||
The functional tests reside under the `tests` directory and are listed in `tests/local.mk`.
|
||||
Each test is a bash script.
|
||||
|
||||
The whole test suite can be run with:
|
||||
|
||||
```shell-session
|
||||
$ make install && make installcheck
|
||||
ran test tests/foo.sh... [PASS]
|
||||
ran test tests/bar.sh... [PASS]
|
||||
...
|
||||
```
|
||||
|
||||
Individual tests can be run with `make`:
|
||||
|
||||
```shell-session
|
||||
$ make tests/${testName}.sh.test
|
||||
ran test tests/${testName}.sh... [PASS]
|
||||
```
|
||||
|
||||
or without `make`:
|
||||
|
||||
```shell-session
|
||||
$ ./mk/run-test.sh tests/${testName}.sh
|
||||
ran test tests/${testName}.sh... [PASS]
|
||||
```
|
||||
|
||||
To see the complete output, one can also run:
|
||||
|
||||
```shell-session
|
||||
$ ./mk/debug-test.sh tests/${testName}.sh
|
||||
+ foo
|
||||
output from foo
|
||||
+ bar
|
||||
output from bar
|
||||
...
|
||||
```
|
||||
|
||||
The test script will then be traced with `set -x` and the output displayed as it happens, regardless of whether the test succeeds or fails.
|
||||
|
||||
#### Debugging failing functional tests
|
||||
|
||||
When a functional test fails, it usually does so somewhere in the middle of the script.
|
||||
|
||||
To figure out what's wrong, it is convenient to run the test regularly up to the failing `nix` command, and then run that command with a debugger like GDB.
|
||||
|
||||
For example, if the script looks like:
|
||||
|
||||
```bash
|
||||
foo
|
||||
nix blah blub
|
||||
bar
|
||||
```
|
||||
edit it like so:
|
||||
|
||||
```diff
|
||||
foo
|
||||
-nix blah blub
|
||||
+gdb --args nix blah blub
|
||||
bar
|
||||
```
|
||||
|
||||
Then, running the test with `./mk/debug-test.sh` will drop you into GDB once the script reaches that point:
|
||||
|
||||
```shell-session
|
||||
$ ./mk/debug-test.sh tests/${testName}.sh
|
||||
...
|
||||
+ gdb blash blub
|
||||
GNU gdb (GDB) 12.1
|
||||
...
|
||||
(gdb)
|
||||
```
|
||||
|
||||
One can debug the Nix invocation in all the usual ways.
|
||||
For example, enter `run` to start the Nix invocation.
|
||||
|
||||
### Integration tests
|
||||
|
||||
The integration tests are defined in the Nix flake under the `hydraJobs.tests` attribute.
|
||||
These tests include everything that needs to interact with external services or run Nix in a non-trivial distributed setup.
|
||||
Because these tests are expensive and require more than what the standard github-actions setup provides, they only run on the master branch (on <https://hydra.nixos.org/jobset/nix/master>).
|
||||
|
||||
You can run them manually with `nix build .#hydraJobs.tests.{testName}` or `nix-build -A hydraJobs.tests.{testName}`
|
||||
|
||||
### Installer tests
|
||||
|
||||
After a one-time setup, the Nix repository's GitHub Actions continuous integration (CI) workflow can test the installer each time you push to a branch.
|
||||
|
||||
Creating a Cachix cache for your installer tests and adding its authorization token to GitHub enables [two installer-specific jobs in the CI workflow](https://github.com/NixOS/nix/blob/88a45d6149c0e304f6eb2efcc2d7a4d0d569f8af/.github/workflows/ci.yml#L50-L91):
|
||||
|
||||
- The `installer` job generates installers for the platforms below and uploads them to your Cachix cache:
|
||||
- `x86_64-linux`
|
||||
- `armv6l-linux`
|
||||
- `armv7l-linux`
|
||||
- `x86_64-darwin`
|
||||
|
||||
- The `installer_test` job (which runs on `ubuntu-latest` and `macos-latest`) will try to install Nix with the cached installer and run a trivial Nix command.
|
||||
|
||||
#### One-time setup
|
||||
|
||||
1. Have a GitHub account with a fork of the [Nix repository](https://github.com/NixOS/nix).
|
||||
2. At cachix.org:
|
||||
- Create or log in to an account.
|
||||
- Create a Cachix cache using the format `<github-username>-nix-install-tests`.
|
||||
- Navigate to the new cache > Settings > Auth Tokens.
|
||||
- Generate a new Cachix auth token and copy the generated value.
|
||||
3. At github.com:
|
||||
- Navigate to your Nix fork > Settings > Secrets > Actions > New repository secret.
|
||||
- Name the secret `CACHIX_AUTH_TOKEN`.
|
||||
- Paste the copied value of the Cachix cache auth token.
|
||||
|
||||
#### Using the CI-generated installer for manual testing
|
||||
|
||||
After the CI run completes, you can check the output to extract the installer URL:
|
||||
1. Click into the detailed view of the CI run.
|
||||
2. Click into any `installer_test` run (the URL you're here to extract will be the same in all of them).
|
||||
3. Click into the `Run cachix/install-nix-action@v...` step and click the detail triangle next to the first log line (it will also be `Run cachix/install-nix-action@v...`)
|
||||
4. Copy the value of `install_url`
|
||||
5. To generate an install command, plug this `install_url` and your GitHub username into this template:
|
||||
|
||||
```console
|
||||
sh <(curl -L <install_url>) --tarball-url-prefix https://<github-username>-nix-install-tests.cachix.org/serve
|
||||
```
|
||||
|
||||
<!-- #### Manually generating test installers
|
||||
|
||||
There's obviously a manual way to do this, and it's still the only way for
|
||||
platforms that lack GA runners.
|
||||
|
||||
I did do this back in Fall 2020 (before the GA approach encouraged here). I'll
|
||||
sketch what I recall in case it encourages someone to fill in detail, but: I
|
||||
didn't know what I was doing at the time and had to fumble/ask around a lot--
|
||||
so I don't want to uphold any of it as "right". It may have been dumb or
|
||||
the _hard_ way from the getgo. Fundamentals may have changed since.
|
||||
|
||||
Here's the build command I used to do this on and for x86_64-darwin:
|
||||
nix build --out-link /tmp/foo ".#checks.x86_64-darwin.binaryTarball"
|
||||
|
||||
I used the stable out-link to make it easier to script the next steps:
|
||||
link=$(readlink /tmp/foo)
|
||||
cp $link/*-darwin.tar.xz ~/somewheres
|
||||
|
||||
I've lost the last steps and am just going from memory:
|
||||
|
||||
From here, I think I had to extract and modify the `install` script to point
|
||||
it at this tarball (which I scped to my own site, but it might make more sense
|
||||
to just share them locally). I extracted this script once and then just
|
||||
search/replaced in it for each new build.
|
||||
|
||||
The installer now supports a `--tarball-url-prefix` flag which _may_ have
|
||||
solved this need?
|
||||
-->
|
||||
|
||||
### Checking links in the manual
|
||||
|
||||
The build checks for broken internal links.
|
||||
This happens late in the process, so `nix build` is not suitable for iterating.
|
||||
To build the manual incrementally, run:
|
||||
|
||||
```console
|
||||
make html -j $NIX_BUILD_CORES
|
||||
```
|
||||
|
||||
In order to reflect changes to the [Makefile], clear all generated files before re-building:
|
||||
|
||||
[Makefile]: https://github.com/NixOS/nix/blob/master/doc/manual/local.mk
|
||||
|
||||
```console
|
||||
rm $(git ls-files doc/manual/ -o | grep -F '.md') && rmdir doc/manual/src/command-ref/new-cli && make html -j $NIX_BUILD_CORES
|
||||
```
|
||||
|
||||
[`mdbook-linkcheck`] does not implement checking [URI fragments] yet.
|
||||
|
||||
[`mdbook-linkcheck`]: https://github.com/Michael-F-Bryan/mdbook-linkcheck
|
||||
[URI fragments]: https://en.m.wikipedia.org/wiki/URI_fragment
|
||||
|
||||
#### `@docroot@` variable
|
||||
|
||||
`@docroot@` provides a base path for links that occur in reusable snippets or other documentation that doesn't have a base path of its own.
|
||||
|
||||
If a broken link occurs in a snippet that was inserted into multiple generated files in different directories, use `@docroot@` to reference the `doc/manual/src` directory.
|
||||
|
||||
If the `@docroot@` literal appears in an error message from the `mdbook-linkcheck` tool, the `@docroot@` replacement needs to be applied to the generated source file that mentions it.
|
||||
See existing `@docroot@` logic in the [Makefile].
|
||||
Regular markdown files used for the manual have a base path of their own and they can use relative paths instead of `@docroot@`.
|
||||
|
||||
@@ -2,14 +2,14 @@
|
||||
|
||||
Derivations can declare some infrequently used optional attributes.
|
||||
|
||||
- [`allowedReferences`]{#adv-attr-allowedReferences}\
|
||||
- `allowedReferences`
|
||||
The optional attribute `allowedReferences` specifies a list of legal
|
||||
references (dependencies) of the output of the builder. For example,
|
||||
|
||||
|
||||
```nix
|
||||
allowedReferences = [];
|
||||
```
|
||||
|
||||
|
||||
enforces that the output of a derivation cannot have any runtime
|
||||
dependencies on its inputs. To allow an output to have a runtime
|
||||
dependency on itself, use `"out"` as a list item. This is used in
|
||||
@@ -17,45 +17,45 @@ Derivations can declare some infrequently used optional attributes.
|
||||
booting Linux don’t have accidental dependencies on other paths in
|
||||
the Nix store.
|
||||
|
||||
- [`allowedRequisites`]{#adv-attr-allowedRequisites}\
|
||||
- `allowedRequisites`
|
||||
This attribute is similar to `allowedReferences`, but it specifies
|
||||
the legal requisites of the whole closure, so all the dependencies
|
||||
recursively. For example,
|
||||
|
||||
|
||||
```nix
|
||||
allowedRequisites = [ foobar ];
|
||||
```
|
||||
|
||||
|
||||
enforces that the output of a derivation cannot have any other
|
||||
runtime dependency than `foobar`, and in addition it enforces that
|
||||
`foobar` itself doesn't introduce any other dependency itself.
|
||||
|
||||
- [`disallowedReferences`]{#adv-attr-disallowedReferences}\
|
||||
- `disallowedReferences`
|
||||
The optional attribute `disallowedReferences` specifies a list of
|
||||
illegal references (dependencies) of the output of the builder. For
|
||||
example,
|
||||
|
||||
|
||||
```nix
|
||||
disallowedReferences = [ foo ];
|
||||
```
|
||||
|
||||
|
||||
enforces that the output of a derivation cannot have a direct
|
||||
runtime dependencies on the derivation `foo`.
|
||||
|
||||
- [`disallowedRequisites`]{#adv-attr-disallowedRequisites}\
|
||||
- `disallowedRequisites`
|
||||
This attribute is similar to `disallowedReferences`, but it
|
||||
specifies illegal requisites for the whole closure, so all the
|
||||
dependencies recursively. For example,
|
||||
|
||||
|
||||
```nix
|
||||
disallowedRequisites = [ foobar ];
|
||||
```
|
||||
|
||||
|
||||
enforces that the output of a derivation cannot have any runtime
|
||||
dependency on `foobar` or any other derivation depending recursively
|
||||
on `foobar`.
|
||||
|
||||
- [`exportReferencesGraph`]{#adv-attr-exportReferencesGraph}\
|
||||
- `exportReferencesGraph`
|
||||
This attribute allows builders access to the references graph of
|
||||
their inputs. The attribute is a list of inputs in the Nix store
|
||||
whose references graph the builder needs to know. The value of
|
||||
@@ -65,17 +65,17 @@ Derivations can declare some infrequently used optional attributes.
|
||||
files have the format used by `nix-store --register-validity`
|
||||
(with the deriver fields left empty). For example, when the
|
||||
following derivation is built:
|
||||
|
||||
|
||||
```nix
|
||||
derivation {
|
||||
...
|
||||
exportReferencesGraph = [ "libfoo-graph" libfoo ];
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
the references graph of `libfoo` is placed in the file
|
||||
`libfoo-graph` in the temporary build directory.
|
||||
|
||||
|
||||
`exportReferencesGraph` is useful for builders that want to do
|
||||
something with the closure of a store path. Examples include the
|
||||
builders in NixOS that generate the initial ramdisk for booting
|
||||
@@ -84,66 +84,66 @@ Derivations can declare some infrequently used optional attributes.
|
||||
with a Nix store containing the closure of a bootable NixOS
|
||||
configuration).
|
||||
|
||||
- [`impureEnvVars`]{#adv-attr-impureEnvVars}\
|
||||
- `impureEnvVars`
|
||||
This attribute allows you to specify a list of environment variables
|
||||
that should be passed from the environment of the calling user to
|
||||
the builder. Usually, the environment is cleared completely when the
|
||||
builder is executed, but with this attribute you can allow specific
|
||||
environment variables to be passed unmodified. For example,
|
||||
`fetchurl` in Nixpkgs has the line
|
||||
|
||||
|
||||
```nix
|
||||
impureEnvVars = [ "http_proxy" "https_proxy" ... ];
|
||||
```
|
||||
|
||||
|
||||
to make it use the proxy server configuration specified by the user
|
||||
in the environment variables `http_proxy` and friends.
|
||||
|
||||
|
||||
This attribute is only allowed in *fixed-output derivations* (see
|
||||
below), where impurities such as these are okay since (the hash
|
||||
of) the output is known in advance. It is ignored for all other
|
||||
derivations.
|
||||
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
>
|
||||
> `impureEnvVars` implementation takes environment variables from
|
||||
> the current builder process. When a daemon is building its
|
||||
> environmental variables are used. Without the daemon, the
|
||||
> environmental variables come from the environment of the
|
||||
> `nix-build`.
|
||||
|
||||
- [`outputHash`]{#adv-attr-outputHash}; [`outputHashAlgo`]{#adv-attr-outputHashAlgo}; [`outputHashMode`]{#adv-attr-outputHashMode}\
|
||||
- `outputHash`; `outputHashAlgo`; `outputHashMode`
|
||||
These attributes declare that the derivation is a so-called
|
||||
*fixed-output derivation*, which means that a cryptographic hash of
|
||||
the output is already known in advance. When the build of a
|
||||
fixed-output derivation finishes, Nix computes the cryptographic
|
||||
hash of the output and compares it to the hash declared with these
|
||||
attributes. If there is a mismatch, the build fails.
|
||||
|
||||
|
||||
The rationale for fixed-output derivations is derivations such as
|
||||
those produced by the `fetchurl` function. This function downloads a
|
||||
file from a given URL. To ensure that the downloaded file has not
|
||||
been modified, the caller must also specify a cryptographic hash of
|
||||
the file. For example,
|
||||
|
||||
|
||||
```nix
|
||||
fetchurl {
|
||||
url = "http://ftp.gnu.org/pub/gnu/hello/hello-2.1.1.tar.gz";
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
It sometimes happens that the URL of the file changes, e.g., because
|
||||
servers are reorganised or no longer available. We then must update
|
||||
the call to `fetchurl`, e.g.,
|
||||
|
||||
|
||||
```nix
|
||||
fetchurl {
|
||||
url = "ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz";
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
If a `fetchurl` derivation was treated like a normal derivation, the
|
||||
output paths of the derivation and *all derivations depending on it*
|
||||
would change. For instance, if we were to change the URL of the
|
||||
@@ -151,16 +151,16 @@ Derivations can declare some infrequently used optional attributes.
|
||||
other packages depend) massive rebuilds would be needed. This is
|
||||
unfortunate for a change which we know cannot have a real effect as
|
||||
it propagates upwards through the dependency graph.
|
||||
|
||||
|
||||
For fixed-output derivations, on the other hand, the name of the
|
||||
output path only depends on the `outputHash*` and `name` attributes,
|
||||
while all other attributes are ignored for the purpose of computing
|
||||
the output path. (The `name` attribute is included because it is
|
||||
part of the path.)
|
||||
|
||||
|
||||
As an example, here is the (simplified) Nix expression for
|
||||
`fetchurl`:
|
||||
|
||||
|
||||
```nix
|
||||
{ stdenv, curl }: # The curl program is used for downloading.
|
||||
|
||||
@@ -180,51 +180,43 @@ Derivations can declare some infrequently used optional attributes.
|
||||
inherit url;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
The `outputHashAlgo` attribute specifies the hash algorithm used to
|
||||
compute the hash. It can currently be `"sha1"`, `"sha256"` or
|
||||
`"sha512"`.
|
||||
|
||||
|
||||
The `outputHashMode` attribute determines how the hash is computed.
|
||||
It must be one of the following two values:
|
||||
|
||||
- `"flat"`\
|
||||
|
||||
- `"flat"`
|
||||
The output must be a non-executable regular file. If it isn’t,
|
||||
the build fails. The hash is simply computed over the contents
|
||||
of that file (so it’s equal to what Unix commands like
|
||||
`sha256sum` or `sha1sum` produce).
|
||||
|
||||
|
||||
This is the default.
|
||||
|
||||
- `"recursive"`\
|
||||
|
||||
- `"recursive"`
|
||||
The hash is computed over the NAR archive dump of the output
|
||||
(i.e., the result of [`nix-store
|
||||
--dump`](../command-ref/nix-store.md#operation---dump)). In
|
||||
this case, the output can be anything, including a directory
|
||||
tree.
|
||||
|
||||
|
||||
The `outputHash` attribute, finally, must be a string containing
|
||||
the hash in either hexadecimal or base-32 notation. (See the
|
||||
[`nix-hash` command](../command-ref/nix-hash.md) for information
|
||||
about converting to and from base-32 notation.)
|
||||
|
||||
- [`__contentAddressed`]{#adv-attr-__contentAddressed}
|
||||
If this **experimental** attribute is set to true, then the derivation
|
||||
outputs will be stored in a content-addressed location rather than the
|
||||
traditional input-addressed one.
|
||||
This only has an effect if the `ca-derivation` experimental feature is enabled.
|
||||
|
||||
Setting this attribute also requires setting `outputHashMode` and `outputHashAlgo` like for *fixed-output derivations* (see above).
|
||||
|
||||
- [`passAsFile`]{#adv-attr-passAsFile}\
|
||||
- `passAsFile`
|
||||
A list of names of attributes that should be passed via files rather
|
||||
than environment variables. For example, if you have
|
||||
|
||||
|
||||
```nix
|
||||
passAsFile = ["big"];
|
||||
big = "a very long string";
|
||||
```
|
||||
|
||||
|
||||
then when the builder runs, the environment variable `bigPath`
|
||||
will contain the absolute path to a temporary file containing `a
|
||||
very long string`. That is, for any attribute *x* listed in
|
||||
@@ -234,22 +226,22 @@ Derivations can declare some infrequently used optional attributes.
|
||||
builder, since most operating systems impose a limit on the size
|
||||
of the environment (typically, a few hundred kilobyte).
|
||||
|
||||
- [`preferLocalBuild`]{#adv-attr-preferLocalBuild}\
|
||||
- `preferLocalBuild`
|
||||
If this attribute is set to `true` and [distributed building is
|
||||
enabled](../advanced-topics/distributed-builds.md), then, if
|
||||
possible, the derivation will be built locally instead of forwarded
|
||||
possible, the derivaton will be built locally instead of forwarded
|
||||
to a remote machine. This is appropriate for trivial builders
|
||||
where the cost of doing a download or remote build would exceed
|
||||
the cost of building locally.
|
||||
|
||||
- [`allowSubstitutes`]{#adv-attr-allowSubstitutes}\
|
||||
- `allowSubstitutes`
|
||||
If this attribute is set to `false`, then Nix will always build this
|
||||
derivation; it will not try to substitute its outputs. This is
|
||||
useful for very trivial derivations (such as `writeText` in Nixpkgs)
|
||||
that are cheaper to build than to substitute from a binary cache.
|
||||
|
||||
|
||||
> **Note**
|
||||
>
|
||||
>
|
||||
> You need to have a builder configured which satisfies the
|
||||
> derivation’s `system` attribute, since the derivation cannot be
|
||||
> substituted. Thus it is usually a good idea to align `system` with
|
||||
80
doc/manual/src/expressions/arguments-variables.md
Normal file
80
doc/manual/src/expressions/arguments-variables.md
Normal file
@@ -0,0 +1,80 @@
|
||||
# Arguments and Variables
|
||||
|
||||
The [Nix expression for GNU Hello](expression-syntax.md) is a
|
||||
function; it is missing some arguments that have to be filled in
|
||||
somewhere. In the Nix Packages collection this is done in the file
|
||||
`pkgs/top-level/all-packages.nix`, where all Nix expressions for
|
||||
packages are imported and called with the appropriate arguments. Here
|
||||
are some fragments of `all-packages.nix`, with annotations of what
|
||||
they mean:
|
||||
|
||||
```nix
|
||||
...
|
||||
|
||||
rec { ①
|
||||
|
||||
hello = import ../applications/misc/hello/ex-1 ② { ③
|
||||
inherit fetchurl stdenv perl;
|
||||
};
|
||||
|
||||
perl = import ../development/interpreters/perl { ④
|
||||
inherit fetchurl stdenv;
|
||||
};
|
||||
|
||||
fetchurl = import ../build-support/fetchurl {
|
||||
inherit stdenv; ...
|
||||
};
|
||||
|
||||
stdenv = ...;
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
1. This file defines a set of attributes, all of which are concrete
|
||||
derivations (i.e., not functions). In fact, we define a *mutually
|
||||
recursive* set of attributes. That is, the attributes can refer to
|
||||
each other. This is precisely what we want since we want to “plug”
|
||||
the various packages into each other.
|
||||
|
||||
2. Here we *import* the Nix expression for GNU Hello. The import
|
||||
operation just loads and returns the specified Nix expression. In
|
||||
fact, we could just have put the contents of the Nix expression
|
||||
for GNU Hello in `all-packages.nix` at this point. That would be
|
||||
completely equivalent, but it would make `all-packages.nix` rather
|
||||
bulky.
|
||||
|
||||
Note that we refer to `../applications/misc/hello/ex-1`, not
|
||||
`../applications/misc/hello/ex-1/default.nix`. When you try to
|
||||
import a directory, Nix automatically appends `/default.nix` to the
|
||||
file name.
|
||||
|
||||
3. This is where the actual composition takes place. Here we *call* the
|
||||
function imported from `../applications/misc/hello/ex-1` with a set
|
||||
containing the things that the function expects, namely `fetchurl`,
|
||||
`stdenv`, and `perl`. We use inherit again to use the attributes
|
||||
defined in the surrounding scope (we could also have written
|
||||
`fetchurl = fetchurl;`, etc.).
|
||||
|
||||
The result of this function call is an actual derivation that can be
|
||||
built by Nix (since when we fill in the arguments of the function,
|
||||
what we get is its body, which is the call to `stdenv.mkDerivation`
|
||||
in the [Nix expression for GNU Hello](expression-syntax.md)).
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Nixpkgs has a convenience function `callPackage` that imports and
|
||||
> calls a function, filling in any missing arguments by passing the
|
||||
> corresponding attribute from the Nixpkgs set, like this:
|
||||
>
|
||||
> ```nix
|
||||
> hello = callPackage ../applications/misc/hello/ex-1 { };
|
||||
> ```
|
||||
>
|
||||
> If necessary, you can set or override arguments:
|
||||
>
|
||||
> ```nix
|
||||
> hello = callPackage ../applications/misc/hello/ex-1 { stdenv = myStdenv; };
|
||||
> ```
|
||||
|
||||
4. Likewise, we have to instantiate Perl, `fetchurl`, and the standard
|
||||
environment.
|
||||
70
doc/manual/src/expressions/build-script.md
Normal file
70
doc/manual/src/expressions/build-script.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Build Script
|
||||
|
||||
Here is the builder referenced from Hello's Nix expression (stored in
|
||||
`pkgs/applications/misc/hello/ex-1/builder.sh`):
|
||||
|
||||
```bash
|
||||
source $stdenv/setup ①
|
||||
|
||||
PATH=$perl/bin:$PATH ②
|
||||
|
||||
tar xvfz $src ③
|
||||
cd hello-*
|
||||
./configure --prefix=$out ④
|
||||
make ⑤
|
||||
make install
|
||||
```
|
||||
|
||||
The builder can actually be made a lot shorter by using the *generic
|
||||
builder* functions provided by `stdenv`, but here we write out the build
|
||||
steps to elucidate what a builder does. It performs the following steps:
|
||||
|
||||
1. When Nix runs a builder, it initially completely clears the
|
||||
environment (except for the attributes declared in the derivation).
|
||||
This is done to prevent undeclared inputs from being used in the
|
||||
build process. If for example the `PATH` contained `/usr/bin`, then
|
||||
you might accidentally use `/usr/bin/gcc`.
|
||||
|
||||
So the first step is to set up the environment. This is done by
|
||||
calling the `setup` script of the standard environment. The
|
||||
environment variable `stdenv` points to the location of the
|
||||
standard environment being used. (It wasn't specified explicitly
|
||||
as an attribute in Hello's Nix expression, but `mkDerivation` adds
|
||||
it automatically.)
|
||||
|
||||
2. Since Hello needs Perl, we have to make sure that Perl is in the
|
||||
`PATH`. The `perl` environment variable points to the location of
|
||||
the Perl package (since it was passed in as an attribute to the
|
||||
derivation), so `$perl/bin` is the directory containing the Perl
|
||||
interpreter.
|
||||
|
||||
3. Now we have to unpack the sources. The `src` attribute was bound to
|
||||
the result of fetching the Hello source tarball from the network, so
|
||||
the `src` environment variable points to the location in the Nix
|
||||
store to which the tarball was downloaded. After unpacking, we `cd`
|
||||
to the resulting source directory.
|
||||
|
||||
The whole build is performed in a temporary directory created in
|
||||
`/tmp`, by the way. This directory is removed after the builder
|
||||
finishes, so there is no need to clean up the sources afterwards.
|
||||
Also, the temporary directory is always newly created, so you don't
|
||||
have to worry about files from previous builds interfering with the
|
||||
current build.
|
||||
|
||||
4. GNU Hello is a typical Autoconf-based package, so we first have to
|
||||
run its `configure` script. In Nix every package is stored in a
|
||||
separate location in the Nix store, for instance
|
||||
`/nix/store/9a54ba97fb71b65fda531012d0443ce2-hello-2.1.1`. Nix
|
||||
computes this path by cryptographically hashing all attributes of
|
||||
the derivation. The path is passed to the builder through the `out`
|
||||
environment variable. So here we give `configure` the parameter
|
||||
`--prefix=$out` to cause Hello to be installed in the expected
|
||||
location.
|
||||
|
||||
5. Finally we build Hello (`make`) and install it into the location
|
||||
specified by `out` (`make install`).
|
||||
|
||||
If you are wondering about the absence of error checking on the result
|
||||
of various commands called in the builder: this is because the shell
|
||||
script is evaluated with Bash's `-e` option, which causes the script to
|
||||
be aborted if any command fails without an error check.
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
Here are the constants built into the Nix expression evaluator:
|
||||
|
||||
- `builtins`\
|
||||
- `builtins`
|
||||
The set `builtins` contains all the built-in functions and values.
|
||||
You can use `builtins` to test for the availability of features in
|
||||
the Nix installation, e.g.,
|
||||
@@ -14,7 +14,7 @@ Here are the constants built into the Nix expression evaluator:
|
||||
This allows a Nix expression to fall back gracefully on older Nix
|
||||
installations that don’t have the desired built-in function.
|
||||
|
||||
- [`builtins.currentSystem`]{#builtins-currentSystem}\
|
||||
- `builtins.currentSystem`
|
||||
The built-in value `currentSystem` evaluates to the Nix platform
|
||||
identifier for the Nix installation on which the expression is being
|
||||
evaluated, such as `"i686-linux"` or `"x86_64-darwin"`.
|
||||
@@ -9,8 +9,7 @@ scope. Instead, you can access them through the `builtins` built-in
|
||||
value, which is a set that contains all built-in functions and values.
|
||||
For instance, `derivation` is also available as `builtins.derivation`.
|
||||
|
||||
<dl>
|
||||
<dt><code>derivation <var>attrs</var></code>;
|
||||
<code>builtins.derivation <var>attrs</var></code></dt>
|
||||
<dd><p><var>derivation</var> is described in
|
||||
<a href="derivations.md">its own section</a>.</p></dd>
|
||||
- `derivation` *attrs*; `builtins.derivation` *attrs*
|
||||
|
||||
`derivation` is described in [its own section](derivations.md).
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Derivations
|
||||
|
||||
The most important built-in function is `derivation`, which is used to
|
||||
describe a single derivation (a build task). It takes as input a set,
|
||||
describe a single derivation (a build action). It takes as input a set,
|
||||
the attributes of which specify the inputs of the build.
|
||||
|
||||
- There must be an attribute named [`system`]{#attr-system} whose value must be a
|
||||
- There must be an attribute named `system` whose value must be a
|
||||
string specifying a Nix system type, such as `"i686-linux"` or
|
||||
`"x86_64-darwin"`. (To figure out your system type, run `nix -vv
|
||||
--version`.) The build can only be performed on a machine and
|
||||
12
doc/manual/src/expressions/expression-language.md
Normal file
12
doc/manual/src/expressions/expression-language.md
Normal file
@@ -0,0 +1,12 @@
|
||||
# Nix Expression Language
|
||||
|
||||
The Nix expression language is a pure, lazy, functional language. Purity
|
||||
means that operations in the language don't have side-effects (for
|
||||
instance, there is no variable assignment). Laziness means that
|
||||
arguments to functions are evaluated only when they are needed.
|
||||
Functional means that functions are “normal” values that can be passed
|
||||
around and manipulated in interesting ways. The language is not a
|
||||
full-featured, general purpose language. Its main job is to describe
|
||||
packages, compositions of packages, and the variability within packages.
|
||||
|
||||
This section presents the various features of the language.
|
||||
93
doc/manual/src/expressions/expression-syntax.md
Normal file
93
doc/manual/src/expressions/expression-syntax.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Expression Syntax
|
||||
|
||||
Here is a Nix expression for GNU Hello:
|
||||
|
||||
```nix
|
||||
{ stdenv, fetchurl, perl }: ①
|
||||
|
||||
stdenv.mkDerivation { ②
|
||||
name = "hello-2.1.1"; ③
|
||||
builder = ./builder.sh; ④
|
||||
src = fetchurl { ⑤
|
||||
url = "ftp://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz";
|
||||
sha256 = "1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465";
|
||||
};
|
||||
inherit perl; ⑥
|
||||
}
|
||||
```
|
||||
|
||||
This file is actually already in the Nix Packages collection in
|
||||
`pkgs/applications/misc/hello/ex-1/default.nix`. It is customary to
|
||||
place each package in a separate directory and call the single Nix
|
||||
expression in that directory `default.nix`. The file has the following
|
||||
elements (referenced from the figure by number):
|
||||
|
||||
1. This states that the expression is a *function* that expects to be
|
||||
called with three arguments: `stdenv`, `fetchurl`, and `perl`. They
|
||||
are needed to build Hello, but we don't know how to build them here;
|
||||
that's why they are function arguments. `stdenv` is a package that
|
||||
is used by almost all Nix Packages packages; it provides a
|
||||
“standard” environment consisting of the things you would expect
|
||||
in a basic Unix environment: a C/C++ compiler (GCC, to be precise),
|
||||
the Bash shell, fundamental Unix tools such as `cp`, `grep`, `tar`,
|
||||
etc. `fetchurl` is a function that downloads files. `perl` is the
|
||||
Perl interpreter.
|
||||
|
||||
Nix functions generally have the form `{ x, y, ..., z }: e` where
|
||||
`x`, `y`, etc. are the names of the expected arguments, and where
|
||||
*e* is the body of the function. So here, the entire remainder of
|
||||
the file is the body of the function; when given the required
|
||||
arguments, the body should describe how to build an instance of
|
||||
the Hello package.
|
||||
|
||||
2. So we have to build a package. Building something from other stuff
|
||||
is called a *derivation* in Nix (as opposed to sources, which are
|
||||
built by humans instead of computers). We perform a derivation by
|
||||
calling `stdenv.mkDerivation`. `mkDerivation` is a function
|
||||
provided by `stdenv` that builds a package from a set of
|
||||
*attributes*. A set is just a list of key/value pairs where each
|
||||
key is a string and each value is an arbitrary Nix
|
||||
expression. They take the general form `{ name1 = expr1; ...
|
||||
nameN = exprN; }`.
|
||||
|
||||
3. The attribute `name` specifies the symbolic name and version of
|
||||
the package. Nix doesn't really care about these things, but they
|
||||
are used by for instance `nix-env -q` to show a “human-readable”
|
||||
name for packages. This attribute is required by `mkDerivation`.
|
||||
|
||||
4. The attribute `builder` specifies the builder. This attribute can
|
||||
sometimes be omitted, in which case `mkDerivation` will fill in a
|
||||
default builder (which does a `configure; make; make install`, in
|
||||
essence). Hello is sufficiently simple that the default builder
|
||||
would suffice, but in this case, we will show an actual builder
|
||||
for educational purposes. The value `./builder.sh` refers to the
|
||||
shell script shown in the [next section](build-script.md),
|
||||
discussed below.
|
||||
|
||||
5. The builder has to know what the sources of the package are. Here,
|
||||
the attribute `src` is bound to the result of a call to the
|
||||
`fetchurl` function. Given a URL and a SHA-256 hash of the expected
|
||||
contents of the file at that URL, this function builds a derivation
|
||||
that downloads the file and checks its hash. So the sources are a
|
||||
dependency that like all other dependencies is built before Hello
|
||||
itself is built.
|
||||
|
||||
Instead of `src` any other name could have been used, and in fact
|
||||
there can be any number of sources (bound to different attributes).
|
||||
However, `src` is customary, and it's also expected by the default
|
||||
builder (which we don't use in this example).
|
||||
|
||||
6. Since the derivation requires Perl, we have to pass the value of the
|
||||
`perl` function argument to the builder. All attributes in the set
|
||||
are actually passed as environment variables to the builder, so
|
||||
declaring an attribute
|
||||
|
||||
```nix
|
||||
perl = perl;
|
||||
```
|
||||
|
||||
will do the trick: it binds an attribute `perl` to the function
|
||||
argument which also happens to be called `perl`. However, it looks a
|
||||
bit silly, so there is a shorter syntax. The `inherit` keyword
|
||||
causes the specified attributes to be bound to whatever variables
|
||||
with the same name happen to be in scope.
|
||||
66
doc/manual/src/expressions/generic-builder.md
Normal file
66
doc/manual/src/expressions/generic-builder.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# Generic Builder Syntax
|
||||
|
||||
Recall that the [build script for GNU Hello](build-script.md) looked
|
||||
something like this:
|
||||
|
||||
```bash
|
||||
PATH=$perl/bin:$PATH
|
||||
tar xvfz $src
|
||||
cd hello-*
|
||||
./configure --prefix=$out
|
||||
make
|
||||
make install
|
||||
```
|
||||
|
||||
The builders for almost all Unix packages look like this — set up some
|
||||
environment variables, unpack the sources, configure, build, and
|
||||
install. For this reason the standard environment provides some Bash
|
||||
functions that automate the build process. Here is what a builder using
|
||||
the generic build facilities looks like:
|
||||
|
||||
```bash
|
||||
buildInputs="$perl" ①
|
||||
|
||||
source $stdenv/setup ②
|
||||
|
||||
genericBuild ③
|
||||
```
|
||||
|
||||
Here is what each line means:
|
||||
|
||||
1. The `buildInputs` variable tells `setup` to use the indicated
|
||||
packages as “inputs”. This means that if a package provides a `bin`
|
||||
subdirectory, it's added to `PATH`; if it has a `include`
|
||||
subdirectory, it's added to GCC's header search path; and so on.
|
||||
(This is implemented in a modular way: `setup` tries to source the
|
||||
file `pkg/nix-support/setup-hook` of all dependencies. These “setup
|
||||
hooks” can then set up whatever environment variables they want; for
|
||||
instance, the setup hook for Perl sets the `PERL5LIB` environment
|
||||
variable to contain the `lib/site_perl` directories of all inputs.)
|
||||
|
||||
2. The function `genericBuild` is defined in the file `$stdenv/setup`.
|
||||
|
||||
3. The final step calls the shell function `genericBuild`, which
|
||||
performs the steps that were done explicitly in the previous build
|
||||
script. The generic builder is smart enough to figure out whether
|
||||
to unpack the sources using `gzip`, `bzip2`, etc. It can be
|
||||
customised in many ways; see the Nixpkgs manual for details.
|
||||
|
||||
Discerning readers will note that the `buildInputs` could just as well
|
||||
have been set in the Nix expression, like this:
|
||||
|
||||
```nix
|
||||
buildInputs = [ perl ];
|
||||
```
|
||||
|
||||
The `perl` attribute can then be removed, and the builder becomes even
|
||||
shorter:
|
||||
|
||||
```bash
|
||||
source $stdenv/setup
|
||||
genericBuild
|
||||
```
|
||||
|
||||
In fact, `mkDerivation` provides a default builder that looks exactly
|
||||
like that, so it is actually possible to omit the builder for Hello
|
||||
entirely.
|
||||
@@ -284,10 +284,6 @@ The points of interest are:
|
||||
function is called with the `localServer` argument set to `true` but
|
||||
the `db4` argument set to `null`, then the evaluation fails.
|
||||
|
||||
Note that `->` is the [logical
|
||||
implication](https://en.wikipedia.org/wiki/Truth_table#Logical_implication)
|
||||
Boolean operation.
|
||||
|
||||
2. This is a more subtle condition: if Subversion is built with Apache
|
||||
(`httpServer`) support, then the Expat library (an XML library) used
|
||||
by Subversion should be same as the one used by Apache. This is
|
||||
28
doc/manual/src/expressions/language-operators.md
Normal file
28
doc/manual/src/expressions/language-operators.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Operators
|
||||
|
||||
The table below lists the operators in the Nix expression language, in
|
||||
order of precedence (from strongest to weakest binding).
|
||||
|
||||
| Name | Syntax | Associativity | Description | Precedence |
|
||||
| ------------------------ | ----------------------------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
|
||||
| Select | *e* `.` *attrpath* \[ `or` *def* \] | none | Select attribute denoted by the attribute path *attrpath* from set *e*. (An attribute path is a dot-separated list of attribute names.) If the attribute doesn’t exist, return *def* if provided, otherwise abort evaluation. | 1 |
|
||||
| Application | *e1* *e2* | left | Call function *e1* with argument *e2*. | 2 |
|
||||
| Arithmetic Negation | `-` *e* | none | Arithmetic negation. | 3 |
|
||||
| Has Attribute | *e* `?` *attrpath* | none | Test whether set *e* contains the attribute denoted by *attrpath*; return `true` or `false`. | 4 |
|
||||
| List Concatenation | *e1* `++` *e2* | right | List concatenation. | 5 |
|
||||
| Multiplication | *e1* `*` *e2*, | left | Arithmetic multiplication. | 6 |
|
||||
| Division | *e1* `/` *e2* | left | Arithmetic division. | 6 |
|
||||
| Addition | *e1* `+` *e2* | left | Arithmetic addition. | 7 |
|
||||
| Subtraction | *e1* `-` *e2* | left | Arithmetic subtraction. | 7 |
|
||||
| String Concatenation | *string1* `+` *string2* | left | String concatenation. | 7 |
|
||||
| Not | `!` *e* | none | Boolean negation. | 8 |
|
||||
| Update | *e1* `//` *e2* | right | Return a set consisting of the attributes in *e1* and *e2* (with the latter taking precedence over the former in case of equally named attributes). | 9 |
|
||||
| Less Than | *e1* `<` *e2*, | none | Arithmetic comparison. | 10 |
|
||||
| Less Than or Equal To | *e1* `<=` *e2* | none | Arithmetic comparison. | 10 |
|
||||
| Greater Than | *e1* `>` *e2* | none | Arithmetic comparison. | 10 |
|
||||
| Greater Than or Equal To | *e1* `>=` *e2* | none | Arithmetic comparison. | 10 |
|
||||
| Equality | *e1* `==` *e2* | none | Equality. | 11 |
|
||||
| Inequality | *e1* `!=` *e2* | none | Inequality. | 11 |
|
||||
| Logical AND | *e1* `&&` *e2* | left | Logical AND. | 12 |
|
||||
| Logical OR | *e1* `\|\|` *e2* | left | Logical OR. | 13 |
|
||||
| Logical Implication | *e1* `->` *e2* | none | Logical implication (equivalent to `!e1 \|\| e2`). | 14 |
|
||||
244
doc/manual/src/expressions/language-values.md
Normal file
244
doc/manual/src/expressions/language-values.md
Normal file
@@ -0,0 +1,244 @@
|
||||
# Values
|
||||
|
||||
## Simple Values
|
||||
|
||||
Nix has the following basic data types:
|
||||
|
||||
- *Strings* can be written in three ways.
|
||||
|
||||
The most common way is to enclose the string between double quotes,
|
||||
e.g., `"foo bar"`. Strings can span multiple lines. The special
|
||||
characters `"` and `\` and the character sequence `${` must be
|
||||
escaped by prefixing them with a backslash (`\`). Newlines, carriage
|
||||
returns and tabs can be written as `\n`, `\r` and `\t`,
|
||||
respectively.
|
||||
|
||||
You can include the result of an expression into a string by
|
||||
enclosing it in `${...}`, a feature known as *antiquotation*. The
|
||||
enclosed expression must evaluate to something that can be coerced
|
||||
into a string (meaning that it must be a string, a path, or a
|
||||
derivation). For instance, rather than writing
|
||||
|
||||
```nix
|
||||
"--with-freetype2-library=" + freetype + "/lib"
|
||||
```
|
||||
|
||||
(where `freetype` is a derivation), you can instead write the more
|
||||
natural
|
||||
|
||||
```nix
|
||||
"--with-freetype2-library=${freetype}/lib"
|
||||
```
|
||||
|
||||
The latter is automatically translated to the former. A more
|
||||
complicated example (from the Nix expression for
|
||||
[Qt](http://www.trolltech.com/products/qt)):
|
||||
|
||||
```nix
|
||||
configureFlags = "
|
||||
-system-zlib -system-libpng -system-libjpeg
|
||||
${if openglSupport then "-dlopen-opengl
|
||||
-L${mesa}/lib -I${mesa}/include
|
||||
-L${libXmu}/lib -I${libXmu}/include" else ""}
|
||||
${if threadSupport then "-thread" else "-no-thread"}
|
||||
";
|
||||
```
|
||||
|
||||
Note that Nix expressions and strings can be arbitrarily nested; in
|
||||
this case the outer string contains various antiquotations that
|
||||
themselves contain strings (e.g., `"-thread"`), some of which in
|
||||
turn contain expressions (e.g., `${mesa}`).
|
||||
|
||||
The second way to write string literals is as an *indented string*,
|
||||
which is enclosed between pairs of *double single-quotes*, like so:
|
||||
|
||||
```nix
|
||||
''
|
||||
This is the first line.
|
||||
This is the second line.
|
||||
This is the third line.
|
||||
''
|
||||
```
|
||||
|
||||
This kind of string literal intelligently strips indentation from
|
||||
the start of each line. To be precise, it strips from each line a
|
||||
number of spaces equal to the minimal indentation of the string as a
|
||||
whole (disregarding the indentation of empty lines). For instance,
|
||||
the first and second line are indented two space, while the third
|
||||
line is indented four spaces. Thus, two spaces are stripped from
|
||||
each line, so the resulting string is
|
||||
|
||||
```nix
|
||||
"This is the first line.\nThis is the second line.\n This is the third line.\n"
|
||||
```
|
||||
|
||||
Note that the whitespace and newline following the opening `''` is
|
||||
ignored if there is no non-whitespace text on the initial line.
|
||||
|
||||
Antiquotation (`${expr}`) is supported in indented strings.
|
||||
|
||||
Since `${` and `''` have special meaning in indented strings, you
|
||||
need a way to quote them. `$` can be escaped by prefixing it with
|
||||
`''` (that is, two single quotes), i.e., `''$`. `''` can be escaped
|
||||
by prefixing it with `'`, i.e., `'''`. `$` removes any special
|
||||
meaning from the following `$`. Linefeed, carriage-return and tab
|
||||
characters can be written as `''\n`, `''\r`, `''\t`, and `''\`
|
||||
escapes any other character.
|
||||
|
||||
Indented strings are primarily useful in that they allow multi-line
|
||||
string literals to follow the indentation of the enclosing Nix
|
||||
expression, and that less escaping is typically necessary for
|
||||
strings representing languages such as shell scripts and
|
||||
configuration files because `''` is much less common than `"`.
|
||||
Example:
|
||||
|
||||
```nix
|
||||
stdenv.mkDerivation {
|
||||
...
|
||||
postInstall =
|
||||
''
|
||||
mkdir $out/bin $out/etc
|
||||
cp foo $out/bin
|
||||
echo "Hello World" > $out/etc/foo.conf
|
||||
${if enableBar then "cp bar $out/bin" else ""}
|
||||
'';
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Finally, as a convenience, *URIs* as defined in appendix B of
|
||||
[RFC 2396](http://www.ietf.org/rfc/rfc2396.txt) can be written *as
|
||||
is*, without quotes. For instance, the string
|
||||
`"http://example.org/foo.tar.bz2"` can also be written as
|
||||
`http://example.org/foo.tar.bz2`.
|
||||
|
||||
- Numbers, which can be *integers* (like `123`) or *floating point*
|
||||
(like `123.43` or `.27e13`).
|
||||
|
||||
Numbers are type-compatible: pure integer operations will always
|
||||
return integers, whereas any operation involving at least one
|
||||
floating point number will have a floating point number as a result.
|
||||
|
||||
- *Paths*, e.g., `/bin/sh` or `./builder.sh`. A path must contain at
|
||||
least one slash to be recognised as such. For instance, `builder.sh`
|
||||
is not a path: it's parsed as an expression that selects the
|
||||
attribute `sh` from the variable `builder`. If the file name is
|
||||
relative, i.e., if it does not begin with a slash, it is made
|
||||
absolute at parse time relative to the directory of the Nix
|
||||
expression that contained it. For instance, if a Nix expression in
|
||||
`/foo/bar/bla.nix` refers to `../xyzzy/fnord.nix`, the absolute path
|
||||
is `/foo/xyzzy/fnord.nix`.
|
||||
|
||||
If the first component of a path is a `~`, it is interpreted as if
|
||||
the rest of the path were relative to the user's home directory.
|
||||
e.g. `~/foo` would be equivalent to `/home/edolstra/foo` for a user
|
||||
whose home directory is `/home/edolstra`.
|
||||
|
||||
Paths can also be specified between angle brackets, e.g.
|
||||
`<nixpkgs>`. This means that the directories listed in the
|
||||
environment variable `NIX_PATH` will be searched for the given file
|
||||
or directory name.
|
||||
|
||||
- *Booleans* with values `true` and `false`.
|
||||
|
||||
- The null value, denoted as `null`.
|
||||
|
||||
## Lists
|
||||
|
||||
Lists are formed by enclosing a whitespace-separated list of values
|
||||
between square brackets. For example,
|
||||
|
||||
```nix
|
||||
[ 123 ./foo.nix "abc" (f { x = y; }) ]
|
||||
```
|
||||
|
||||
defines a list of four elements, the last being the result of a call to
|
||||
the function `f`. Note that function calls have to be enclosed in
|
||||
parentheses. If they had been omitted, e.g.,
|
||||
|
||||
```nix
|
||||
[ 123 ./foo.nix "abc" f { x = y; } ]
|
||||
```
|
||||
|
||||
the result would be a list of five elements, the fourth one being a
|
||||
function and the fifth being a set.
|
||||
|
||||
Note that lists are only lazy in values, and they are strict in length.
|
||||
|
||||
## Sets
|
||||
|
||||
Sets are really the core of the language, since ultimately the Nix
|
||||
language is all about creating derivations, which are really just sets
|
||||
of attributes to be passed to build scripts.
|
||||
|
||||
Sets are just a list of name/value pairs (called *attributes*) enclosed
|
||||
in curly brackets, where each value is an arbitrary expression
|
||||
terminated by a semicolon. For example:
|
||||
|
||||
```nix
|
||||
{ x = 123;
|
||||
text = "Hello";
|
||||
y = f { bla = 456; };
|
||||
}
|
||||
```
|
||||
|
||||
This defines a set with attributes named `x`, `text`, `y`. The order of
|
||||
the attributes is irrelevant. An attribute name may only occur once.
|
||||
|
||||
Attributes can be selected from a set using the `.` operator. For
|
||||
instance,
|
||||
|
||||
```nix
|
||||
{ a = "Foo"; b = "Bar"; }.a
|
||||
```
|
||||
|
||||
evaluates to `"Foo"`. It is possible to provide a default value in an
|
||||
attribute selection using the `or` keyword. For example,
|
||||
|
||||
```nix
|
||||
{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"
|
||||
```
|
||||
|
||||
will evaluate to `"Xyzzy"` because there is no `c` attribute in the set.
|
||||
|
||||
You can use arbitrary double-quoted strings as attribute names:
|
||||
|
||||
```nix
|
||||
{ "foo ${bar}" = 123; "nix-1.0" = 456; }."foo ${bar}"
|
||||
```
|
||||
|
||||
This will evaluate to `123` (Assuming `bar` is antiquotable). In the
|
||||
case where an attribute name is just a single antiquotation, the quotes
|
||||
can be dropped:
|
||||
|
||||
```nix
|
||||
{ foo = 123; }.${bar} or 456
|
||||
```
|
||||
|
||||
This will evaluate to `123` if `bar` evaluates to `"foo"` when coerced
|
||||
to a string and `456` otherwise (again assuming `bar` is antiquotable).
|
||||
|
||||
In the special case where an attribute name inside of a set declaration
|
||||
evaluates to `null` (which is normally an error, as `null` is not
|
||||
antiquotable), that attribute is simply not added to the set:
|
||||
|
||||
```nix
|
||||
{ ${if foo then "bar" else null} = true; }
|
||||
```
|
||||
|
||||
This will evaluate to `{}` if `foo` evaluates to `false`.
|
||||
|
||||
A set that has a `__functor` attribute whose value is callable (i.e. is
|
||||
itself a function or a set with a `__functor` attribute whose value is
|
||||
callable) can be applied as if it were a function, with the set itself
|
||||
passed in first , e.g.,
|
||||
|
||||
```nix
|
||||
let add = { __functor = self: x: x + self.x; };
|
||||
inc = add // { x = 1; };
|
||||
in inc 1
|
||||
```
|
||||
|
||||
evaluates to `2`. This can be used to attach metadata to a function
|
||||
without the caller needing to treat it specially, or to implement a form
|
||||
of object-oriented programming, for example.
|
||||
61
doc/manual/src/expressions/simple-building-testing.md
Normal file
61
doc/manual/src/expressions/simple-building-testing.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# Building and Testing
|
||||
|
||||
You can now try to build Hello. Of course, you could do `nix-env -i
|
||||
hello`, but you may not want to install a possibly broken package just
|
||||
yet. The best way to test the package is by using the command
|
||||
`nix-build`, which builds a Nix expression and creates a symlink named
|
||||
`result` in the current directory:
|
||||
|
||||
```console
|
||||
$ nix-build -A hello
|
||||
building path `/nix/store/632d2b22514d...-hello-2.1.1'
|
||||
hello-2.1.1/
|
||||
hello-2.1.1/intl/
|
||||
hello-2.1.1/intl/ChangeLog
|
||||
...
|
||||
|
||||
$ ls -l result
|
||||
lrwxrwxrwx ... 2006-09-29 10:43 result -> /nix/store/632d2b22514d...-hello-2.1.1
|
||||
|
||||
$ ./result/bin/hello
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
The `-A` option selects the `hello` attribute. This is faster than
|
||||
using the symbolic package name specified by the `name` attribute
|
||||
(which also happens to be `hello`) and is unambiguous (there can be
|
||||
multiple packages with the symbolic name `hello`, but there can be
|
||||
only one attribute in a set named `hello`).
|
||||
|
||||
`nix-build` registers the `./result` symlink as a garbage collection
|
||||
root, so unless and until you delete the `./result` symlink, the output
|
||||
of the build will be safely kept on your system. You can use
|
||||
`nix-build`’s `-o` switch to give the symlink another name.
|
||||
|
||||
Nix has transactional semantics. Once a build finishes successfully, Nix
|
||||
makes a note of this in its database: it registers that the path denoted
|
||||
by `out` is now “valid”. If you try to build the derivation again, Nix
|
||||
will see that the path is already valid and finish immediately. If a
|
||||
build fails, either because it returns a non-zero exit code, because Nix
|
||||
or the builder are killed, or because the machine crashes, then the
|
||||
output paths will not be registered as valid. If you try to build the
|
||||
derivation again, Nix will remove the output paths if they exist (e.g.,
|
||||
because the builder died half-way through `make
|
||||
install`) and try again. Note that there is no “negative caching”: Nix
|
||||
doesn't remember that a build failed, and so a failed build can always
|
||||
be repeated. This is because Nix cannot distinguish between permanent
|
||||
failures (e.g., a compiler error due to a syntax error in the source)
|
||||
and transient failures (e.g., a disk full condition).
|
||||
|
||||
Nix also performs locking. If you run multiple Nix builds
|
||||
simultaneously, and they try to build the same derivation, the first Nix
|
||||
instance that gets there will perform the build, while the others block
|
||||
(or perform other derivations if available) until the build finishes:
|
||||
|
||||
```console
|
||||
$ nix-build -A hello
|
||||
waiting for lock on `/nix/store/0h5b7hp8d4hqfrw8igvx97x1xawrjnac-hello-2.1.1x'
|
||||
```
|
||||
|
||||
So it is always safe to run multiple instances of Nix in parallel (which
|
||||
isn’t the case with, say, `make`).
|
||||
23
doc/manual/src/expressions/simple-expression.md
Normal file
23
doc/manual/src/expressions/simple-expression.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# A Simple Nix Expression
|
||||
|
||||
This section shows how to add and test the [GNU Hello
|
||||
package](http://www.gnu.org/software/hello/hello.html) to the Nix
|
||||
Packages collection. Hello is a program that prints out the text “Hello,
|
||||
world\!”.
|
||||
|
||||
To add a package to the Nix Packages collection, you generally need to
|
||||
do three things:
|
||||
|
||||
1. Write a Nix expression for the package. This is a file that
|
||||
describes all the inputs involved in building the package, such as
|
||||
dependencies, sources, and so on.
|
||||
|
||||
2. Write a *builder*. This is a shell script that builds the package
|
||||
from the inputs. (In fact, it can be written in any language, but
|
||||
typically it's a `bash` shell script.)
|
||||
|
||||
3. Add the package to the file `pkgs/top-level/all-packages.nix`. The
|
||||
Nix expression written in the first step is a *function*; it
|
||||
requires other packages in order to build it. In this step you put
|
||||
it all together, i.e., you call the function with the right
|
||||
arguments to build the actual package.
|
||||
12
doc/manual/src/expressions/writing-nix-expressions.md
Normal file
12
doc/manual/src/expressions/writing-nix-expressions.md
Normal file
@@ -0,0 +1,12 @@
|
||||
This chapter shows you how to write Nix expressions, which instruct Nix
|
||||
how to build packages. It starts with a simple example (a Nix expression
|
||||
for GNU Hello), and then moves on to a more in-depth look at the Nix
|
||||
expression language.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> This chapter is mostly about the Nix expression language. For more
|
||||
> extensive information on adding packages to the Nix Packages
|
||||
> collection (such as functions in the standard environment and coding
|
||||
> conventions), please consult [its
|
||||
> manual](http://nixos.org/nixpkgs/manual/).
|
||||
@@ -1,134 +1,62 @@
|
||||
# Glossary
|
||||
|
||||
- [derivation]{#gloss-derivation}\
|
||||
A description of a build task. The result of a derivation is a
|
||||
- derivation
|
||||
A description of a build action. The result of a derivation is a
|
||||
store object. Derivations are typically specified in Nix expressions
|
||||
using the [`derivation` primitive](./language/derivations.md). These are
|
||||
using the [`derivation` primitive](expressions/derivations.md). These are
|
||||
translated into low-level *store derivations* (implicitly by
|
||||
`nix-env` and `nix-build`, or explicitly by `nix-instantiate`).
|
||||
|
||||
[derivation]: #gloss-derivation
|
||||
|
||||
- [store derivation]{#gloss-store-derivation}\
|
||||
A [derivation] represented as a `.drv` file in the [store].
|
||||
It has a [store path], like any [store object].
|
||||
|
||||
Example: `/nix/store/g946hcz4c8mdvq2g8vxx42z51qb71rvp-git-2.38.1.drv`
|
||||
|
||||
See [`nix show-derivation`](./command-ref/new-cli/nix3-show-derivation.md) (experimental) for displaying the contents of store derivations.
|
||||
|
||||
[store derivation]: #gloss-store-derivation
|
||||
|
||||
- [content-addressed derivation]{#gloss-content-addressed-derivation}\
|
||||
A derivation which has the
|
||||
[`__contentAddressed`](./language/advanced-attributes.md#adv-attr-__contentAddressed)
|
||||
attribute set to `true`.
|
||||
|
||||
- [fixed-output derivation]{#gloss-fixed-output-derivation}\
|
||||
A derivation which includes the
|
||||
[`outputHash`](./language/advanced-attributes.md#adv-attr-outputHash) attribute.
|
||||
|
||||
- [store]{#gloss-store}\
|
||||
- store
|
||||
The location in the file system where store objects live. Typically
|
||||
`/nix/store`.
|
||||
|
||||
From the perspective of the location where Nix is
|
||||
invoked, the Nix store can be referred to
|
||||
as a "_local_" or a "_remote_" one:
|
||||
|
||||
+ A *local store* exists on the filesystem of
|
||||
the machine where Nix is invoked. You can use other
|
||||
local stores by passing the `--store` flag to the
|
||||
`nix` command. Local stores can be used for building derivations.
|
||||
|
||||
+ A *remote store* exists anywhere other than the
|
||||
local filesystem. One example is the `/nix/store`
|
||||
directory on another machine, accessed via `ssh` or
|
||||
served by the `nix-serve` Perl script.
|
||||
|
||||
[store]: #gloss-store
|
||||
|
||||
- [chroot store]{#gloss-chroot-store}\
|
||||
A local store whose canonical path is anything other than `/nix/store`.
|
||||
|
||||
- [binary cache]{#gloss-binary-cache}\
|
||||
A *binary cache* is a Nix store which uses a different format: its
|
||||
metadata and signatures are kept in `.narinfo` files rather than in a
|
||||
Nix database. This different format simplifies serving store objects
|
||||
over the network, but cannot host builds. Examples of binary caches
|
||||
include S3 buckets and the [NixOS binary
|
||||
cache](https://cache.nixos.org).
|
||||
|
||||
- [store path]{#gloss-store-path}\
|
||||
The location of a [store object] in the file system, i.e., an
|
||||
- store path
|
||||
The location in the file system of a store object, i.e., an
|
||||
immediate child of the Nix store directory.
|
||||
|
||||
Example: `/nix/store/a040m110amc4h71lds2jmr8qrkj2jhxd-git-2.38.1`
|
||||
|
||||
[store path]: #gloss-store-path
|
||||
|
||||
- [store object]{#gloss-store-object}\
|
||||
- store object
|
||||
A file that is an immediate child of the Nix store directory. These
|
||||
can be regular files, but also entire directory trees. Store objects
|
||||
can be sources (objects copied from outside of the store),
|
||||
derivation outputs (objects produced by running a build task), or
|
||||
derivations (files describing a build task).
|
||||
derivation outputs (objects produced by running a build action), or
|
||||
derivations (files describing a build action).
|
||||
|
||||
[store object]: #gloss-store-object
|
||||
|
||||
- [input-addressed store object]{#gloss-input-addressed-store-object}\
|
||||
A store object produced by building a
|
||||
non-[content-addressed](#gloss-content-addressed-derivation),
|
||||
non-[fixed-output](#gloss-fixed-output-derivation)
|
||||
derivation.
|
||||
|
||||
- [output-addressed store object]{#gloss-output-addressed-store-object}\
|
||||
A store object whose store path hashes its content. This
|
||||
includes derivations, the outputs of
|
||||
[content-addressed derivations](#gloss-content-addressed-derivation),
|
||||
and the outputs of
|
||||
[fixed-output derivations](#gloss-fixed-output-derivation).
|
||||
|
||||
- [substitute]{#gloss-substitute}\
|
||||
- substitute
|
||||
A substitute is a command invocation stored in the Nix database that
|
||||
describes how to build a store object, bypassing the normal build
|
||||
mechanism (i.e., derivations). Typically, the substitute builds the
|
||||
store object by downloading a pre-built version of the store object
|
||||
from some server.
|
||||
|
||||
- [substituter]{#gloss-substituter}\
|
||||
A *substituter* is an additional store from which Nix will
|
||||
copy store objects it doesn't have. For details, see the
|
||||
[`substituters` option](./command-ref/conf-file.md#conf-substituters).
|
||||
|
||||
- [purity]{#gloss-purity}\
|
||||
- purity
|
||||
The assumption that equal Nix derivations when run always produce
|
||||
the same output. This cannot be guaranteed in general (e.g., a
|
||||
builder can rely on external inputs such as the network or the
|
||||
system time) but the Nix model assumes it.
|
||||
|
||||
- [Nix expression]{#gloss-nix-expression}\
|
||||
- Nix expression
|
||||
A high-level description of software packages and compositions
|
||||
thereof. Deploying software using Nix entails writing Nix
|
||||
expressions for your packages. Nix expressions are translated to
|
||||
derivations that are stored in the Nix store. These derivations can
|
||||
then be built.
|
||||
|
||||
- [reference]{#gloss-reference}\
|
||||
- reference
|
||||
A store path `P` is said to have a reference to a store path `Q` if
|
||||
the store object at `P` contains the path `Q` somewhere. The
|
||||
*references* of a store path are the set of store paths to which it
|
||||
has a reference.
|
||||
|
||||
|
||||
A derivation can reference other derivations and sources (but not
|
||||
output paths), whereas an output path only references other output
|
||||
paths.
|
||||
|
||||
- [reachable]{#gloss-reachable}\
|
||||
- reachable
|
||||
A store path `Q` is reachable from another store path `P` if `Q`
|
||||
is in the *closure* of the *references* relation.
|
||||
|
||||
- [closure]{#gloss-closure}\
|
||||
- closure
|
||||
The closure of a store path is the set of store paths that are
|
||||
directly or indirectly “reachable” from that store path; that is,
|
||||
it’s the closure of the path under the *references* relation. For
|
||||
@@ -138,52 +66,35 @@
|
||||
is necessary to deploy whole closures, since otherwise at runtime
|
||||
files could be missing. The command `nix-store -qR` prints out
|
||||
closures of store paths.
|
||||
|
||||
|
||||
As an example, if the store object at path `P` contains a reference
|
||||
to path `Q`, then `Q` is in the closure of `P`. Further, if `Q`
|
||||
references `R` then `R` is also in the closure of `P`.
|
||||
|
||||
- [output path]{#gloss-output-path}\
|
||||
A [store path] produced by a [derivation].
|
||||
- output path
|
||||
A store path produced by a derivation.
|
||||
|
||||
[output path]: #gloss-output-path
|
||||
|
||||
- [deriver]{#gloss-deriver}\
|
||||
- deriver
|
||||
The deriver of an *output path* is the store
|
||||
derivation that built it.
|
||||
|
||||
- [validity]{#gloss-validity}\
|
||||
- validity
|
||||
A store path is considered *valid* if it exists in the file system,
|
||||
is listed in the Nix database as being valid, and if all paths in
|
||||
its closure are also valid.
|
||||
|
||||
- [user environment]{#gloss-user-env}\
|
||||
- user environment
|
||||
An automatically generated store object that consists of a set of
|
||||
symlinks to “active” applications, i.e., other store paths. These
|
||||
are generated automatically by
|
||||
[`nix-env`](./command-ref/nix-env.md). See *profiles*.
|
||||
[`nix-env`](command-ref/nix-env.md). See *profiles*.
|
||||
|
||||
- [profile]{#gloss-profile}\
|
||||
- profile
|
||||
A symlink to the current *user environment* of a user, e.g.,
|
||||
`/nix/var/nix/profiles/default`.
|
||||
|
||||
- [NAR]{#gloss-nar}\
|
||||
- NAR
|
||||
A *N*ix *AR*chive. This is a serialisation of a path in the Nix
|
||||
store. It can contain regular files, directories and symbolic
|
||||
links. NARs are generated and unpacked using `nix-store --dump`
|
||||
and `nix-store --restore`.
|
||||
|
||||
- [`∅`]{#gloss-emtpy-set}\
|
||||
The empty set symbol. In the context of profile history, this denotes a package is not present in a particular version of the profile.
|
||||
|
||||
- [`ε`]{#gloss-epsilon}\
|
||||
The epsilon symbol. In the context of a package, this means the version is empty. More precisely, the derivation does not have a version attribute.
|
||||
|
||||
- [string interpolation]{#gloss-string-interpolation}\
|
||||
Expanding expressions enclosed in `${ }` within a [string], [path], or [attribute name].
|
||||
|
||||
See [String interpolation](./language/string-interpolation.md) for details.
|
||||
|
||||
[string]: ./language/values.md#type-string
|
||||
[path]: ./language/values.md#type-path
|
||||
[attribute name]: ./language/values.md#attribute-set
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Building Nix from Source
|
||||
|
||||
After cloning Nix's Git repository, issue the following commands:
|
||||
After unpacking or checking out the Nix sources, issue the following
|
||||
commands:
|
||||
|
||||
```console
|
||||
$ ./bootstrap.sh
|
||||
$ ./configure options...
|
||||
$ make
|
||||
$ make install
|
||||
@@ -11,6 +11,13 @@ $ make install
|
||||
|
||||
Nix requires GNU Make so you may need to invoke `gmake` instead.
|
||||
|
||||
When building from the Git repository, these should be preceded by the
|
||||
command:
|
||||
|
||||
```console
|
||||
$ ./bootstrap.sh
|
||||
```
|
||||
|
||||
The installation path can be specified by passing the `--prefix=prefix`
|
||||
to `configure`. The default installation directory is `/usr/local`. You
|
||||
can change this to any location you like. You must have write permission
|
||||
|
||||
@@ -40,7 +40,7 @@ export NIX_SSL_CERT_FILE=/etc/ssl/my-certificate-bundle.crt
|
||||
> **Note**
|
||||
>
|
||||
> You must not add the export and then do the install, as the Nix
|
||||
> installer will detect the presence of Nix configuration, and abort.
|
||||
> installer will detect the presense of Nix configuration, and abort.
|
||||
|
||||
## `NIX_SSL_CERT_FILE` with macOS and the Nix daemon
|
||||
|
||||
|
||||
@@ -1,26 +1,18 @@
|
||||
# Installing a Binary Distribution
|
||||
|
||||
The easiest way to install Nix is to run the following command:
|
||||
If you are using Linux or macOS versions up to 10.14 (Mojave), the
|
||||
easiest way to install Nix is to run the following command:
|
||||
|
||||
```console
|
||||
$ sh <(curl -L https://nixos.org/nix/install)
|
||||
```
|
||||
|
||||
This will run the installer interactively (causing it to explain what
|
||||
it is doing more explicitly), and perform the default "type" of install
|
||||
for your platform:
|
||||
- single-user on Linux
|
||||
- multi-user on macOS
|
||||
If you're using macOS 10.15 (Catalina) or newer, consult [the macOS
|
||||
installation instructions](#macos-installation) before installing.
|
||||
|
||||
> **Notes on read-only filesystem root in macOS 10.15 Catalina +**
|
||||
>
|
||||
> - It took some time to support this cleanly. You may see posts,
|
||||
> examples, and tutorials using obsolete workarounds.
|
||||
> - Supporting it cleanly made macOS installs too complex to qualify
|
||||
> as single-user, so this type is no longer supported on macOS.
|
||||
|
||||
We recommend the multi-user install if it supports your platform and
|
||||
you can authenticate with `sudo`.
|
||||
As of Nix 2.1.0, the Nix installer will always default to creating a
|
||||
single-user installation, however opting in to the multi-user
|
||||
installation is highly recommended.
|
||||
|
||||
# Single User Installation
|
||||
|
||||
@@ -31,8 +23,8 @@ $ sh <(curl -L https://nixos.org/nix/install) --no-daemon
|
||||
```
|
||||
|
||||
This will perform a single-user installation of Nix, meaning that `/nix`
|
||||
is owned by the invoking user. You can run this under your usual user
|
||||
account or root. The script will invoke `sudo` to create `/nix`
|
||||
is owned by the invoking user. You should run this under your usual user
|
||||
account, *not* as root. The script will invoke `sudo` to create `/nix`
|
||||
if it doesn’t already exist. If you don’t have `sudo`, you should
|
||||
manually create `/nix` first as root, e.g.:
|
||||
|
||||
@@ -58,9 +50,9 @@ $ rm -rf /nix
|
||||
The multi-user Nix installation creates system users, and a system
|
||||
service for the Nix daemon.
|
||||
|
||||
**Supported Systems**
|
||||
- Linux running systemd, with SELinux disabled
|
||||
- macOS
|
||||
- Linux running systemd, with SELinux disabled
|
||||
|
||||
- macOS
|
||||
|
||||
You can instruct the installer to perform a multi-user installation on
|
||||
your system:
|
||||
@@ -71,11 +63,11 @@ $ sh <(curl -L https://nixos.org/nix/install) --daemon
|
||||
|
||||
The multi-user installation of Nix will create build users between the
|
||||
user IDs 30001 and 30032, and a group with the group ID 30000. You
|
||||
can run this under your usual user account or root. The script
|
||||
should run this under your usual user account, *not* as root. The script
|
||||
will invoke `sudo` as needed.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
>
|
||||
> If you need Nix to use a different group ID or user ID set, you will
|
||||
> have to download the tarball manually and [edit the install
|
||||
> script](#installing-from-a-binary-tarball).
|
||||
@@ -84,199 +76,185 @@ The installer will modify `/etc/bashrc`, and `/etc/zshrc` if they exist.
|
||||
The installer will first back up these files with a `.backup-before-nix`
|
||||
extension. The installer will also create `/etc/profile.d/nix.sh`.
|
||||
|
||||
## Uninstalling
|
||||
|
||||
### Linux
|
||||
|
||||
If you are on Linux with systemd:
|
||||
|
||||
1. Remove the Nix daemon service:
|
||||
|
||||
```console
|
||||
sudo systemctl stop nix-daemon.service
|
||||
sudo systemctl disable nix-daemon.socket nix-daemon.service
|
||||
sudo systemctl daemon-reload
|
||||
```
|
||||
|
||||
1. Remove systemd service files:
|
||||
|
||||
```console
|
||||
sudo rm /etc/systemd/system/nix-daemon.service /etc/systemd/system/nix-daemon.socket
|
||||
```
|
||||
|
||||
1. The installer script uses systemd-tmpfiles to create the socket directory.
|
||||
You may also want to remove the configuration for that:
|
||||
|
||||
```console
|
||||
sudo rm /etc/tmpfiles.d/nix-daemon.conf
|
||||
```
|
||||
|
||||
Remove files created by Nix:
|
||||
You can uninstall Nix with the following commands:
|
||||
|
||||
```console
|
||||
sudo rm -rf /nix /etc/nix /etc/profile/nix.sh ~root/.nix-profile ~root/.nix-defexpr ~root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels
|
||||
sudo rm -rf /etc/profile/nix.sh /etc/nix /nix ~root/.nix-profile ~root/.nix-defexpr ~root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels
|
||||
|
||||
# If you are on Linux with systemd, you will need to run:
|
||||
sudo systemctl stop nix-daemon.socket
|
||||
sudo systemctl stop nix-daemon.service
|
||||
sudo systemctl disable nix-daemon.socket
|
||||
sudo systemctl disable nix-daemon.service
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
# If you are on macOS, you will need to run:
|
||||
sudo launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
sudo rm /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
```
|
||||
|
||||
Remove build users and their group:
|
||||
|
||||
```console
|
||||
for i in $(seq 1 32); do
|
||||
sudo userdel nixbld$i
|
||||
done
|
||||
sudo groupdel nixbld
|
||||
```
|
||||
|
||||
There may also be references to Nix in
|
||||
|
||||
- `/etc/profile`
|
||||
- `/etc/bashrc`
|
||||
- `/etc/zshrc`
|
||||
|
||||
which you may remove.
|
||||
|
||||
### macOS
|
||||
|
||||
1. Edit `/etc/zshrc` and `/etc/bashrc` to remove the lines sourcing
|
||||
`nix-daemon.sh`, which should look like this:
|
||||
|
||||
```bash
|
||||
# Nix
|
||||
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
|
||||
. '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh'
|
||||
fi
|
||||
# End Nix
|
||||
```
|
||||
|
||||
If these files haven't been altered since installing Nix you can simply put
|
||||
the backups back in place:
|
||||
|
||||
```console
|
||||
sudo mv /etc/zshrc.backup-before-nix /etc/zshrc
|
||||
sudo mv /etc/bashrc.backup-before-nix /etc/bashrc
|
||||
```
|
||||
|
||||
This will stop shells from sourcing the file and bringing everything you
|
||||
installed using Nix in scope.
|
||||
|
||||
2. Stop and remove the Nix daemon services:
|
||||
|
||||
```console
|
||||
sudo launchctl unload /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
sudo rm /Library/LaunchDaemons/org.nixos.nix-daemon.plist
|
||||
sudo launchctl unload /Library/LaunchDaemons/org.nixos.darwin-store.plist
|
||||
sudo rm /Library/LaunchDaemons/org.nixos.darwin-store.plist
|
||||
```
|
||||
|
||||
This stops the Nix daemon and prevents it from being started next time you
|
||||
boot the system.
|
||||
|
||||
3. Remove the `nixbld` group and the `_nixbuildN` users:
|
||||
|
||||
```console
|
||||
sudo dscl . -delete /Groups/nixbld
|
||||
for u in $(sudo dscl . -list /Users | grep _nixbld); do sudo dscl . -delete /Users/$u; done
|
||||
```
|
||||
|
||||
This will remove all the build users that no longer serve a purpose.
|
||||
|
||||
4. Edit fstab using `sudo vifs` to remove the line mounting the Nix Store
|
||||
volume on `/nix`, which looks like
|
||||
`UUID=<uuid> /nix apfs rw,noauto,nobrowse,suid,owners` or
|
||||
`LABEL=Nix\040Store /nix apfs rw,nobrowse`. This will prevent automatic
|
||||
mounting of the Nix Store volume.
|
||||
|
||||
5. Edit `/etc/synthetic.conf` to remove the `nix` line. If this is the only
|
||||
line in the file you can remove it entirely, `sudo rm /etc/synthetic.conf`.
|
||||
This will prevent the creation of the empty `/nix` directory to provide a
|
||||
mountpoint for the Nix Store volume.
|
||||
|
||||
6. Remove the files Nix added to your system:
|
||||
|
||||
```console
|
||||
sudo rm -rf /etc/nix /var/root/.nix-profile /var/root/.nix-defexpr /var/root/.nix-channels ~/.nix-profile ~/.nix-defexpr ~/.nix-channels
|
||||
```
|
||||
|
||||
This gets rid of any data Nix may have created except for the store which is
|
||||
removed next.
|
||||
|
||||
7. Remove the Nix Store volume:
|
||||
|
||||
```console
|
||||
sudo diskutil apfs deleteVolume /nix
|
||||
```
|
||||
|
||||
This will remove the Nix Store volume and everything that was added to the
|
||||
store.
|
||||
|
||||
If the output indicates that the command couldn't remove the volume, you should
|
||||
make sure you don't have an _unmounted_ Nix Store volume. Look for a
|
||||
"Nix Store" volume in the output of the following command:
|
||||
|
||||
```console
|
||||
diskutil list
|
||||
```
|
||||
|
||||
If you _do_ see a "Nix Store" volume, delete it by re-running the diskutil
|
||||
deleteVolume command, but replace `/nix` with the store volume's `diskXsY`
|
||||
identifier.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> After you complete the steps here, you will still have an empty `/nix`
|
||||
> directory. This is an expected sign of a successful uninstall. The empty
|
||||
> `/nix` directory will disappear the next time you reboot.
|
||||
>
|
||||
> You do not have to reboot to finish uninstalling Nix. The uninstall is
|
||||
> complete. macOS (Catalina+) directly controls root directories and its
|
||||
> read-only root will prevent you from manually deleting the empty `/nix`
|
||||
> mountpoint.
|
||||
There may also be references to Nix in `/etc/profile`, `/etc/bashrc`,
|
||||
and `/etc/zshrc` which you may remove.
|
||||
|
||||
# macOS Installation
|
||||
[]{#sect-macos-installation-change-store-prefix}[]{#sect-macos-installation-encrypted-volume}[]{#sect-macos-installation-symlink}[]{#sect-macos-installation-recommended-notes}
|
||||
<!-- Note: anchors above to catch permalinks to old explanations -->
|
||||
|
||||
We believe we have ironed out how to cleanly support the read-only root
|
||||
on modern macOS. New installs will do this automatically.
|
||||
Starting with macOS 10.15 (Catalina), the root filesystem is read-only.
|
||||
This means `/nix` can no longer live on your system volume, and that
|
||||
you'll need a workaround to install Nix.
|
||||
|
||||
This section previously detailed the situation, options, and trade-offs,
|
||||
but it now only outlines what the installer does. You don't need to know
|
||||
this to run the installer, but it may help if you run into trouble:
|
||||
The recommended approach, which creates an unencrypted APFS volume for
|
||||
your Nix store and a "synthetic" empty directory to mount it over at
|
||||
`/nix`, is least likely to impair Nix or your system.
|
||||
|
||||
- create a new APFS volume for your Nix store
|
||||
- update `/etc/synthetic.conf` to direct macOS to create a "synthetic"
|
||||
empty root directory to mount your volume
|
||||
- specify mount options for the volume in `/etc/fstab`
|
||||
- `rw`: read-write
|
||||
- `noauto`: prevent the system from auto-mounting the volume (so the
|
||||
LaunchDaemon mentioned below can control mounting it, and to avoid
|
||||
masking problems with that mounting service).
|
||||
- `nobrowse`: prevent the Nix Store volume from showing up on your
|
||||
desktop; also keeps Spotlight from spending resources to index
|
||||
this volume
|
||||
<!-- TODO:
|
||||
- `suid`: honor setuid? surely not? ...
|
||||
- `owners`: honor file ownership on the volume
|
||||
> **Note**
|
||||
>
|
||||
> With all separate-volume approaches, it's possible something on your
|
||||
> system (particularly daemons/services and restored apps) may need
|
||||
> access to your Nix store before the volume is mounted. Adding
|
||||
> additional encryption makes this more likely.
|
||||
|
||||
For now I'll avoid pretending to understand suid/owners more
|
||||
than I do. There've been some vague reports of file-ownership
|
||||
and permission issues, particularly in cloud/VM/headless setups.
|
||||
My pet theory is that this has something to do with these setups
|
||||
not having a token that gets delegated to initial/admin accounts
|
||||
on macOS. See scripts/create-darwin-volume.sh for a little more.
|
||||
If you're using a recent Mac with a [T2
|
||||
chip](https://www.apple.com/euro/mac/shared/docs/Apple_T2_Security_Chip_Overview.pdf),
|
||||
your drive will still be encrypted at rest (in which case "unencrypted"
|
||||
is a bit of a misnomer). To use this approach, just install Nix with:
|
||||
|
||||
In any case, by Dec 4 2021, it _seems_ like some combination of
|
||||
suid, owners, and calling diskutil enableOwnership have stopped
|
||||
new reports from coming in. But I hesitate to celebrate because we
|
||||
haven't really named and catalogued the behavior, understood what
|
||||
we're fixing, and validated that all 3 components are essential.
|
||||
-->
|
||||
- if you have FileVault enabled
|
||||
- generate an encryption password
|
||||
- put it in your system Keychain
|
||||
- use it to encrypt the volume
|
||||
- create a system LaunchDaemon to mount this volume early enough in the
|
||||
boot process to avoid problems loading or restoring any programs that
|
||||
need access to your Nix store
|
||||
```console
|
||||
$ sh <(curl -L https://nixos.org/nix/install) --darwin-use-unencrypted-nix-store-volume
|
||||
```
|
||||
|
||||
If you don't like the sound of this, you'll want to weigh the other
|
||||
approaches and tradeoffs detailed in this section.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> All of the known workarounds have drawbacks, but we hope better
|
||||
> solutions will be available in the future. Some that we have our eye
|
||||
> on are:
|
||||
>
|
||||
> 1. A true firmlink would enable the Nix store to live on the primary
|
||||
> data volume without the build problems caused by the symlink
|
||||
> approach. End users cannot currently create true firmlinks.
|
||||
>
|
||||
> 2. If the Nix store volume shared FileVault encryption with the
|
||||
> primary data volume (probably by using the same volume group and
|
||||
> role), FileVault encryption could be easily supported by the
|
||||
> installer without requiring manual setup by each user.
|
||||
|
||||
## Change the Nix store path prefix
|
||||
|
||||
Changing the default prefix for the Nix store is a simple approach which
|
||||
enables you to leave it on your root volume, where it can take full
|
||||
advantage of FileVault encryption if enabled. Unfortunately, this
|
||||
approach also opts your device out of some benefits that are enabled by
|
||||
using the same prefix across systems:
|
||||
|
||||
- Your system won't be able to take advantage of the binary cache
|
||||
(unless someone is able to stand up and support duplicate caching
|
||||
infrastructure), which means you'll spend more time waiting for
|
||||
builds.
|
||||
|
||||
- It's harder to build and deploy packages to Linux systems.
|
||||
|
||||
It would also possible (and often requested) to just apply this change
|
||||
ecosystem-wide, but it's an intrusive process that has side effects we
|
||||
want to avoid for now.
|
||||
|
||||
## Use a separate encrypted volume
|
||||
|
||||
If you like, you can also add encryption to the recommended approach
|
||||
taken by the installer. You can do this by pre-creating an encrypted
|
||||
volume before you run the installer--or you can run the installer and
|
||||
encrypt the volume it creates later.
|
||||
|
||||
In either case, adding encryption to a second volume isn't quite as
|
||||
simple as enabling FileVault for your boot volume. Before you dive in,
|
||||
there are a few things to weigh:
|
||||
|
||||
1. The additional volume won't be encrypted with your existing
|
||||
FileVault key, so you'll need another mechanism to decrypt the
|
||||
volume.
|
||||
|
||||
2. You can store the password in Keychain to automatically decrypt the
|
||||
volume on boot--but it'll have to wait on Keychain and may not mount
|
||||
before your GUI apps restore. If any of your launchd agents or apps
|
||||
depend on Nix-installed software (for example, if you use a
|
||||
Nix-installed login shell), the restore may fail or break.
|
||||
|
||||
On a case-by-case basis, you may be able to work around this problem
|
||||
by using `wait4path` to block execution until your executable is
|
||||
available.
|
||||
|
||||
It's also possible to decrypt and mount the volume earlier with a
|
||||
login hook--but this mechanism appears to be deprecated and its
|
||||
future is unclear.
|
||||
|
||||
3. You can hard-code the password in the clear, so that your store
|
||||
volume can be decrypted before Keychain is available.
|
||||
|
||||
If you are comfortable navigating these tradeoffs, you can encrypt the
|
||||
volume with something along the lines of:
|
||||
|
||||
```console
|
||||
$ diskutil apfs enableFileVault /nix -user disk
|
||||
```
|
||||
|
||||
## Symlink the Nix store to a custom location
|
||||
|
||||
Another simple approach is using `/etc/synthetic.conf` to symlink the
|
||||
Nix store to the data volume. This option also enables your store to
|
||||
share any configured FileVault encryption. Unfortunately, builds that
|
||||
resolve the symlink may leak the canonical path or even fail.
|
||||
|
||||
Because of these downsides, we can't recommend this approach.
|
||||
|
||||
## Notes on the recommended approach
|
||||
|
||||
This section goes into a little more detail on the recommended approach.
|
||||
You don't need to understand it to run the installer, but it can serve
|
||||
as a helpful reference if you run into trouble.
|
||||
|
||||
1. In order to compose user-writable locations into the new read-only
|
||||
system root, Apple introduced a new concept called `firmlinks`,
|
||||
which it describes as a "bi-directional wormhole" between two
|
||||
filesystems. You can see the current firmlinks in
|
||||
`/usr/share/firmlinks`. Unfortunately, firmlinks aren't (currently?)
|
||||
user-configurable.
|
||||
|
||||
For special cases like NFS mount points or package manager roots,
|
||||
[synthetic.conf(5)](https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man5/synthetic.conf.5.html)
|
||||
supports limited user-controlled file-creation (of symlinks, and
|
||||
synthetic empty directories) at `/`. To create a synthetic empty
|
||||
directory for mounting at `/nix`, add the following line to
|
||||
`/etc/synthetic.conf` (create it if necessary):
|
||||
|
||||
nix
|
||||
|
||||
2. This configuration is applied at boot time, but you can use
|
||||
`apfs.util` to trigger creation (not deletion) of new entries
|
||||
without a reboot:
|
||||
|
||||
```console
|
||||
$ /System/Library/Filesystems/apfs.fs/Contents/Resources/apfs.util -B
|
||||
```
|
||||
|
||||
3. Create the new APFS volume with diskutil:
|
||||
|
||||
```console
|
||||
$ sudo diskutil apfs addVolume diskX APFS 'Nix Store' -mountpoint /nix
|
||||
```
|
||||
|
||||
4. Using `vifs`, add the new mount to `/etc/fstab`. If it doesn't
|
||||
already have other entries, it should look something like:
|
||||
|
||||
#
|
||||
# Warning - this file should only be modified with vifs(8)
|
||||
#
|
||||
# Failure to do so is unsupported and may be destructive.
|
||||
#
|
||||
LABEL=Nix\040Store /nix apfs rw,nobrowse
|
||||
|
||||
The nobrowse setting will keep Spotlight from indexing this volume,
|
||||
and keep it from showing up on your desktop.
|
||||
|
||||
# Installing a pinned Nix version from a URL
|
||||
|
||||
|
||||
@@ -1,59 +0,0 @@
|
||||
# Using Nix within Docker
|
||||
|
||||
To run the latest stable release of Nix with Docker run the following command:
|
||||
|
||||
```console
|
||||
$ docker run -ti nixos/nix
|
||||
Unable to find image 'nixos/nix:latest' locally
|
||||
latest: Pulling from nixos/nix
|
||||
5843afab3874: Pull complete
|
||||
b52bf13f109c: Pull complete
|
||||
1e2415612aa3: Pull complete
|
||||
Digest: sha256:27f6e7f60227e959ee7ece361f75d4844a40e1cc6878b6868fe30140420031ff
|
||||
Status: Downloaded newer image for nixos/nix:latest
|
||||
35ca4ada6e96:/# nix --version
|
||||
nix (Nix) 2.3.12
|
||||
35ca4ada6e96:/# exit
|
||||
```
|
||||
|
||||
# What is included in Nix's Docker image?
|
||||
|
||||
The official Docker image is created using `pkgs.dockerTools.buildLayeredImage`
|
||||
(and not with `Dockerfile` as it is usual with Docker images). You can still
|
||||
base your custom Docker image on it as you would do with any other Docker
|
||||
image.
|
||||
|
||||
The Docker image is also not based on any other image and includes minimal set
|
||||
of runtime dependencies that are required to use Nix:
|
||||
|
||||
- pkgs.nix
|
||||
- pkgs.bashInteractive
|
||||
- pkgs.coreutils-full
|
||||
- pkgs.gnutar
|
||||
- pkgs.gzip
|
||||
- pkgs.gnugrep
|
||||
- pkgs.which
|
||||
- pkgs.curl
|
||||
- pkgs.less
|
||||
- pkgs.wget
|
||||
- pkgs.man
|
||||
- pkgs.cacert.out
|
||||
- pkgs.findutils
|
||||
|
||||
# Docker image with the latest development version of Nix
|
||||
|
||||
To get the latest image that was built by [Hydra](https://hydra.nixos.org) run
|
||||
the following command:
|
||||
|
||||
```console
|
||||
$ curl -L https://hydra.nixos.org/job/nix/master/dockerImage.x86_64-linux/latest/download/1 | docker load
|
||||
$ docker run -ti nix:2.5pre20211105
|
||||
```
|
||||
|
||||
You can also build a Docker image from source yourself:
|
||||
|
||||
```console
|
||||
$ nix build ./\#hydraJobs.dockerImage.x86_64-linux
|
||||
$ docker load -i ./result/image.tar.gz
|
||||
$ docker run -ti nix:2.5pre20211105
|
||||
```
|
||||
@@ -1,4 +1,4 @@
|
||||
# Installing Nix from Source
|
||||
|
||||
If no binary package is available or if you want to hack on Nix, you
|
||||
can build Nix from its Git repository.
|
||||
If no binary package is available, you can download and compile a source
|
||||
distribution.
|
||||
|
||||
@@ -1,9 +1,14 @@
|
||||
# Obtaining the Source
|
||||
# Obtaining a Source Distribution
|
||||
|
||||
The most recent sources of Nix can be obtained from its [Git
|
||||
repository](https://github.com/NixOS/nix). For example, the following
|
||||
command will check out the latest revision into a directory called
|
||||
`nix`:
|
||||
The source tarball of the most recent stable release can be downloaded
|
||||
from the [Nix homepage](http://nixos.org/nix/download.html). You can
|
||||
also grab the [most recent development
|
||||
release](http://hydra.nixos.org/job/nix/master/release/latest-finished#tabs-constituents).
|
||||
|
||||
Alternatively, the most recent sources of Nix can be obtained from its
|
||||
[Git repository](https://github.com/NixOS/nix). For example, the
|
||||
following command will check out the latest revision into a directory
|
||||
called `nix`:
|
||||
|
||||
```console
|
||||
$ git clone https://github.com/NixOS/nix
|
||||
|
||||
@@ -2,8 +2,9 @@
|
||||
|
||||
- GNU Autoconf (<https://www.gnu.org/software/autoconf/>) and the
|
||||
autoconf-archive macro collection
|
||||
(<https://www.gnu.org/software/autoconf-archive/>). These are
|
||||
needed to run the bootstrap script.
|
||||
(<https://www.gnu.org/software/autoconf-archive/>). These are only
|
||||
needed to run the bootstrap script, and are not necessary if your
|
||||
source distribution came with a pre-built `./configure` script.
|
||||
|
||||
- GNU Make.
|
||||
|
||||
@@ -25,6 +26,15 @@
|
||||
available for download from the official repository
|
||||
<https://github.com/google/brotli>.
|
||||
|
||||
- The bzip2 compressor program and the `libbz2` library. Thus you must
|
||||
have bzip2 installed, including development headers and libraries.
|
||||
If your distribution does not provide these, you can obtain bzip2
|
||||
from
|
||||
<https://sourceware.org/bzip2/>.
|
||||
|
||||
- `liblzma`, which is provided by XZ Utils. If your distribution does
|
||||
not provide this, you can get it from <https://tukaani.org/xz/>.
|
||||
|
||||
- cURL and its library. If your distribution does not provide it, you
|
||||
can get it from <https://curl.haxx.se/>.
|
||||
|
||||
@@ -44,11 +54,6 @@
|
||||
obtained from the its repository
|
||||
<https://github.com/troglobit/editline>.
|
||||
|
||||
- The `libsodium` library for verifying cryptographic signatures
|
||||
of contents fetched from binary caches.
|
||||
It can be obtained from the official web site
|
||||
<https://libsodium.org>.
|
||||
|
||||
- Recent versions of Bison and Flex to build the parser. (This is
|
||||
because Nix needs GLR support in Bison and reentrancy support in
|
||||
Flex.) For Bison, you need version 2.6, which can be obtained from
|
||||
@@ -56,18 +61,11 @@
|
||||
you need version 2.5.35, which is available on
|
||||
[SourceForge](http://lex.sourceforge.net/). Slightly older versions
|
||||
may also work, but ancient versions like the ubiquitous 2.5.4a
|
||||
won't.
|
||||
won't. Note that these are only required if you modify the parser or
|
||||
when you are building from the Git repository.
|
||||
|
||||
- The `libseccomp` is used to provide syscall filtering on Linux. This
|
||||
is an optional dependency and can be disabled passing a
|
||||
`--disable-seccomp-sandboxing` option to the `configure` script (Not
|
||||
recommended unless your system doesn't support `libseccomp`). To get
|
||||
the library, visit <https://github.com/seccomp/libseccomp>.
|
||||
|
||||
- On 64-bit x86 machines only, `libcpuid` library
|
||||
is used to determine which microarchitecture levels are supported
|
||||
(e.g., as whether to have `x86_64-v2-linux` among additional system types).
|
||||
The library is available from its homepage
|
||||
<http://libcpuid.sourceforge.net>.
|
||||
This is an optional dependency and can be disabled
|
||||
by providing a `--disable-cpuid` to the `configure` script.
|
||||
|
||||
@@ -4,4 +4,4 @@ Nix is currently supported on the following platforms:
|
||||
|
||||
- Linux (i686, x86\_64, aarch64).
|
||||
|
||||
- macOS (x86\_64, aarch64).
|
||||
- macOS (x86\_64).
|
||||
|
||||
@@ -76,7 +76,7 @@ there after an upgrade. This means that you can _roll back_ to the
|
||||
old version:
|
||||
|
||||
```console
|
||||
$ nix-env --upgrade -A nixpkgs.some-package
|
||||
$ nix-env --upgrade some-packages
|
||||
$ nix-env --rollback
|
||||
```
|
||||
|
||||
@@ -104,7 +104,7 @@ a currently running program.
|
||||
|
||||
Packages are built from _Nix expressions_, which is a simple
|
||||
functional language. A Nix expression describes everything that goes
|
||||
into a package build task (a “derivation”): other packages, sources,
|
||||
into a package build action (a “derivation”): other packages, sources,
|
||||
the build script, environment variables for the build script, etc.
|
||||
Nix tries very hard to ensure that Nix expressions are
|
||||
_deterministic_: building a Nix expression twice should yield the same
|
||||
@@ -122,12 +122,12 @@ Nix expressions generally describe how to build a package from
|
||||
source, so an installation action like
|
||||
|
||||
```console
|
||||
$ nix-env --install -A nixpkgs.firefox
|
||||
$ nix-env --install firefox
|
||||
```
|
||||
|
||||
_could_ cause quite a bit of build activity, as not only Firefox but
|
||||
also all its dependencies (all the way up to the C library and the
|
||||
compiler) would have to be built, at least if they are not already in the
|
||||
compiler) would have to built, at least if they are not already in the
|
||||
Nix store. This is a _source deployment model_. For most users,
|
||||
building from source is not very pleasant as it takes far too long.
|
||||
However, Nix can automatically skip building from source and instead
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
</dl>
|
||||
@@ -1,581 +0,0 @@
|
||||
# Nix Language
|
||||
|
||||
The Nix language is
|
||||
|
||||
- *domain-specific*
|
||||
|
||||
It only exists for the Nix package manager:
|
||||
to describe packages and configurations as well as their variants and compositions.
|
||||
It is not intended for general purpose use.
|
||||
|
||||
- *declarative*
|
||||
|
||||
There is no notion of executing sequential steps.
|
||||
Dependencies between operations are established only through data.
|
||||
|
||||
- *pure*
|
||||
|
||||
Values cannot change during computation.
|
||||
Functions always produce the same output if their input does not change.
|
||||
|
||||
- *functional*
|
||||
|
||||
Functions are like any other value.
|
||||
Functions can be assigned to names, taken as arguments, or returned by functions.
|
||||
|
||||
- *lazy*
|
||||
|
||||
Expressions are only evaluated when their value is needed.
|
||||
|
||||
- *dynamically typed*
|
||||
|
||||
Type errors are only detected when expressions are evaluated.
|
||||
|
||||
# Overview
|
||||
|
||||
This is an incomplete overview of language features, by example.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>
|
||||
Example
|
||||
</th>
|
||||
<th>
|
||||
Description
|
||||
</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
|
||||
*Basic values*
|
||||
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`"hello world"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A string
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
```
|
||||
''
|
||||
multi
|
||||
line
|
||||
string
|
||||
''
|
||||
```
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A multi-line string. Strips common prefixed whitespace. Evaluates to `"multi\n line\n string"`.
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`"hello ${ { a = "world" }.a }"`
|
||||
|
||||
`"1 2 ${toString 3}"`
|
||||
|
||||
`"${pkgs.bash}/bin/sh"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
String interpolation (expands to `"hello world"`, `"1 2 3"`, `"/nix/store/<hash>-bash-<version>/bin/sh"`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`true`, `false`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Booleans
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`null`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Null value
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`123`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
An integer
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`3.141`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A floating point number
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`/etc`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
An absolute path
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`./foo.png`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A path relative to the file containing this Nix expression
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`~/.config`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A home path. Evaluates to the `"<user's home directory>/.config"`.
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
<nixpkgs>
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Search path. Value determined by [`$NIX_PATH` environment variable](../command-ref/env-common.md#env-NIX_PATH).
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
*Compound values*
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x = 1; y = 2; }`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A set with attributes named `x` and `y`
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ foo.bar = 1; }`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A nested set, equivalent to `{ foo = { bar = 1; }; }`
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`rec { x = "foo"; y = x + "bar"; }`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A recursive set, equivalent to `{ x = "foo"; y = "foobar"; }`
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`[ "foo" "bar" "baz" ]`
|
||||
|
||||
`[ 1 2 3 ]`
|
||||
|
||||
`[ (f 1) { a = 1; b = 2; } [ "c" ] ]`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Lists with three elements.
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
*Operators*
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`"foo" + "bar"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
String concatenation
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`1 + 2`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Integer addition
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`"foo" == "f" + "oo"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Equality test (evaluates to `true`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`"foo" != "bar"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Inequality test (evaluates to `true`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`!true`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Boolean negation
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x = 1; y = 2; }.x`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Attribute selection (evaluates to `1`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x = 1; y = 2; }.z or 3`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Attribute selection with default (evaluates to `3`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x = 1; y = 2; } // { z = 3; }`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Merge two sets (attributes in the right-hand set taking precedence)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
*Control structures*
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`if 1 + 1 == 2 then "yes!" else "no!"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Conditional expression
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`assert 1 + 1 == 2; "yes!"`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Assertion check (evaluates to `"yes!"`).
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`let x = "foo"; y = "bar"; in x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Variable definition
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`with builtins; head [ 1 2 3 ]`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Add all attributes from the given set to the scope (evaluates to `1`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
*Functions (lambdas)*
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`x: x + 1`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function that expects an integer and returns it increased by 1
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`x: y: x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Curried function, equivalent to `x: (y: x + y)`. Can be used like a function that takes two arguments and returns their sum.
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`(x: x + 1) 100`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function call (evaluates to 101)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`let inc = x: x + 1; in inc (inc (inc 100))`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function bound to a variable and subsequently called by name (evaluates to 103)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x, y }: x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function that expects a set with required attributes `x` and `y` and concatenates them
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x, y ? "bar" }: x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function that expects a set with required attribute `x` and optional `y`, using `"bar"` as default value for `y`
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x, y, ... }: x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function that expects a set with required attributes `x` and `y` and ignores any other attributes
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`{ x, y } @ args: x + y`
|
||||
|
||||
`args @ { x, y }: x + y`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
A function that expects a set with required attributes `x` and `y`, and binds the whole set to `args`
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
*Built-in functions*
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`import ./foo.nix`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Load and return Nix expression in given file
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>
|
||||
|
||||
`map (x: x + x) [ 1 2 3 ]`
|
||||
|
||||
</td>
|
||||
<td>
|
||||
|
||||
Apply a function to every element of a list (evaluates to `[ 2 4 6 ]`)
|
||||
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
@@ -1,167 +0,0 @@
|
||||
# Operators
|
||||
|
||||
| Name | Syntax | Associativity | Precedence |
|
||||
|----------------------------------------|--------------------------------------------|---------------|------------|
|
||||
| [Attribute selection] | *attrset* `.` *attrpath* \[ `or` *expr* \] | none | 1 |
|
||||
| Function application | *func* *expr* | left | 2 |
|
||||
| [Arithmetic negation][arithmetic] | `-` *number* | none | 3 |
|
||||
| [Has attribute] | *attrset* `?` *attrpath* | none | 4 |
|
||||
| List concatenation | *list* `++` *list* | right | 5 |
|
||||
| [Multiplication][arithmetic] | *number* `*` *number* | left | 6 |
|
||||
| [Division][arithmetic] | *number* `/` *number* | left | 6 |
|
||||
| [Subtraction][arithmetic] | *number* `-` *number* | left | 7 |
|
||||
| [Addition][arithmetic] | *number* `+` *number* | left | 7 |
|
||||
| [String concatenation] | *string* `+` *string* | left | 7 |
|
||||
| [Path concatenation] | *path* `+` *path* | left | 7 |
|
||||
| [Path and string concatenation] | *path* `+` *string* | left | 7 |
|
||||
| [String and path concatenation] | *string* `+` *path* | left | 7 |
|
||||
| Logical negation (`NOT`) | `!` *bool* | none | 8 |
|
||||
| [Update] | *attrset* `//` *attrset* | right | 9 |
|
||||
| [Less than][Comparison] | *expr* `<` *expr* | none | 10 |
|
||||
| [Less than or equal to][Comparison] | *expr* `<=` *expr* | none | 10 |
|
||||
| [Greater than][Comparison] | *expr* `>` *expr* | none | 10 |
|
||||
| [Greater than or equal to][Comparison] | *expr* `>=` *expr* | none | 10 |
|
||||
| [Equality] | *expr* `==` *expr* | none | 11 |
|
||||
| Inequality | *expr* `!=` *expr* | none | 11 |
|
||||
| Logical conjunction (`AND`) | *bool* `&&` *bool* | left | 12 |
|
||||
| Logical disjunction (`OR`) | *bool* `||` *bool* | left | 13 |
|
||||
| [Logical implication] | *bool* `->` *bool* | none | 14 |
|
||||
|
||||
[string]: ./values.md#type-string
|
||||
[path]: ./values.md#type-path
|
||||
[number]: ./values.md#type-number
|
||||
[list]: ./values.md#list
|
||||
[attribute set]: ./values.md#attribute-set
|
||||
|
||||
## Attribute selection
|
||||
|
||||
Select the attribute denoted by attribute path *attrpath* from [attribute set] *attrset*.
|
||||
If the attribute doesn’t exist, return *value* if provided, otherwise abort evaluation.
|
||||
|
||||
<!-- FIXME: the following should to into its own language syntax section, but that needs more work to fit in well -->
|
||||
|
||||
An attribute path is a dot-separated list of attribute names.
|
||||
An attribute name can be an identifier or a string.
|
||||
|
||||
> *attrpath* = *name* [ `.` *name* ]...
|
||||
> *name* = *identifier* | *string*
|
||||
> *identifier* ~ `[a-zA-Z_][a-zA-Z0-9_'-]*`
|
||||
|
||||
[Attribute selection]: #attribute-selection
|
||||
|
||||
## Has attribute
|
||||
|
||||
> *attrset* `?` *attrpath*
|
||||
|
||||
Test whether [attribute set] *attrset* contains the attribute denoted by *attrpath*.
|
||||
The result is a [Boolean] value.
|
||||
|
||||
[Boolean]: ./values.md#type-boolean
|
||||
|
||||
[Has attribute]: #has-attribute
|
||||
|
||||
## Arithmetic
|
||||
|
||||
Numbers are type-compatible:
|
||||
Pure integer operations will always return integers, whereas any operation involving at least one floating point number return a floating point number.
|
||||
|
||||
See also [Comparison] and [Equality].
|
||||
|
||||
The `+` operator is overloaded to also work on strings and paths.
|
||||
|
||||
[arithmetic]: #arithmetic
|
||||
|
||||
## String concatenation
|
||||
|
||||
> *string* `+` *string*
|
||||
|
||||
Concatenate two [string]s and merge their string contexts.
|
||||
|
||||
[String concatenation]: #string-concatenation
|
||||
|
||||
## Path concatenation
|
||||
|
||||
> *path* `+` *path*
|
||||
|
||||
Concatenate two [path]s.
|
||||
The result is a path.
|
||||
|
||||
[Path concatenation]: #path-concatenation
|
||||
|
||||
## Path and string concatenation
|
||||
|
||||
> *path* + *string*
|
||||
|
||||
Concatenate *[path]* with *[string]*.
|
||||
The result is a path.
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> The string must not have a string context that refers to a [store path].
|
||||
|
||||
[Path and string concatenation]: #path-and-string-concatenation
|
||||
|
||||
## String and path concatenation
|
||||
|
||||
> *string* + *path*
|
||||
|
||||
Concatenate *[string]* with *[path]*.
|
||||
The result is a string.
|
||||
|
||||
> **Important**
|
||||
>
|
||||
> The file or directory at *path* must exist and is copied to the [store].
|
||||
> The path appears in the result as the corresponding [store path].
|
||||
|
||||
[store path]: ../glossary.md#gloss-store-path
|
||||
[store]: ../glossary.md#gloss-store
|
||||
|
||||
[Path and string concatenation]: #path-and-string-concatenation
|
||||
|
||||
## Update
|
||||
|
||||
> *attrset1* + *attrset2*
|
||||
|
||||
Update [attribute set] *attrset1* with names and values from *attrset2*.
|
||||
|
||||
The returned attribute set will have of all the attributes in *e1* and *e2*.
|
||||
If an attribute name is present in both, the attribute value from the former is taken.
|
||||
|
||||
[Update]: #update
|
||||
|
||||
## Comparison
|
||||
|
||||
Comparison is
|
||||
|
||||
- [arithmetic] for [number]s
|
||||
- lexicographic for [string]s and [path]s
|
||||
- item-wise lexicographic for [list]s:
|
||||
elements at the same index in both lists are compared according to their type and skipped if they are equal.
|
||||
|
||||
All comparison operators are implemented in terms of `<`, and the following equivalencies hold:
|
||||
|
||||
| comparison | implementation |
|
||||
|--------------|-----------------------|
|
||||
| *a* `<=` *b* | `! (` *b* `<` *a* `)` |
|
||||
| *a* `>` *b* | *b* `<` *a* |
|
||||
| *a* `>=` *b* | `! (` *a* `<` *b* `)` |
|
||||
|
||||
[Comparison]: #comparison-operators
|
||||
|
||||
## Equality
|
||||
|
||||
- [Attribute sets][attribute set] and [list]s are compared recursively, and therefore are fully evaluated.
|
||||
- Comparison of [function]s always returns `false`.
|
||||
- Numbers are type-compatible, see [arithmetic] operators.
|
||||
- Floating point numbers only differ up to a limited precision.
|
||||
|
||||
[function]: ./constructs.md#functions
|
||||
|
||||
[Equality]: #equality
|
||||
|
||||
## Logical implication
|
||||
|
||||
Equivalent to `!`*b1* `||` *b2*.
|
||||
|
||||
[Logical implication]: #logical-implication
|
||||
|
||||
@@ -1,82 +0,0 @@
|
||||
# String interpolation
|
||||
|
||||
String interpolation is a language feature where a [string], [path], or [attribute name] can contain expressions enclosed in `${ }` (dollar-sign with curly brackets).
|
||||
|
||||
Such a string is an *interpolated string*, and an expression inside is an *interpolated expression*.
|
||||
|
||||
Interpolated expressions must evaluate to one of the following:
|
||||
|
||||
- a [string]
|
||||
- a [path]
|
||||
- a [derivation]
|
||||
|
||||
[string]: ./values.md#type-string
|
||||
[path]: ./values.md#type-path
|
||||
[attribute name]: ./values.md#attribute-set
|
||||
[derivation]: ../glossary.md#gloss-derivation
|
||||
|
||||
## Examples
|
||||
|
||||
### String
|
||||
|
||||
Rather than writing
|
||||
|
||||
```nix
|
||||
"--with-freetype2-library=" + freetype + "/lib"
|
||||
```
|
||||
|
||||
(where `freetype` is a [derivation]), you can instead write
|
||||
|
||||
```nix
|
||||
"--with-freetype2-library=${freetype}/lib"
|
||||
```
|
||||
|
||||
The latter is automatically translated to the former.
|
||||
|
||||
A more complicated example (from the Nix expression for [Qt](http://www.trolltech.com/products/qt)):
|
||||
|
||||
```nix
|
||||
configureFlags = "
|
||||
-system-zlib -system-libpng -system-libjpeg
|
||||
${if openglSupport then "-dlopen-opengl
|
||||
-L${mesa}/lib -I${mesa}/include
|
||||
-L${libXmu}/lib -I${libXmu}/include" else ""}
|
||||
${if threadSupport then "-thread" else "-no-thread"}
|
||||
";
|
||||
```
|
||||
|
||||
Note that Nix expressions and strings can be arbitrarily nested;
|
||||
in this case the outer string contains various interpolated expressions that themselves contain strings (e.g., `"-thread"`), some of which in turn contain interpolated expressions (e.g., `${mesa}`).
|
||||
|
||||
### Path
|
||||
|
||||
Rather than writing
|
||||
|
||||
```nix
|
||||
./. + "/" + foo + "-" + bar + ".nix"
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```nix
|
||||
./. + "/${foo}-${bar}.nix"
|
||||
```
|
||||
|
||||
you can instead write
|
||||
|
||||
```nix
|
||||
./${foo}-${bar}.nix
|
||||
```
|
||||
|
||||
### Attribute name
|
||||
|
||||
Attribute names can be created dynamically with string interpolation:
|
||||
|
||||
```nix
|
||||
let name = "foo"; in
|
||||
{
|
||||
${name} = "bar";
|
||||
}
|
||||
```
|
||||
|
||||
{ foo = "bar"; }
|
||||
@@ -1,251 +0,0 @@
|
||||
# Data Types
|
||||
|
||||
## Primitives
|
||||
|
||||
- <a id="type-string" href="#type-string">String</a>
|
||||
|
||||
*Strings* can be written in three ways.
|
||||
|
||||
The most common way is to enclose the string between double quotes,
|
||||
e.g., `"foo bar"`. Strings can span multiple lines. The special
|
||||
characters `"` and `\` and the character sequence `${` must be
|
||||
escaped by prefixing them with a backslash (`\`). Newlines, carriage
|
||||
returns and tabs can be written as `\n`, `\r` and `\t`,
|
||||
respectively.
|
||||
|
||||
You can include the results of other expressions into a string by enclosing them in `${ }`, a feature known as [string interpolation].
|
||||
|
||||
[string interpolation]: ./string-interpolation.md
|
||||
|
||||
The second way to write string literals is as an *indented string*,
|
||||
which is enclosed between pairs of *double single-quotes*, like so:
|
||||
|
||||
```nix
|
||||
''
|
||||
This is the first line.
|
||||
This is the second line.
|
||||
This is the third line.
|
||||
''
|
||||
```
|
||||
|
||||
This kind of string literal intelligently strips indentation from
|
||||
the start of each line. To be precise, it strips from each line a
|
||||
number of spaces equal to the minimal indentation of the string as a
|
||||
whole (disregarding the indentation of empty lines). For instance,
|
||||
the first and second line are indented two spaces, while the third
|
||||
line is indented four spaces. Thus, two spaces are stripped from
|
||||
each line, so the resulting string is
|
||||
|
||||
```nix
|
||||
"This is the first line.\nThis is the second line.\n This is the third line.\n"
|
||||
```
|
||||
|
||||
Note that the whitespace and newline following the opening `''` is
|
||||
ignored if there is no non-whitespace text on the initial line.
|
||||
|
||||
Indented strings support [string interpolation].
|
||||
|
||||
Since `${` and `''` have special meaning in indented strings, you
|
||||
need a way to quote them. `$` can be escaped by prefixing it with
|
||||
`''` (that is, two single quotes), i.e., `''$`. `''` can be escaped
|
||||
by prefixing it with `'`, i.e., `'''`. `$` removes any special
|
||||
meaning from the following `$`. Linefeed, carriage-return and tab
|
||||
characters can be written as `''\n`, `''\r`, `''\t`, and `''\`
|
||||
escapes any other character.
|
||||
|
||||
Indented strings are primarily useful in that they allow multi-line
|
||||
string literals to follow the indentation of the enclosing Nix
|
||||
expression, and that less escaping is typically necessary for
|
||||
strings representing languages such as shell scripts and
|
||||
configuration files because `''` is much less common than `"`.
|
||||
Example:
|
||||
|
||||
```nix
|
||||
stdenv.mkDerivation {
|
||||
...
|
||||
postInstall =
|
||||
''
|
||||
mkdir $out/bin $out/etc
|
||||
cp foo $out/bin
|
||||
echo "Hello World" > $out/etc/foo.conf
|
||||
${if enableBar then "cp bar $out/bin" else ""}
|
||||
'';
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
Finally, as a convenience, *URIs* as defined in appendix B of
|
||||
[RFC 2396](http://www.ietf.org/rfc/rfc2396.txt) can be written *as
|
||||
is*, without quotes. For instance, the string
|
||||
`"http://example.org/foo.tar.bz2"` can also be written as
|
||||
`http://example.org/foo.tar.bz2`.
|
||||
|
||||
- <a id="type-number" href="#type-number">Number</a>
|
||||
|
||||
Numbers, which can be *integers* (like `123`) or *floating point*
|
||||
(like `123.43` or `.27e13`).
|
||||
|
||||
See [arithmetic] and [comparison] operators for semantics.
|
||||
|
||||
[arithmetic]: ./operators.md#arithmetic
|
||||
[comparison]: ./operators.md#comparison
|
||||
|
||||
- <a id="type-path" href="#type-path">Path</a>
|
||||
|
||||
*Paths*, e.g., `/bin/sh` or `./builder.sh`. A path must contain at
|
||||
least one slash to be recognised as such. For instance, `builder.sh`
|
||||
is not a path: it's parsed as an expression that selects the
|
||||
attribute `sh` from the variable `builder`. If the file name is
|
||||
relative, i.e., if it does not begin with a slash, it is made
|
||||
absolute at parse time relative to the directory of the Nix
|
||||
expression that contained it. For instance, if a Nix expression in
|
||||
`/foo/bar/bla.nix` refers to `../xyzzy/fnord.nix`, the absolute path
|
||||
is `/foo/xyzzy/fnord.nix`.
|
||||
|
||||
If the first component of a path is a `~`, it is interpreted as if
|
||||
the rest of the path were relative to the user's home directory.
|
||||
e.g. `~/foo` would be equivalent to `/home/edolstra/foo` for a user
|
||||
whose home directory is `/home/edolstra`.
|
||||
|
||||
Paths can also be specified between angle brackets, e.g.
|
||||
`<nixpkgs>`. This means that the directories listed in the
|
||||
environment variable `NIX_PATH` will be searched for the given file
|
||||
or directory name.
|
||||
|
||||
When an [interpolated string][string interpolation] evaluates to a path, the path is first copied into the Nix store and the resulting string is the [store path] of the newly created [store object].
|
||||
|
||||
[store path]: ../glossary.md#gloss-store-path
|
||||
[store object]: ../glossary.md#gloss-store-object
|
||||
|
||||
For instance, evaluating `"${./foo.txt}"` will cause `foo.txt` in the current directory to be copied into the Nix store and result in the string `"/nix/store/<hash>-foo.txt"`.
|
||||
|
||||
Note that the Nix language assumes that all input files will remain _unchanged_ while evaluating a Nix expression.
|
||||
For example, assume you used a file path in an interpolated string during a `nix repl` session.
|
||||
Later in the same session, after having changed the file contents, evaluating the interpolated string with the file path again might not return a new store path, since Nix might not re-read the file contents.
|
||||
|
||||
Paths themselves, except those in angle brackets (`< >`), support [string interpolation].
|
||||
|
||||
At least one slash (`/`) must appear *before* any interpolated expression for the result to be recognized as a path.
|
||||
|
||||
`a.${foo}/b.${bar}` is a syntactically valid division operation.
|
||||
`./a.${foo}/b.${bar}` is a path.
|
||||
|
||||
- <a id="type-boolean" href="#type-boolean">Boolean</a>
|
||||
|
||||
*Booleans* with values `true` and `false`.
|
||||
|
||||
- <a id="type-null" href="#type-null">Null</a>
|
||||
|
||||
The null value, denoted as `null`.
|
||||
|
||||
## List
|
||||
|
||||
Lists are formed by enclosing a whitespace-separated list of values
|
||||
between square brackets. For example,
|
||||
|
||||
```nix
|
||||
[ 123 ./foo.nix "abc" (f { x = y; }) ]
|
||||
```
|
||||
|
||||
defines a list of four elements, the last being the result of a call to
|
||||
the function `f`. Note that function calls have to be enclosed in
|
||||
parentheses. If they had been omitted, e.g.,
|
||||
|
||||
```nix
|
||||
[ 123 ./foo.nix "abc" f { x = y; } ]
|
||||
```
|
||||
|
||||
the result would be a list of five elements, the fourth one being a
|
||||
function and the fifth being a set.
|
||||
|
||||
Note that lists are only lazy in values, and they are strict in length.
|
||||
|
||||
## Attribute Set
|
||||
|
||||
An attribute set is a collection of name-value-pairs (called *attributes*) enclosed in curly brackets (`{ }`).
|
||||
|
||||
Names and values are separated by an equal sign (`=`).
|
||||
Each value is an arbitrary expression terminated by a semicolon (`;`).
|
||||
|
||||
Attributes can appear in any order.
|
||||
An attribute name may only occur once.
|
||||
|
||||
Example:
|
||||
|
||||
```nix
|
||||
{
|
||||
x = 123;
|
||||
text = "Hello";
|
||||
y = f { bla = 456; };
|
||||
}
|
||||
```
|
||||
|
||||
This defines a set with attributes named `x`, `text`, `y`.
|
||||
|
||||
Attributes can be selected from a set using the `.` operator. For
|
||||
instance,
|
||||
|
||||
```nix
|
||||
{ a = "Foo"; b = "Bar"; }.a
|
||||
```
|
||||
|
||||
evaluates to `"Foo"`. It is possible to provide a default value in an
|
||||
attribute selection using the `or` keyword. For example,
|
||||
|
||||
```nix
|
||||
{ a = "Foo"; b = "Bar"; }.c or "Xyzzy"
|
||||
```
|
||||
|
||||
will evaluate to `"Xyzzy"` because there is no `c` attribute in the set.
|
||||
|
||||
You can use arbitrary double-quoted strings as attribute names:
|
||||
|
||||
```nix
|
||||
{ "$!@#?" = 123; }."$!@#?"
|
||||
```
|
||||
|
||||
```nix
|
||||
let bar = "bar";
|
||||
{ "foo ${bar}" = 123; }."foo ${bar}"
|
||||
```
|
||||
|
||||
Both will evaluate to `123`.
|
||||
|
||||
Attribute names support [string interpolation]:
|
||||
|
||||
```nix
|
||||
let bar = "foo"; in
|
||||
{ foo = 123; }.${bar}
|
||||
```
|
||||
|
||||
```nix
|
||||
let bar = "foo"; in
|
||||
{ ${bar} = 123; }.foo
|
||||
```
|
||||
|
||||
Both will evaluate to `123`.
|
||||
|
||||
In the special case where an attribute name inside of a set declaration
|
||||
evaluates to `null` (which is normally an error, as `null` cannot be coerced to
|
||||
a string), that attribute is simply not added to the set:
|
||||
|
||||
```nix
|
||||
{ ${if foo then "bar" else null} = true; }
|
||||
```
|
||||
|
||||
This will evaluate to `{}` if `foo` evaluates to `false`.
|
||||
|
||||
A set that has a `__functor` attribute whose value is callable (i.e. is
|
||||
itself a function or a set with a `__functor` attribute whose value is
|
||||
callable) can be applied as if it were a function, with the set itself
|
||||
passed in first , e.g.,
|
||||
|
||||
```nix
|
||||
let add = { __functor = self: x: x + self.x; };
|
||||
inc = add // { x = 1; };
|
||||
in inc 1
|
||||
```
|
||||
|
||||
evaluates to `2`. This can be used to attach metadata to a function
|
||||
without the caller needing to treat it specially, or to implement a form
|
||||
of object-oriented programming, for example.
|
||||
@@ -24,7 +24,7 @@ collection; you could write your own Nix expressions based on Nixpkgs,
|
||||
or completely new ones.)
|
||||
|
||||
You can manually download the latest version of Nixpkgs from
|
||||
<https://github.com/NixOS/nixpkgs>. However, it’s much more
|
||||
<http://nixos.org/nixpkgs/download.html>. However, it’s much more
|
||||
convenient to use the Nixpkgs [*channel*](channels.md), since it makes
|
||||
it easy to stay up to date with new versions of Nixpkgs. Nixpkgs is
|
||||
automatically added to your list of “subscribed” channels when you
|
||||
@@ -40,52 +40,48 @@ $ nix-channel --update
|
||||
>
|
||||
> On NixOS, you’re automatically subscribed to a NixOS channel
|
||||
> corresponding to your NixOS major release (e.g.
|
||||
> <http://nixos.org/channels/nixos-21.11>). A NixOS channel is identical
|
||||
> <http://nixos.org/channels/nixos-14.12>). A NixOS channel is identical
|
||||
> to the Nixpkgs channel, except that it contains only Linux binaries
|
||||
> and is updated only if a set of regression tests succeed.
|
||||
|
||||
You can view the set of available packages in Nixpkgs:
|
||||
|
||||
```console
|
||||
$ nix-env -qaP
|
||||
nixpkgs.aterm aterm-2.2
|
||||
nixpkgs.bash bash-3.0
|
||||
nixpkgs.binutils binutils-2.15
|
||||
nixpkgs.bison bison-1.875d
|
||||
nixpkgs.blackdown blackdown-1.4.2
|
||||
nixpkgs.bzip2 bzip2-1.0.2
|
||||
$ nix-env -qa
|
||||
aterm-2.2
|
||||
bash-3.0
|
||||
binutils-2.15
|
||||
bison-1.875d
|
||||
blackdown-1.4.2
|
||||
bzip2-1.0.2
|
||||
…
|
||||
```
|
||||
|
||||
The flag `-q` specifies a query operation, `-a` means that you want
|
||||
The flag `-q` specifies a query operation, and `-a` means that you want
|
||||
to show the “available” (i.e., installable) packages, as opposed to the
|
||||
installed packages, and `-P` prints the attribute paths that can be used
|
||||
to unambiguously select a package for installation (listed in the first column).
|
||||
If you downloaded Nixpkgs yourself, or if you checked it out from GitHub,
|
||||
then you need to pass the path to your Nixpkgs tree using the `-f` flag:
|
||||
installed packages. If you downloaded Nixpkgs yourself, or if you
|
||||
checked it out from GitHub, then you need to pass the path to your
|
||||
Nixpkgs tree using the `-f` flag:
|
||||
|
||||
```console
|
||||
$ nix-env -qaPf /path/to/nixpkgs
|
||||
aterm aterm-2.2
|
||||
bash bash-3.0
|
||||
…
|
||||
$ nix-env -qaf /path/to/nixpkgs
|
||||
```
|
||||
|
||||
where */path/to/nixpkgs* is where you’ve unpacked or checked out
|
||||
Nixpkgs.
|
||||
|
||||
You can filter the packages by name:
|
||||
You can select specific packages by name:
|
||||
|
||||
```console
|
||||
$ nix-env -qaP firefox
|
||||
nixpkgs.firefox-esr firefox-91.3.0esr
|
||||
nixpkgs.firefox firefox-94.0.1
|
||||
$ nix-env -qa firefox
|
||||
firefox-34.0.5
|
||||
firefox-with-plugins-34.0.5
|
||||
```
|
||||
|
||||
and using regular expressions:
|
||||
|
||||
```console
|
||||
$ nix-env -qaP 'firefox.*'
|
||||
$ nix-env -qa 'firefox.*'
|
||||
```
|
||||
|
||||
It is also possible to see the *status* of available packages, i.e.,
|
||||
@@ -93,11 +89,11 @@ whether they are installed into the user environment and/or present in
|
||||
the system:
|
||||
|
||||
```console
|
||||
$ nix-env -qaPs
|
||||
$ nix-env -qas
|
||||
…
|
||||
-PS nixpkgs.bash bash-3.0
|
||||
--S nixpkgs.binutils binutils-2.15
|
||||
IPS nixpkgs.bison bison-1.875d
|
||||
-PS bash-3.0
|
||||
--S binutils-2.15
|
||||
IPS bison-1.875d
|
||||
…
|
||||
```
|
||||
|
||||
@@ -110,13 +106,13 @@ which is Nix’s mechanism for doing binary deployment. It just means that
|
||||
Nix knows that it can fetch a pre-built package from somewhere
|
||||
(typically a network server) instead of building it locally.
|
||||
|
||||
You can install a package using `nix-env -iA`. For instance,
|
||||
You can install a package using `nix-env -i`. For instance,
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.subversion
|
||||
$ nix-env -i subversion
|
||||
```
|
||||
|
||||
will install the package called `subversion` from `nixpkgs` channel (which is, of course, the
|
||||
will install the package called `subversion` (which is, of course, the
|
||||
[Subversion version management system](http://subversion.tigris.org/)).
|
||||
|
||||
> **Note**
|
||||
@@ -126,7 +122,7 @@ will install the package called `subversion` from `nixpkgs` channel (which is, o
|
||||
> binary cache <https://cache.nixos.org>; it contains binaries for most
|
||||
> packages in Nixpkgs. Only if no binary is available in the binary
|
||||
> cache, Nix will build the package from source. So if `nix-env
|
||||
> -iA nixpkgs.subversion` results in Nix building stuff from source, then either
|
||||
> -i subversion` results in Nix building stuff from source, then either
|
||||
> the package is not built for your platform by the Nixpkgs build
|
||||
> servers, or your version of Nixpkgs is too old or too new. For
|
||||
> instance, if you have a very recent checkout of Nixpkgs, then the
|
||||
@@ -137,10 +133,7 @@ will install the package called `subversion` from `nixpkgs` channel (which is, o
|
||||
> using a Git checkout of the Nixpkgs tree), you will get binaries for
|
||||
> most packages.
|
||||
|
||||
Naturally, packages can also be uninstalled. Unlike when installing, you will
|
||||
need to use the derivation name (though the version part can be omitted),
|
||||
instead of the attribute path, as `nix-env` does not record which attribute
|
||||
was used for installing:
|
||||
Naturally, packages can also be uninstalled:
|
||||
|
||||
```console
|
||||
$ nix-env -e subversion
|
||||
@@ -150,7 +143,7 @@ Upgrading to a new version is just as easy. If you have a new release of
|
||||
Nix Packages, you can do:
|
||||
|
||||
```console
|
||||
$ nix-env -uA nixpkgs.subversion
|
||||
$ nix-env -u subversion
|
||||
```
|
||||
|
||||
This will *only* upgrade Subversion if there is a “newer” version in the
|
||||
|
||||
@@ -9,7 +9,7 @@ The daemon that handles binary cache requests via HTTP, `nix-serve`, is
|
||||
not part of the Nix distribution, but you can install it from Nixpkgs:
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.nix-serve
|
||||
$ nix-env -i nix-serve
|
||||
```
|
||||
|
||||
You can then start the server, listening for HTTP connections on
|
||||
@@ -35,7 +35,7 @@ On the client side, you can tell Nix to use your binary cache using
|
||||
`--option extra-binary-caches`, e.g.:
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.firefox --option extra-binary-caches http://avalon:8080/
|
||||
$ nix-env -i firefox --option extra-binary-caches http://avalon:8080/
|
||||
```
|
||||
|
||||
The option `extra-binary-caches` tells Nix to use this binary cache in
|
||||
|
||||
@@ -44,7 +44,7 @@ collector as follows:
|
||||
$ nix-store --gc
|
||||
```
|
||||
|
||||
The behaviour of the garbage collector is affected by the
|
||||
The behaviour of the gargage collector is affected by the
|
||||
`keep-derivations` (default: true) and `keep-outputs` (default: false)
|
||||
options in the Nix configuration file. The defaults will ensure that all
|
||||
derivations that are build-time dependencies of garbage collector roots
|
||||
|
||||
@@ -1,4 +1,5 @@
|
||||
This chapter discusses how to do package management with Nix, i.e.,
|
||||
how to obtain, install, upgrade, and erase packages. This is the
|
||||
“user’s” perspective of the Nix system — people who want to *create*
|
||||
packages should consult the chapter on the [Nix language](../language/index.md).
|
||||
packages should consult the [chapter on writing Nix
|
||||
expressions](../expressions/writing-nix-expressions.md).
|
||||
|
||||
@@ -39,7 +39,7 @@ just Subversion 1.1.2 (arrows in the figure indicate symlinks). This
|
||||
would be what we would obtain if we had done
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.subversion
|
||||
$ nix-env -i subversion
|
||||
```
|
||||
|
||||
on a set of Nix expressions that contained Subversion 1.1.2.
|
||||
@@ -54,7 +54,7 @@ environment is generated based on the current one. For instance,
|
||||
generation 43 was created from generation 42 when we did
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.subversion nixpkgs.firefox
|
||||
$ nix-env -i subversion firefox
|
||||
```
|
||||
|
||||
on a set of Nix expressions that contained Firefox and a new version of
|
||||
@@ -127,7 +127,7 @@ All `nix-env` operations work on the profile pointed to by
|
||||
(abbreviation `-p`):
|
||||
|
||||
```console
|
||||
$ nix-env -p /nix/var/nix/profiles/other-profile -iA nixpkgs.subversion
|
||||
$ nix-env -p /nix/var/nix/profiles/other-profile -i subversion
|
||||
```
|
||||
|
||||
This will *not* change the `~/.nix-profile` symlink.
|
||||
|
||||
@@ -7,17 +7,17 @@ cache mechanism that Nix usually uses to fetch prebuilt binaries from
|
||||
|
||||
The following options can be specified as URL parameters to the S3 URL:
|
||||
|
||||
- `profile`\
|
||||
- `profile`
|
||||
The name of the AWS configuration profile to use. By default Nix
|
||||
will use the `default` profile.
|
||||
|
||||
- `region`\
|
||||
- `region`
|
||||
The region of the S3 bucket. `us–east-1` by default.
|
||||
|
||||
If your bucket is not in `us–east-1`, you should always explicitly
|
||||
specify the region parameter.
|
||||
|
||||
- `endpoint`\
|
||||
- `endpoint`
|
||||
The URL to your S3-compatible service, for when not using Amazon S3.
|
||||
Do not specify this value if you're using Amazon S3.
|
||||
|
||||
@@ -26,7 +26,7 @@ The following options can be specified as URL parameters to the S3 URL:
|
||||
> This endpoint must support HTTPS and will use path-based
|
||||
> addressing instead of virtual host based addressing.
|
||||
|
||||
- `scheme`\
|
||||
- `scheme`
|
||||
The scheme used for S3 requests, `https` (default) or `http`. This
|
||||
option allows you to disable HTTPS for binary caches which don't
|
||||
support it.
|
||||
|
||||
@@ -6,7 +6,7 @@ automatically fetching any store paths in Firefox’s closure if they are
|
||||
available on the server `avalon`:
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.firefox --substituters ssh://alice@avalon
|
||||
$ nix-env -i firefox --substituters ssh://alice@avalon
|
||||
```
|
||||
|
||||
This works similar to the binary cache substituter that Nix usually
|
||||
|
||||
@@ -19,19 +19,19 @@ to subsequent chapters.
|
||||
channel:
|
||||
|
||||
```console
|
||||
$ nix-env -qaP
|
||||
nixpkgs.docbook_xml_dtd_43 docbook-xml-4.3
|
||||
nixpkgs.docbook_xml_dtd_45 docbook-xml-4.5
|
||||
nixpkgs.firefox firefox-33.0.2
|
||||
nixpkgs.hello hello-2.9
|
||||
nixpkgs.libxslt libxslt-1.1.28
|
||||
$ nix-env -qa
|
||||
docbook-xml-4.3
|
||||
docbook-xml-4.5
|
||||
firefox-33.0.2
|
||||
hello-2.9
|
||||
libxslt-1.1.28
|
||||
…
|
||||
```
|
||||
|
||||
1. Install some packages from the channel:
|
||||
|
||||
```console
|
||||
$ nix-env -iA nixpkgs.hello
|
||||
$ nix-env -i hello
|
||||
```
|
||||
|
||||
This should download pre-built packages; it should not build them
|
||||
|
||||
@@ -1,31 +0,0 @@
|
||||
# Release 2.10 (2022-07-11)
|
||||
|
||||
* `nix repl` now takes installables on the command line, unifying the usage
|
||||
with other commands that use `--file` and `--expr`. Primary breaking change
|
||||
is for the common usage of `nix repl '<nixpkgs>'` which can be recovered with
|
||||
`nix repl --file '<nixpkgs>'` or `nix repl --expr 'import <nixpkgs>{}'`.
|
||||
|
||||
This is currently guarded by the `repl-flake` experimental feature.
|
||||
|
||||
* A new function `builtins.traceVerbose` is available. It is similar
|
||||
to `builtins.trace` if the `trace-verbose` setting is set to true,
|
||||
and it is a no-op otherwise.
|
||||
|
||||
* `nix search` has a new flag `--exclude` to filter out packages.
|
||||
|
||||
* On Linux, if `/nix` doesn't exist and cannot be created and you're
|
||||
not running as root, Nix will automatically use
|
||||
`~/.local/share/nix/root` as a chroot store. This enables non-root
|
||||
users to download the statically linked Nix binary and have it work
|
||||
out of the box, e.g.
|
||||
|
||||
```
|
||||
# ~/nix run nixpkgs#hello
|
||||
warning: '/nix' does not exists, so Nix will use '/home/ubuntu/.local/share/nix/root' as a chroot store
|
||||
Hello, world!
|
||||
```
|
||||
|
||||
* `flake-registry.json` is now fetched from `channels.nixos.org`.
|
||||
|
||||
* Nix can now be built with LTO by passing `--enable-lto` to `configure`.
|
||||
LTO is currently only supported when building with GCC.
|
||||
@@ -1,5 +0,0 @@
|
||||
# Release 2.11 (2022-08-24)
|
||||
|
||||
* `nix copy` now copies the store paths in parallel as much as possible (again).
|
||||
This doesn't apply for the `daemon` and `ssh-ng` stores which copy everything
|
||||
in one batch to avoid latencies issues.
|
||||
@@ -1,43 +0,0 @@
|
||||
# Release 2.12 (2022-12-06)
|
||||
|
||||
* On Linux, Nix can now run builds in a user namespace where they run
|
||||
as root (UID 0) and have 65,536 UIDs available.
|
||||
<!-- FIXME: move this to its own section about system features -->
|
||||
This is primarily useful for running containers such as `systemd-nspawn`
|
||||
inside a Nix build. For an example, see [`tests/systemd-nspawn/nix`][nspawn].
|
||||
|
||||
[nspawn]: https://github.com/NixOS/nix/blob/67bcb99700a0da1395fa063d7c6586740b304598/tests/systemd-nspawn.nix.
|
||||
|
||||
A build can enable this by setting the derivation attribute:
|
||||
|
||||
```
|
||||
requiredSystemFeatures = [ "uid-range" ];
|
||||
```
|
||||
|
||||
The `uid-range` [system feature] requires the [`auto-allocate-uids`]
|
||||
setting to be enabled.
|
||||
|
||||
[system feature]: ../command-ref/conf-file.md#conf-system-features
|
||||
|
||||
* Nix can now automatically pick UIDs for builds, removing the need to
|
||||
create `nixbld*` user accounts. See [`auto-allocate-uids`].
|
||||
|
||||
[`auto-allocate-uids`]: ../command-ref/conf-file.md#conf-auto-allocate-uids
|
||||
|
||||
* On Linux, Nix has experimental support for running builds inside a
|
||||
cgroup. See
|
||||
[`use-cgroups`](../command-ref/conf-file.md#conf-use-cgroups).
|
||||
|
||||
* `<nix/fetchurl.nix>` now accepts an additional argument `impure` which
|
||||
defaults to `false`. If it is set to `true`, the `hash` and `sha256`
|
||||
arguments will be ignored and the resulting derivation will have
|
||||
`__impure` set to `true`, making it an impure derivation.
|
||||
|
||||
* If `builtins.readFile` is called on a file with context, then only
|
||||
the parts of the context that appear in the content of the file are
|
||||
retained. This avoids a lot of spurious errors where strings end up
|
||||
having a context just because they are read from a store path
|
||||
([#7260](https://github.com/NixOS/nix/pull/7260)).
|
||||
|
||||
* `nix build --json` now prints some statistics about top-level
|
||||
derivations, such as CPU statistics when cgroups are enabled.
|
||||
@@ -1,40 +0,0 @@
|
||||
# Release 2.13 (2023-01-17)
|
||||
|
||||
* The `repeat` and `enforce-determinism` options have been removed
|
||||
since they had been broken under many circumstances for a long time.
|
||||
|
||||
* You can now use [flake references] in the [old command line interface], e.g.
|
||||
|
||||
[flake references]: ../command-ref/new-cli/nix3-flake.md#flake-references
|
||||
[old command line interface]: ../command-ref/main-commands.md
|
||||
|
||||
```shell-session
|
||||
# nix-build flake:nixpkgs -A hello
|
||||
# nix-build -I nixpkgs=flake:github:NixOS/nixpkgs/nixos-22.05 \
|
||||
'<nixpkgs>' -A hello
|
||||
# NIX_PATH=nixpkgs=flake:nixpkgs nix-build '<nixpkgs>' -A hello
|
||||
```
|
||||
|
||||
* Instead of "antiquotation", the more common term [string interpolation](../language/string-interpolation.md) is now used consistently.
|
||||
Historical release notes were not changed.
|
||||
|
||||
* Allow explicitly selecting outputs in a store derivation installable, just like we can do with other sorts of installables.
|
||||
For example,
|
||||
```shell-session
|
||||
# nix build /nix/store/gzaflydcr6sb3567hap9q6srzx8ggdgg-glibc-2.33-78.drv^dev
|
||||
```
|
||||
now works just as
|
||||
```shell-session
|
||||
# nix build nixpkgs#glibc^dev
|
||||
```
|
||||
does already.
|
||||
|
||||
* On Linux, `nix develop` now sets the
|
||||
[*personality*](https://man7.org/linux/man-pages/man2/personality.2.html)
|
||||
for the development shell in the same way as the actual build of the
|
||||
derivation. This makes shells for `i686-linux` derivations work
|
||||
correctly on `x86_64-linux`.
|
||||
|
||||
* You can now disable the global flake registry by setting the `flake-registry`
|
||||
configuration option to an empty string. The same can be achieved at runtime with
|
||||
`--flake-registry ""`.
|
||||
@@ -1,542 +0,0 @@
|
||||
# Release 2.4 (2021-11-01)
|
||||
|
||||
This is the first release in more than two years and is the result of
|
||||
more than 2800 commits from 195 contributors since release 2.3.
|
||||
|
||||
## Highlights
|
||||
|
||||
* Nix's **error messages** have been improved a lot. For instance,
|
||||
evaluation errors now point out the location of the error:
|
||||
|
||||
```
|
||||
$ nix build
|
||||
error: undefined variable 'bzip3'
|
||||
|
||||
at /nix/store/449lv242z0zsgwv95a8124xi11sp419f-source/flake.nix:88:13:
|
||||
|
||||
87| [ curl
|
||||
88| bzip3 xz brotli editline
|
||||
| ^
|
||||
89| openssl sqlite
|
||||
```
|
||||
|
||||
* The **`nix` command** has seen a lot of work and is now almost at
|
||||
feature parity with the old command-line interface (the `nix-*`
|
||||
commands). It aims to be [more modern, consistent and pleasant to
|
||||
use](../contributing/cli-guideline.md) than the old CLI. It is still
|
||||
marked as experimental but its interface should not change much
|
||||
anymore in future releases.
|
||||
|
||||
* **Flakes** are a new format to package Nix-based projects in a more
|
||||
discoverable, composable, consistent and reproducible way. A flake
|
||||
is just a repository or tarball containing a file named `flake.nix`
|
||||
that specifies dependencies on other flakes and returns any Nix
|
||||
assets such as packages, Nixpkgs overlays, NixOS modules or CI
|
||||
tests. The new `nix` CLI is primarily based around flakes; for
|
||||
example, a command like `nix run nixpkgs#hello` runs the `hello`
|
||||
application from the `nixpkgs` flake.
|
||||
|
||||
Flakes are currently marked as experimental. For an introduction,
|
||||
see [this blog
|
||||
post](https://www.tweag.io/blog/2020-05-25-flakes/). For detailed
|
||||
information about flake syntax and semantics, see the [`nix flake`
|
||||
manual page](../command-ref/new-cli/nix3-flake.md).
|
||||
|
||||
* Nix's store can now be **content-addressed**, meaning that the hash
|
||||
component of a store path is the hash of the path's
|
||||
contents. Previously Nix could only build **input-addressed** store
|
||||
paths, where the hash is computed from the derivation dependency
|
||||
graph. Content-addressing allows deduplication, early cutoff in
|
||||
build systems, and unprivileged closure copying. This is still [an
|
||||
experimental
|
||||
feature](https://discourse.nixos.org/t/content-addressed-nix-call-for-testers/12881).
|
||||
|
||||
* The Nix manual has been converted into Markdown, making it easier to
|
||||
contribute. In addition, every `nix` subcommand now has a manual
|
||||
page, documenting every option.
|
||||
|
||||
* A new setting that allows **experimental features** to be enabled
|
||||
selectively. This allows us to merge unstable features into Nix more
|
||||
quickly and do more frequent releases.
|
||||
|
||||
## Other features
|
||||
|
||||
* There are many new `nix` subcommands:
|
||||
|
||||
- `nix develop` is intended to replace `nix-shell`. It has a number
|
||||
of new features:
|
||||
|
||||
* It automatically sets the output environment variables (such as
|
||||
`$out`) to writable locations (such as `./outputs/out`).
|
||||
|
||||
* It can store the environment in a profile. This is useful for
|
||||
offline work.
|
||||
|
||||
* It can run specific phases directly. For instance, `nix develop
|
||||
--build` runs `buildPhase`.
|
||||
|
||||
- It allows dependencies in the Nix store to be "redirected" to
|
||||
arbitrary directories using the `--redirect` flag. This is
|
||||
useful if you want to hack on a package *and* some of its
|
||||
dependencies at the same time.
|
||||
|
||||
- `nix print-dev-env` prints the environment variables and bash
|
||||
functions defined by a derivation. This is useful for users of
|
||||
other shells than bash (especially with `--json`).
|
||||
|
||||
- `nix shell` was previously named `nix run` and is intended to
|
||||
replace `nix-shell -p`, but without the `stdenv` overhead. It
|
||||
simply starts a shell where some packages have been added to
|
||||
`$PATH`.
|
||||
|
||||
- `nix run` (not to be confused with the old subcommand that has
|
||||
been renamed to `nix shell`) runs an "app", a flake output that
|
||||
specifies a command to run, or an eponymous program from a
|
||||
package. For example, `nix run nixpkgs#hello` runs the `hello`
|
||||
program from the `hello` package in `nixpkgs`.
|
||||
|
||||
- `nix flake` is the container for flake-related operations, such as
|
||||
creating a new flake, querying the contents of a flake or updating
|
||||
flake lock files.
|
||||
|
||||
- `nix registry` allows you to query and update the flake registry,
|
||||
which maps identifiers such as `nixpkgs` to concrete flake URLs.
|
||||
|
||||
- `nix profile` is intended to replace `nix-env`. Its main advantage
|
||||
is that it keeps track of the provenance of installed packages
|
||||
(e.g. exactly which flake version a package came from). It also
|
||||
has some helpful subcommands:
|
||||
|
||||
* `nix profile history` shows what packages were added, upgraded
|
||||
or removed between each version of a profile.
|
||||
|
||||
* `nix profile diff-closures` shows the changes between the
|
||||
closures of each version of a profile. This allows you to
|
||||
discover the addition or removal of dependencies or size
|
||||
changes.
|
||||
|
||||
**Warning**: after a profile has been updated using `nix profile`,
|
||||
it is no longer usable with `nix-env`.
|
||||
|
||||
- `nix store diff-closures` shows the differences between the
|
||||
closures of two store paths in terms of the versions and sizes of
|
||||
dependencies in the closures.
|
||||
|
||||
- `nix store make-content-addressable` rewrites an arbitrary closure
|
||||
to make it content-addressed. Such paths can be copied into other
|
||||
stores without requiring signatures.
|
||||
|
||||
- `nix bundle` uses the [`nix-bundle`
|
||||
program](https://github.com/matthewbauer/nix-bundle) to convert a
|
||||
closure into a self-extracting executable.
|
||||
|
||||
- Various other replacements for the old CLI, e.g. `nix store gc`,
|
||||
`nix store delete`, `nix store repair`, `nix nar dump-path`, `nix
|
||||
store prefetch-file`, `nix store prefetch-tarball`, `nix key` and
|
||||
`nix daemon`.
|
||||
|
||||
* Nix now has an **evaluation cache** for flake outputs. For example,
|
||||
a second invocation of the command `nix run nixpkgs#firefox` will
|
||||
not need to evaluate the `firefox` attribute because it's already in
|
||||
the evaluation cache. This is made possible by the hermetic
|
||||
evaluation model of flakes.
|
||||
|
||||
* The new `--offline` flag disables substituters and causes all
|
||||
locally cached tarballs and repositories to be considered
|
||||
up-to-date.
|
||||
|
||||
* The new `--refresh` flag causes all locally cached tarballs and
|
||||
repositories to be considered out-of-date.
|
||||
|
||||
* Many `nix` subcommands now have a `--json` option to produce
|
||||
machine-readable output.
|
||||
|
||||
* `nix repl` has a new `:doc` command to show documentation about
|
||||
builtin functions (e.g. `:doc builtins.map`).
|
||||
|
||||
* Binary cache stores now have an option `index-debug-info` to create
|
||||
an index of DWARF debuginfo files for use by
|
||||
[`dwarffs`](https://github.com/edolstra/dwarffs).
|
||||
|
||||
* To support flakes, Nix now has an extensible mechanism for fetching
|
||||
source trees. Currently it has the following backends:
|
||||
|
||||
* Git repositories
|
||||
|
||||
* Mercurial repositories
|
||||
|
||||
* GitHub and GitLab repositories (an optimisation for faster
|
||||
fetching than Git)
|
||||
|
||||
* Tarballs
|
||||
|
||||
* Arbitrary directories
|
||||
|
||||
The fetcher infrastructure is exposed via flake input specifications
|
||||
and via the `fetchTree` built-in.
|
||||
|
||||
* **Languages changes**: the only new language feature is that you can
|
||||
now have antiquotations in paths, e.g. `./${foo}` instead of `./. +
|
||||
foo`.
|
||||
|
||||
* **New built-in functions**:
|
||||
|
||||
- `builtins.fetchTree` allows fetching a source tree using any
|
||||
backends supported by the fetcher infrastructure. It subsumes the
|
||||
functionality of existing built-ins like `fetchGit`,
|
||||
`fetchMercurial` and `fetchTarball`.
|
||||
|
||||
- `builtins.getFlake` fetches a flake and returns its output
|
||||
attributes. This function should not be used inside flakes! Use
|
||||
flake inputs instead.
|
||||
|
||||
- `builtins.floor` and `builtins.ceil` round a floating-point number
|
||||
down and up, respectively.
|
||||
|
||||
* Experimental support for recursive Nix. This means that Nix
|
||||
derivations can now call Nix to build other derivations. This is not
|
||||
in a stable state yet and not well
|
||||
[documented](https://github.com/NixOS/nix/commit/c4d7c76b641d82b2696fef73ce0ac160043c18da).
|
||||
|
||||
* The new experimental feature `no-url-literals` disables URL
|
||||
literals. This helps to implement [RFC
|
||||
45](https://github.com/NixOS/rfcs/pull/45).
|
||||
|
||||
* Nix now uses `libarchive` to decompress and unpack tarballs and zip
|
||||
files, so `tar` is no longer required.
|
||||
|
||||
* The priority of substituters can now be overridden using the
|
||||
`priority` substituter setting (e.g. `--substituters
|
||||
'http://cache.nixos.org?priority=100 daemon?priority=10'`).
|
||||
|
||||
* `nix edit` now supports non-derivation attributes, e.g. `nix edit
|
||||
.#nixosConfigurations.bla`.
|
||||
|
||||
* The `nix` command now provides command line completion for `bash`,
|
||||
`zsh` and `fish`. Since the support for getting completions is built
|
||||
into `nix`, it's easy to add support for other shells.
|
||||
|
||||
* The new `--log-format` flag selects what Nix's output looks like. It
|
||||
defaults to a terse progress indicator. There is a new
|
||||
`internal-json` output format for use by other programs.
|
||||
|
||||
* `nix eval` has a new `--apply` flag that applies a function to the
|
||||
evaluation result.
|
||||
|
||||
* `nix eval` has a new `--write-to` flag that allows it to write a
|
||||
nested attribute set of string leaves to a corresponding directory
|
||||
tree.
|
||||
|
||||
* Memory improvements: many operations that add paths to the store or
|
||||
copy paths between stores now run in constant memory.
|
||||
|
||||
* Many `nix` commands now support the flag `--derivation` to operate
|
||||
on a `.drv` file itself instead of its outputs.
|
||||
|
||||
* There is a new store called `dummy://` that does not support
|
||||
building or adding paths. This is useful if you want to use the Nix
|
||||
evaluator but don't have a Nix store.
|
||||
|
||||
* The `ssh-ng://` store now allows substituting paths on the remote,
|
||||
as `ssh://` already did.
|
||||
|
||||
* When auto-calling a function with an ellipsis, all arguments are now
|
||||
passed.
|
||||
|
||||
* New `nix-shell` features:
|
||||
|
||||
- It preserves the `PS1` environment variable if
|
||||
`NIX_SHELL_PRESERVE_PROMPT` is set.
|
||||
|
||||
- With `-p`, it passes any `--arg`s as Nixpkgs arguments.
|
||||
|
||||
- Support for structured attributes.
|
||||
|
||||
* `nix-prefetch-url` has a new `--executable` flag.
|
||||
|
||||
* On `x86_64` systems, [`x86_64` microarchitecture
|
||||
levels](https://lwn.net/Articles/844831/) are mapped to additional
|
||||
system types (e.g. `x86_64-v1-linux`).
|
||||
|
||||
* The new `--eval-store` flag allows you to use a different store for
|
||||
evaluation than for building or storing the build result. This is
|
||||
primarily useful when you want to query whether something exists in
|
||||
a read-only store, such as a binary cache:
|
||||
|
||||
```
|
||||
# nix path-info --json --store https://cache.nixos.org \
|
||||
--eval-store auto nixpkgs#hello
|
||||
```
|
||||
|
||||
(Here `auto` indicates the local store.)
|
||||
|
||||
* The Nix daemon has a new low-latency mechanism for copying
|
||||
closures. This is useful when building on remote stores such as
|
||||
`ssh-ng://`.
|
||||
|
||||
* Plugins can now register `nix` subcommands.
|
||||
|
||||
* The `--indirect` flag to `nix-store --add-root` has become a no-op.
|
||||
`--add-root` will always generate indirect GC roots from now on.
|
||||
|
||||
## Incompatible changes
|
||||
|
||||
* The `nix` command is now marked as an experimental feature. This
|
||||
means that you need to add
|
||||
|
||||
```
|
||||
experimental-features = nix-command
|
||||
```
|
||||
|
||||
to your `nix.conf` if you want to use it, or pass
|
||||
`--extra-experimental-features nix-command` on the command line.
|
||||
|
||||
* The `nix` command no longer has a syntax for referring to packages
|
||||
in a channel. This means that the following no longer works:
|
||||
|
||||
```console
|
||||
nix build nixpkgs.hello # Nix 2.3
|
||||
```
|
||||
|
||||
Instead, you can either use the `#` syntax to select a package from
|
||||
a flake, e.g.
|
||||
|
||||
```console
|
||||
nix build nixpkgs#hello
|
||||
```
|
||||
|
||||
Or, if you want to use the `nixpkgs` channel in the `NIX_PATH`
|
||||
environment variable:
|
||||
|
||||
```console
|
||||
nix build -f '<nixpkgs>' hello
|
||||
```
|
||||
|
||||
* The old `nix run` has been renamed to `nix shell`, while there is a
|
||||
new `nix run` that runs a default command. So instead of
|
||||
|
||||
```console
|
||||
nix run nixpkgs.hello -c hello # Nix 2.3
|
||||
```
|
||||
|
||||
you should use
|
||||
|
||||
```console
|
||||
nix shell nixpkgs#hello -c hello
|
||||
```
|
||||
|
||||
or just
|
||||
|
||||
```console
|
||||
nix run nixpkgs#hello
|
||||
```
|
||||
|
||||
if the command you want to run has the same name as the package.
|
||||
|
||||
* It is now an error to modify the `plugin-files` setting via a
|
||||
command-line flag that appears after the first non-flag argument to
|
||||
any command, including a subcommand to `nix`. For example,
|
||||
`nix-instantiate default.nix --plugin-files ""` must now become
|
||||
`nix-instantiate --plugin-files "" default.nix`.
|
||||
|
||||
* We no longer release source tarballs. If you want to build from
|
||||
source, please build from the tags in the Git repository.
|
||||
|
||||
## Contributors
|
||||
|
||||
This release has contributions from
|
||||
Adam Höse,
|
||||
Albert Safin,
|
||||
Alex Kovar,
|
||||
Alex Zero,
|
||||
Alexander Bantyev,
|
||||
Alexandre Esteves,
|
||||
Alyssa Ross,
|
||||
Anatole Lucet,
|
||||
Anders Kaseorg,
|
||||
Andreas Rammhold,
|
||||
Antoine Eiche,
|
||||
Antoine Martin,
|
||||
Arnout Engelen,
|
||||
Arthur Gautier,
|
||||
aszlig,
|
||||
Ben Burdette,
|
||||
Benjamin Hipple,
|
||||
Bernardo Meurer,
|
||||
Björn Gohla,
|
||||
Bjørn Forsman,
|
||||
Bob van der Linden,
|
||||
Brian Leung,
|
||||
Brian McKenna,
|
||||
Brian Wignall,
|
||||
Bruce Toll,
|
||||
Bryan Richter,
|
||||
Calle Rosenquist,
|
||||
Calvin Loncaric,
|
||||
Carlo Nucera,
|
||||
Carlos D'Agostino,
|
||||
Chaz Schlarp,
|
||||
Christian Höppner,
|
||||
Christian Kampka,
|
||||
Chua Hou,
|
||||
Chuck,
|
||||
Cole Helbling,
|
||||
Daiderd Jordan,
|
||||
Dan Callahan,
|
||||
Dani,
|
||||
Daniel Fitzpatrick,
|
||||
Danila Fedorin,
|
||||
Daniël de Kok,
|
||||
Danny Bautista,
|
||||
DavHau,
|
||||
David McFarland,
|
||||
Dima,
|
||||
Domen Kožar,
|
||||
Dominik Schrempf,
|
||||
Dominique Martinet,
|
||||
dramforever,
|
||||
Dustin DeWeese,
|
||||
edef,
|
||||
Eelco Dolstra,
|
||||
Ellie Hermaszewska,
|
||||
Emilio Karakey,
|
||||
Emily,
|
||||
Eric Culp,
|
||||
Ersin Akinci,
|
||||
Fabian Möller,
|
||||
Farid Zakaria,
|
||||
Federico Pellegrin,
|
||||
Finn Behrens,
|
||||
Florian Franzen,
|
||||
Félix Baylac-Jacqué,
|
||||
Gabriella Gonzalez,
|
||||
Geoff Reedy,
|
||||
Georges Dubus,
|
||||
Graham Christensen,
|
||||
Greg Hale,
|
||||
Greg Price,
|
||||
Gregor Kleen,
|
||||
Gregory Hale,
|
||||
Griffin Smith,
|
||||
Guillaume Bouchard,
|
||||
Harald van Dijk,
|
||||
illustris,
|
||||
Ivan Zvonimir Horvat,
|
||||
Jade,
|
||||
Jake Waksbaum,
|
||||
jakobrs,
|
||||
James Ottaway,
|
||||
Jan Tojnar,
|
||||
Janne Heß,
|
||||
Jaroslavas Pocepko,
|
||||
Jarrett Keifer,
|
||||
Jeremy Schlatter,
|
||||
Joachim Breitner,
|
||||
Joe Pea,
|
||||
John Ericson,
|
||||
Jonathan Ringer,
|
||||
Josef Kemetmüller,
|
||||
Joseph Lucas,
|
||||
Jude Taylor,
|
||||
Julian Stecklina,
|
||||
Julien Tanguy,
|
||||
Jörg Thalheim,
|
||||
Kai Wohlfahrt,
|
||||
keke,
|
||||
Keshav Kini,
|
||||
Kevin Quick,
|
||||
Kevin Stock,
|
||||
Kjetil Orbekk,
|
||||
Krzysztof Gogolewski,
|
||||
kvtb,
|
||||
Lars Mühmel,
|
||||
Leonhard Markert,
|
||||
Lily Ballard,
|
||||
Linus Heckemann,
|
||||
Lorenzo Manacorda,
|
||||
Lucas Desgouilles,
|
||||
Lucas Franceschino,
|
||||
Lucas Hoffmann,
|
||||
Luke Granger-Brown,
|
||||
Madeline Haraj,
|
||||
Marwan Aljubeh,
|
||||
Mat Marini,
|
||||
Mateusz Piotrowski,
|
||||
Matthew Bauer,
|
||||
Matthew Kenigsberg,
|
||||
Mauricio Scheffer,
|
||||
Maximilian Bosch,
|
||||
Michael Adler,
|
||||
Michael Bishop,
|
||||
Michael Fellinger,
|
||||
Michael Forney,
|
||||
Michael Reilly,
|
||||
mlatus,
|
||||
Mykola Orliuk,
|
||||
Nathan van Doorn,
|
||||
Naïm Favier,
|
||||
ng0,
|
||||
Nick Van den Broeck,
|
||||
Nicolas Stig124 Formichella,
|
||||
Niels Egberts,
|
||||
Niklas Hambüchen,
|
||||
Nikola Knezevic,
|
||||
oxalica,
|
||||
p01arst0rm,
|
||||
Pamplemousse,
|
||||
Patrick Hilhorst,
|
||||
Paul Opiyo,
|
||||
Pavol Rusnak,
|
||||
Peter Kolloch,
|
||||
Philipp Bartsch,
|
||||
Philipp Middendorf,
|
||||
Piotr Szubiakowski,
|
||||
Profpatsch,
|
||||
Puck Meerburg,
|
||||
Ricardo M. Correia,
|
||||
Rickard Nilsson,
|
||||
Robert Hensing,
|
||||
Robin Gloster,
|
||||
Rodrigo,
|
||||
Rok Garbas,
|
||||
Ronnie Ebrin,
|
||||
Rovanion Luckey,
|
||||
Ryan Burns,
|
||||
Ryan Mulligan,
|
||||
Ryne Everett,
|
||||
Sam Doshi,
|
||||
Sam Lidder,
|
||||
Samir Talwar,
|
||||
Samuel Dionne-Riel,
|
||||
Sebastian Ullrich,
|
||||
Sergei Trofimovich,
|
||||
Sevan Janiyan,
|
||||
Shao Cheng,
|
||||
Shea Levy,
|
||||
Silvan Mosberger,
|
||||
Stefan Frijters,
|
||||
Stefan Jaax,
|
||||
sternenseemann,
|
||||
Steven Shaw,
|
||||
Stéphan Kochen,
|
||||
SuperSandro2000,
|
||||
Suraj Barkale,
|
||||
Taeer Bar-Yam,
|
||||
Thomas Churchman,
|
||||
Théophane Hufschmitt,
|
||||
Timothy DeHerrera,
|
||||
Timothy Klim,
|
||||
Tobias Möst,
|
||||
Tobias Pflug,
|
||||
Tom Bereknyei,
|
||||
Travis A. Everett,
|
||||
Ujjwal Jain,
|
||||
Vladimír Čunát,
|
||||
Wil Taylor,
|
||||
Will Dietz,
|
||||
Yaroslav Bolyukin,
|
||||
Yestin L. Harrison,
|
||||
YI,
|
||||
Yorick van Pelt,
|
||||
Yuriy Taraday and
|
||||
zimbatm.
|
||||
@@ -1,16 +0,0 @@
|
||||
# Release 2.5 (2021-12-13)
|
||||
|
||||
* The garbage collector no longer blocks new builds, so the message
|
||||
`waiting for the big garbage collector lock...` is a thing of the
|
||||
past.
|
||||
|
||||
* Binary cache stores now have a setting `compression-level`.
|
||||
|
||||
* `nix develop` now has a flag `--unpack` to run `unpackPhase`.
|
||||
|
||||
* Lists can now be compared lexicographically using the `<` operator.
|
||||
|
||||
* New built-in function: `builtins.groupBy`, with the same functionality as
|
||||
Nixpkgs' `lib.groupBy`, but faster.
|
||||
|
||||
* `nix repl` now has a `:log` command.
|
||||
@@ -1,21 +0,0 @@
|
||||
# Release 2.6 (2022-01-24)
|
||||
|
||||
* The Nix CLI now searches for a `flake.nix` up until the root of the current
|
||||
Git repository or a filesystem boundary rather than just in the current
|
||||
directory.
|
||||
* The TOML parser used by `builtins.fromTOML` has been replaced by [a
|
||||
more compliant one](https://github.com/ToruNiina/toml11).
|
||||
* Added `:st`/`:show-trace` commands to `nix repl`, which are used to
|
||||
set or toggle display of error traces.
|
||||
* New builtin function `builtins.zipAttrsWith` with the same
|
||||
functionality as `lib.zipAttrsWith` from Nixpkgs, but much more
|
||||
efficient.
|
||||
* New command `nix store copy-log` to copy build logs from one store
|
||||
to another.
|
||||
* The `commit-lockfile-summary` option can be set to a non-empty
|
||||
string to override the commit summary used when commiting an updated
|
||||
lockfile. This may be used in conjunction with the `nixConfig`
|
||||
attribute in `flake.nix` to better conform to repository
|
||||
conventions.
|
||||
* `docker run -ti nixos/nix:master` will place you in the Docker
|
||||
container with the latest version of Nix from the `master` branch.
|
||||
@@ -1,33 +0,0 @@
|
||||
# Release 2.7 (2022-03-07)
|
||||
|
||||
* Nix will now make some helpful suggestions when you mistype
|
||||
something on the command line. For instance, if you type `nix build
|
||||
nixpkgs#thunderbrd`, it will suggest `thunderbird`.
|
||||
|
||||
* A number of "default" flake output attributes have been
|
||||
renamed. These are:
|
||||
|
||||
* `defaultPackage.<system>` → `packages.<system>.default`
|
||||
* `defaultApps.<system>` → `apps.<system>.default`
|
||||
* `defaultTemplate` → `templates.default`
|
||||
* `defaultBundler.<system>` → `bundlers.<system>.default`
|
||||
* `overlay` → `overlays.default`
|
||||
* `devShell.<system>` → `devShells.<system>.default`
|
||||
|
||||
The old flake output attributes still work, but `nix flake check`
|
||||
will warn about them.
|
||||
|
||||
* Breaking API change: `nix bundle` now supports bundlers of the form
|
||||
`bundler.<system>.<name>= derivation: another-derivation;`. This
|
||||
supports additional functionality to inspect evaluation information
|
||||
during bundling. A new
|
||||
[repository](https://github.com/NixOS/bundlers) has various bundlers
|
||||
implemented.
|
||||
|
||||
* `nix store ping` now reports the version of the remote Nix daemon.
|
||||
|
||||
* `nix flake {init,new}` now display information about which files have been
|
||||
created.
|
||||
|
||||
* Templates can now define a `welcomeText` attribute, which is printed out by
|
||||
`nix flake {init,new} --template <template>`.
|
||||
@@ -1,53 +0,0 @@
|
||||
# Release 2.8 (2022-04-19)
|
||||
|
||||
* New experimental command: `nix fmt`, which applies a formatter
|
||||
defined by the `formatter.<system>` flake output to the Nix
|
||||
expressions in a flake.
|
||||
|
||||
* Various Nix commands can now read expressions from standard input
|
||||
using `--file -`.
|
||||
|
||||
* New experimental builtin function `builtins.fetchClosure` that
|
||||
copies a closure from a binary cache at evaluation time and rewrites
|
||||
it to content-addressed form (if it isn't already). Like
|
||||
`builtins.storePath`, this allows importing pre-built store paths;
|
||||
the difference is that it doesn't require the user to configure
|
||||
binary caches and trusted public keys.
|
||||
|
||||
This function is only available if you enable the experimental
|
||||
feature `fetch-closure`.
|
||||
|
||||
* New experimental feature: *impure derivations*. These are
|
||||
derivations that can produce a different result every time they're
|
||||
built. Here is an example:
|
||||
|
||||
```nix
|
||||
stdenv.mkDerivation {
|
||||
name = "impure";
|
||||
__impure = true; # marks this derivation as impure
|
||||
buildCommand = "date > $out";
|
||||
}
|
||||
```
|
||||
|
||||
Running `nix build` twice on this expression will build the
|
||||
derivation twice, producing two different content-addressed store
|
||||
paths. Like fixed-output derivations, impure derivations have access
|
||||
to the network. Only fixed-output derivations and impure derivations
|
||||
can depend on an impure derivation.
|
||||
|
||||
* `nix store make-content-addressable` has been renamed to `nix store
|
||||
make-content-addressed`.
|
||||
|
||||
* The `nixosModule` flake output attribute has been renamed consistent
|
||||
with the `.default` renames in Nix 2.7.
|
||||
|
||||
* `nixosModule` → `nixosModules.default`
|
||||
|
||||
As before, the old output will continue to work, but `nix flake check` will
|
||||
issue a warning about it.
|
||||
|
||||
* `nix run` is now stricter in what it accepts: members of the `apps`
|
||||
flake output are now required to be apps (as defined in [the
|
||||
manual](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-run.html#apps)),
|
||||
and members of `packages` or `legacyPackages` must be derivations
|
||||
(not apps).
|
||||
@@ -1,47 +0,0 @@
|
||||
# Release 2.9 (2022-05-30)
|
||||
|
||||
* Running Nix with the new `--debugger` flag will cause it to start a
|
||||
repl session if an exception is thrown during evaluation, or if
|
||||
`builtins.break` is called. From there you can inspect the values
|
||||
of variables and evaluate Nix expressions. In debug mode, the
|
||||
following new repl commands are available:
|
||||
|
||||
```
|
||||
:env Show env stack
|
||||
:bt Show trace stack
|
||||
:st Show current trace
|
||||
:st <idx> Change to another trace in the stack
|
||||
:c Go until end of program, exception, or builtins.break().
|
||||
:s Go one step
|
||||
```
|
||||
|
||||
Read more about the debugger
|
||||
[here](https://www.zknotes.com/note/5970).
|
||||
|
||||
* Nix now provides better integration with zsh's `run-help`
|
||||
feature. It is now included in the Nix installation in the form of
|
||||
an autoloadable shell function, `run-help-nix`. It picks up Nix
|
||||
subcommands from the currently typed in command and directs the user
|
||||
to the associated man pages.
|
||||
|
||||
* `nix repl` has a new build-and-link (`:bl`) command that builds a
|
||||
derivation while creating GC root symlinks.
|
||||
|
||||
* The path produced by `builtins.toFile` is now allowed to be imported
|
||||
or read even with restricted evaluation. Note that this will not
|
||||
work with a read-only store.
|
||||
|
||||
* `nix build` has a new `--print-out-paths` flag to print the
|
||||
resulting output paths. This matches the default behaviour of
|
||||
`nix-build`.
|
||||
|
||||
* You can now specify which outputs of a derivation `nix` should
|
||||
operate on using the syntax `installable^outputs`,
|
||||
e.g. `nixpkgs#glibc^dev,static` or `nixpkgs#glibc^*`. By default,
|
||||
`nix` will use the outputs specified by the derivation's
|
||||
`meta.outputsToInstall` attribute if it exists, or all outputs
|
||||
otherwise.
|
||||
|
||||
* `builtins.fetchTree` (and flake inputs) can now be used to fetch
|
||||
plain files over the `http(s)` and `file` protocols in addition to
|
||||
directory tarballs.
|
||||
@@ -1,2 +0,0 @@
|
||||
# Release X.Y (202?-??-??)
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user