mirror of
https://github.com/NixOS/nixpkgs.git
synced 2026-10-02 13:00:23 +00:00
Merge branch 'master' into update/crystal
This commit is contained in:
1
.gitattributes
vendored
1
.gitattributes
vendored
@@ -1,4 +1,5 @@
|
||||
**/deps.nix linguist-generated
|
||||
**/deps.json linguist-generated
|
||||
**/node-packages.nix linguist-generated
|
||||
|
||||
pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated
|
||||
|
||||
29
.github/CODEOWNERS
vendored
29
.github/CODEOWNERS
vendored
@@ -49,11 +49,16 @@
|
||||
/pkgs/build-support/writers @lassulus @Profpatsch
|
||||
|
||||
# Nixpkgs documentation
|
||||
/doc @fricklerhandwerk
|
||||
/maintainers/scripts/db-to-md.sh @jtojnar @ryantm
|
||||
/maintainers/scripts/doc @jtojnar @ryantm
|
||||
|
||||
/doc/* @fricklerhandwerk
|
||||
/doc/build-aux/pandoc-filters @jtojnar
|
||||
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar
|
||||
/doc/builders/trivial-builders.chapter.md @fricklerhandwerk
|
||||
/doc/contributing/ @fricklerhandwerk
|
||||
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @fricklerhandwerk
|
||||
/doc/stdenv @fricklerhandwerk
|
||||
/doc/using @fricklerhandwerk
|
||||
|
||||
# NixOS Internals
|
||||
/nixos/default.nix @nbp @infinisil
|
||||
@@ -73,6 +78,8 @@
|
||||
/nixos/doc/manual/man-nixos-option.xml @nbp
|
||||
/nixos/modules/installer/tools/nixos-option.sh @nbp
|
||||
/nixos/modules/system @dasJ
|
||||
/nixos/modules/system/activation/bootspec.nix @grahamc @cole-h @raitobezarius
|
||||
/nixos/modules/system/activation/bootspec.cue @grahamc @cole-h @raitobezarius
|
||||
|
||||
# NixOS integration test driver
|
||||
/nixos/lib/test-driver @tfc
|
||||
@@ -141,6 +148,11 @@
|
||||
# Browsers
|
||||
/pkgs/applications/networking/browsers/firefox @mweinelt
|
||||
|
||||
# Certificate Authorities
|
||||
pkgs/data/misc/cacert/ @ajs124 @lukegb @mweinelt
|
||||
pkgs/development/libraries/nss/ @ajs124 @lukegb @mweinelt
|
||||
pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
|
||||
|
||||
# Jetbrains
|
||||
/pkgs/applications/editors/jetbrains @edwtjo
|
||||
|
||||
@@ -187,6 +199,7 @@
|
||||
/nixos/modules/services/networking/babeld.nix @mweinelt
|
||||
/nixos/modules/services/networking/kea.nix @mweinelt
|
||||
/nixos/modules/services/networking/knot.nix @mweinelt
|
||||
/nixos/modules/services/monitoring/prometheus/exporters/kea.nix @mweinelt
|
||||
/nixos/tests/babeld.nix @mweinelt
|
||||
/nixos/tests/kea.nix @mweinelt
|
||||
/nixos/tests/knot.nix @mweinelt
|
||||
@@ -213,10 +226,10 @@
|
||||
/pkgs/top-level/emacs-packages.nix @adisbladis
|
||||
|
||||
# Neovim
|
||||
/pkgs/applications/editors/neovim @jonringer @teto
|
||||
/pkgs/applications/editors/neovim @figsoda @jonringer @teto
|
||||
|
||||
# VimPlugins
|
||||
/pkgs/applications/editors/vim/plugins @jonringer
|
||||
/pkgs/applications/editors/vim/plugins @figsoda @jonringer
|
||||
|
||||
# VsCode Extensions
|
||||
/pkgs/applications/editors/vscode/extensions @jonringer
|
||||
@@ -278,13 +291,15 @@
|
||||
# Matrix
|
||||
/pkgs/servers/heisenbridge @piegamesde
|
||||
/pkgs/servers/matrix-conduit @piegamesde
|
||||
/pkgs/servers/matrix-synapse/matrix-appservice-irc @piegamesde
|
||||
/nixos/modules/services/misc/heisenbridge.nix @piegamesde
|
||||
/nixos/modules/services/misc/matrix-appservice-irc.nix @piegamesde
|
||||
/nixos/modules/services/misc/matrix-conduit.nix @piegamesde
|
||||
/nixos/tests/matrix-appservice-irc.nix @piegamesde
|
||||
/nixos/tests/matrix-conduit.nix @piegamesde
|
||||
|
||||
# Dotnet
|
||||
/pkgs/build-support/dotnet @IvarWithoutBones
|
||||
/pkgs/development/compilers/dotnet @IvarWithoutBones
|
||||
|
||||
# Node.js
|
||||
/pkgs/build-support/node/build-npm-package @winterqt
|
||||
/pkgs/build-support/node/fetch-npm-deps @winterqt
|
||||
/doc/languages-frameworks/javascript.section.md @winterqt
|
||||
|
||||
31
.github/ISSUE_TEMPLATE/unreproducible_package.md
vendored
Normal file
31
.github/ISSUE_TEMPLATE/unreproducible_package.md
vendored
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
name: Unreproducible package
|
||||
about: A package that does not produce a bit-by-bit reproducible result each time it is built
|
||||
title: ''
|
||||
labels: '0.kind: enhancement', '6.topic: reproducible builds'
|
||||
assignees: ''
|
||||
|
||||
---
|
||||
|
||||
Building this package twice does not produce the bit-by-bit identical result each time, making it harder to detect CI breaches. You can read more about this at https://reproducible-builds.org/ .
|
||||
|
||||
Fixing bit-by-bit reproducibility also has additional advantages, such as avoiding hard-to-reproduce bugs, making content-addressed storage more effective and reducing rebuilds in such systems.
|
||||
|
||||
### Steps To Reproduce
|
||||
|
||||
```
|
||||
nix-build '<nixpkgs>' -A ... --check --keep-failed
|
||||
```
|
||||
|
||||
You can use `diffoscope` to analyze the differences in the output of the two builds.
|
||||
|
||||
To view the build log of the build that produced the artifact in the binary cache:
|
||||
|
||||
```
|
||||
nix-store --read-log $(nix-instantiate '<nixpkgs>' -A ...)
|
||||
```
|
||||
|
||||
### Additional context
|
||||
|
||||
(please share the relevant fragment of the diffoscope output here,
|
||||
and any additional analysis you may have done)
|
||||
2
.github/PULL_REQUEST_TEMPLATE.md
vendored
2
.github/PULL_REQUEST_TEMPLATE.md
vendored
@@ -22,7 +22,7 @@ For new packages please briefly describe the package or provide a link to its ho
|
||||
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
|
||||
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
|
||||
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
|
||||
- [22.11 Release Notes (or backporting 22.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2211-release-notes)
|
||||
- [23.05 Release Notes (or backporting 22.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
|
||||
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
|
||||
- [ ] (Module updates) Added a release notes entry if the change is significant
|
||||
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module
|
||||
|
||||
6
.github/dependabot.yml
vendored
Normal file
6
.github/dependabot.yml
vendored
Normal file
@@ -0,0 +1,6 @@
|
||||
version: 2
|
||||
updates:
|
||||
- package-ecosystem: "github-actions"
|
||||
directory: "/"
|
||||
schedule:
|
||||
interval: "weekly"
|
||||
2
.github/workflows/backport.yml
vendored
2
.github/workflows/backport.yml
vendored
@@ -26,7 +26,7 @@ jobs:
|
||||
fetch-depth: 0
|
||||
ref: ${{ github.event.pull_request.head.sha }}
|
||||
- name: Create backport PRs
|
||||
uses: zeebe-io/backport-action@v0.0.8
|
||||
uses: zeebe-io/backport-action@v0.0.9
|
||||
with:
|
||||
# Config README: https://github.com/zeebe-io/backport-action#backport-action
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
4
.github/workflows/basic-eval.yml
vendored
4
.github/workflows/basic-eval.yml
vendored
@@ -19,8 +19,8 @@ jobs:
|
||||
# we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/cachix-action@v10
|
||||
- uses: cachix/install-nix-action@v18
|
||||
- uses: cachix/cachix-action@v12
|
||||
with:
|
||||
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
|
||||
name: nixpkgs-ci
|
||||
|
||||
2
.github/workflows/direct-push.yml
vendored
2
.github/workflows/direct-push.yml
vendored
@@ -21,7 +21,7 @@ jobs:
|
||||
id: ismerge
|
||||
run: |
|
||||
ISMERGE=$(curl -H 'Accept: application/vnd.github.groot-preview+json' -H "authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" https://api.github.com/repos/${{ env.GITHUB_REPOSITORY }}/commits/${{ env.GITHUB_SHA }}/pulls | jq -r '.[] | select(.merge_commit_sha == "${{ env.GITHUB_SHA }}") | any')
|
||||
echo "::set-output name=ismerge::$ISMERGE"
|
||||
echo "ismerge=$ISMERGE" >> $GITHUB_OUTPUT
|
||||
# github events are eventually consistent, so wait until changes propagate to thier DB
|
||||
- run: sleep 60
|
||||
if: steps.ismerge.outputs.ismerge != 'true'
|
||||
|
||||
2
.github/workflows/editorconfig.yml
vendored
2
.github/workflows/editorconfig.yml
vendored
@@ -28,7 +28,7 @@ jobs:
|
||||
with:
|
||||
# pull_request_target checks out the base branch by default
|
||||
ref: refs/pull/${{ github.event.pull_request.number }}/merge
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
# nixpkgs commit is pinned so that it doesn't break
|
||||
# editorconfig-checker 2.4.0
|
||||
|
||||
4
.github/workflows/manual-nixos.yml
vendored
4
.github/workflows/manual-nixos.yml
vendored
@@ -18,11 +18,11 @@ jobs:
|
||||
with:
|
||||
# pull_request_target checks out the base branch by default
|
||||
ref: refs/pull/${{ github.event.pull_request.number }}/merge
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
# explicitly enable sandbox
|
||||
extra_nix_config: sandbox = true
|
||||
- uses: cachix/cachix-action@v10
|
||||
- uses: cachix/cachix-action@v12
|
||||
with:
|
||||
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
|
||||
name: nixpkgs-ci
|
||||
|
||||
4
.github/workflows/manual-nixpkgs.yml
vendored
4
.github/workflows/manual-nixpkgs.yml
vendored
@@ -18,11 +18,11 @@ jobs:
|
||||
with:
|
||||
# pull_request_target checks out the base branch by default
|
||||
ref: refs/pull/${{ github.event.pull_request.number }}/merge
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
# explicitly enable sandbox
|
||||
extra_nix_config: sandbox = true
|
||||
- uses: cachix/cachix-action@v10
|
||||
- uses: cachix/cachix-action@v12
|
||||
with:
|
||||
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
|
||||
name: nixpkgs-ci
|
||||
|
||||
4
.github/workflows/manual-rendering.yml
vendored
4
.github/workflows/manual-rendering.yml
vendored
@@ -18,11 +18,11 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
# explicitly enable sandbox
|
||||
extra_nix_config: sandbox = true
|
||||
- uses: cachix/cachix-action@v10
|
||||
- uses: cachix/cachix-action@v12
|
||||
with:
|
||||
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.
|
||||
name: nixpkgs-ci
|
||||
|
||||
2
.github/workflows/nixos-manual.yml
vendored
2
.github/workflows/nixos-manual.yml
vendored
@@ -19,7 +19,7 @@ jobs:
|
||||
with:
|
||||
# pull_request_target checks out the base branch by default
|
||||
ref: refs/pull/${{ github.event.pull_request.number }}/merge
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
- name: Check DocBook files generated from Markdown are consistent
|
||||
run: |
|
||||
nixos/doc/manual/md-to-db.sh
|
||||
|
||||
33
.github/workflows/ofborg-pending.yml
vendored
Normal file
33
.github/workflows/ofborg-pending.yml
vendored
Normal file
@@ -0,0 +1,33 @@
|
||||
name: "Set pending OfBorg status"
|
||||
on:
|
||||
pull_request_target:
|
||||
|
||||
# Sets the ofborg-eval status to "pending" to signal that we are waiting for
|
||||
# OfBorg even if it is running late. The status will be overwritten by OfBorg
|
||||
# once it starts evaluation.
|
||||
|
||||
# WARNING:
|
||||
# When extending this action, be aware that $GITHUB_TOKEN allows (restricted) write access to
|
||||
# the GitHub repository. This means that it should not evaluate user input in a
|
||||
# way that allows code injection.
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
action:
|
||||
if: github.repository_owner == 'NixOS'
|
||||
permissions:
|
||||
statuses: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: "Set pending OfBorg status"
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
curl \
|
||||
-X POST \
|
||||
-H "Accept: application/vnd.github.v3+json" \
|
||||
-H "Authorization: Bearer $GITHUB_TOKEN" \
|
||||
-d '{"context": "ofborg-eval", "state": "pending", "description": "Waiting for OfBorg..."}' \
|
||||
"https://api.github.com/repos/NixOS/nixpkgs/commits/${{ github.event.pull_request.head.sha }}/statuses"
|
||||
26
.github/workflows/pending-clear.yml
vendored
26
.github/workflows/pending-clear.yml
vendored
@@ -1,26 +0,0 @@
|
||||
name: "clear pending status"
|
||||
|
||||
on:
|
||||
check_suite:
|
||||
types: [ completed ]
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
action:
|
||||
permissions:
|
||||
statuses: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: clear pending status
|
||||
if: github.repository_owner == 'NixOS' && github.event.check_suite.app.name == 'OfBorg'
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
curl \
|
||||
-X POST \
|
||||
-H "Accept: application/vnd.github.v3+json" \
|
||||
-H "Authorization: token $GITHUB_TOKEN" \
|
||||
-d '{"state": "success", "target_url": " ", "description": " ", "context": "Wait for ofborg"}' \
|
||||
"https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.check_suite.head_sha }}"
|
||||
30
.github/workflows/pending-set.yml
vendored
30
.github/workflows/pending-set.yml
vendored
@@ -1,30 +0,0 @@
|
||||
name: "set pending status"
|
||||
|
||||
on:
|
||||
pull_request_target:
|
||||
|
||||
# WARNING:
|
||||
# When extending this action, be aware that $GITHUB_TOKEN allows write access to
|
||||
# the GitHub repository. This means that it should not evaluate user input in a
|
||||
# way that allows code injection.
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
action:
|
||||
permissions:
|
||||
statuses: write
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: set pending status
|
||||
if: github.repository_owner == 'NixOS'
|
||||
env:
|
||||
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
||||
run: |
|
||||
curl \
|
||||
-X POST \
|
||||
-H "Accept: application/vnd.github.v3+json" \
|
||||
-H "Authorization: token $GITHUB_TOKEN" \
|
||||
-d '{"state": "pending", "target_url": " ", "description": "This pending status will be cleared when ofborg starts eval.", "context": "Wait for ofborg"}' \
|
||||
"https://api.github.com/repos/NixOS/nixpkgs/statuses/${{ github.event.pull_request.head.sha }}"
|
||||
4
.github/workflows/periodic-merge-24h.yml
vendored
4
.github/workflows/periodic-merge-24h.yml
vendored
@@ -34,6 +34,10 @@ jobs:
|
||||
pairs:
|
||||
- from: master
|
||||
into: haskell-updates
|
||||
- from: release-22.11
|
||||
into: staging-next-22.11
|
||||
- from: staging-next-22.11
|
||||
into: staging-22.11
|
||||
- from: release-22.05
|
||||
into: staging-next-22.05
|
||||
- from: staging-next-22.05
|
||||
|
||||
@@ -17,13 +17,13 @@ jobs:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- uses: cachix/install-nix-action@v17
|
||||
- uses: cachix/install-nix-action@v18
|
||||
with:
|
||||
nix_path: nixpkgs=channel:nixpkgs-unstable
|
||||
- name: setup
|
||||
id: setup
|
||||
run: |
|
||||
echo ::set-output name=title::"terraform-providers: update $(date -u +"%Y-%m-%d")"
|
||||
echo "title=terraform-providers: update $(date -u +"%Y-%m-%d")" >> $GITHUB_OUTPUT
|
||||
- name: update terraform-providers
|
||||
run: |
|
||||
git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
|
||||
@@ -34,6 +34,8 @@ jobs:
|
||||
--argstr keep-going true \
|
||||
--argstr max-workers 2 \
|
||||
--argstr path terraform-providers
|
||||
- name: clean repo
|
||||
run: |
|
||||
git clean -f
|
||||
- name: create PR
|
||||
uses: peter-evans/create-pull-request@v4
|
||||
@@ -41,6 +43,8 @@ jobs:
|
||||
body: |
|
||||
Automatic update by [update-terraform-providers](https://github.com/NixOS/nixpkgs/blob/master/.github/workflows/update-terraform-providers.yml) action.
|
||||
|
||||
https://github.com/NixOS/nixpkgs/actions/runs/${{ github.run_id }}
|
||||
|
||||
Check that all providers build with:
|
||||
```
|
||||
@ofborg build terraform.full
|
||||
|
||||
2
.gitignore
vendored
2
.gitignore
vendored
@@ -2,6 +2,8 @@
|
||||
,*
|
||||
.*.swp
|
||||
.*.swo
|
||||
.\#*
|
||||
\#*\#
|
||||
.idea/
|
||||
.vscode/
|
||||
outputs/
|
||||
|
||||
13
.mailmap
13
.mailmap
@@ -1 +1,14 @@
|
||||
ajs124 <git@ajs124.de> <ajs124@users.noreply.github.com>
|
||||
Anderson Torres <torres.anderson.85@protonmail.com>
|
||||
Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
|
||||
Fabian Affolter <mail@fabian-affolter.ch> <fabian@affolter-engineering.ch>
|
||||
Janne Heß <janne@hess.ooo> <dasJ@users.noreply.github.com>
|
||||
Jörg Thalheim <joerg@thalheim.io> <Mic92@users.noreply.github.com>
|
||||
Martin Weinelt <hexa@darmstadt.ccc.de> <mweinelt@users.noreply.github.com>
|
||||
R. RyanTM <ryantm-bot@ryantm.com>
|
||||
Robert Hensing <robert@roberthensing.nl> <roberth@users.noreply.github.com>
|
||||
Sandro Jäckel <sandro.jaeckel@gmail.com>
|
||||
Sandro Jäckel <sandro.jaeckel@gmail.com> <sandro.jaeckel@sap.com>
|
||||
superherointj <5861043+superherointj@users.noreply.github.com>
|
||||
Vladimír Čunát <v@cunat.cz> <vcunat@gmail.com>
|
||||
Vladimír Čunát <v@cunat.cz> <vladimir.cunat@nic.cz>
|
||||
|
||||
@@ -51,7 +51,11 @@ See the nixpkgs manual for more details on [standard meta-attributes](https://ni
|
||||
|
||||
In addition to writing properly formatted commit messages, it's important to include relevant information so other developers can later understand *why* a change was made. While this information usually can be found by digging code, mailing list/Discourse archives, pull request discussions or upstream changes, it may require a lot of work.
|
||||
|
||||
For package version upgrades and such a one-line commit message is usually sufficient.
|
||||
Package version upgrades usually allow for simpler commit messages, including attribute name, old and new version, as well as a reference to the relevant release notes/changelog. Every once in a while a package upgrade requires more extensive changes, and that subsequently warrants a more verbose message.
|
||||
|
||||
Pull requests should not be squash merged in order to keep complete commit messages and GPG signatures intact and must not be when the change doesn't make sense as a single commit.
|
||||
This means that, when addressing review comments in order to keep the pull request in an always mergeable status, you will sometimes need to rewrite your branch's history and then force-push it with `git push --force-with-lease`.
|
||||
Useful git commands that can help a lot with this are `git commit --patch --amend` and `git rebase --interactive @~3`. For more details consult the git man pages.
|
||||
|
||||
## Rebasing between branches (i.e. from master to staging)
|
||||
|
||||
@@ -98,17 +102,17 @@ git push origin feature --force-with-lease
|
||||
|
||||
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
|
||||
|
||||
You can add a label such as `backport release-22.05` to a PR, so that merging it will
|
||||
You can add a label such as `backport release-22.11` to a PR, so that merging it will
|
||||
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
|
||||
This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
|
||||
|
||||
You can also create the backport manually:
|
||||
|
||||
1. Take note of the commits in which the change was introduced into `master` branch.
|
||||
2. Check out the target _release branch_, e.g. `release-22.05`. Do not use a _channel branch_ like `nixos-22.05` or `nixpkgs-22.05-darwin`.
|
||||
2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
|
||||
3. Create a branch for your change, e.g. `git checkout -b backport`.
|
||||
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.05`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.05]`.
|
||||
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was comitted to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
|
||||
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
|
||||
|
||||
## Criteria for Backporting changes
|
||||
@@ -120,15 +124,15 @@ Anything that does not cause user or downstream dependency regressions can be ba
|
||||
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
|
||||
- Security critical applications (E.g. `firefox`)
|
||||
|
||||
## Generating 22.11 Release Notes
|
||||
## Generating 23.05 Release Notes
|
||||
|
||||
Documentation in nixpkgs is transitioning to a markdown-centric workflow. Release notes now require a translation step to convert from markdown to a compatible docbook document.
|
||||
|
||||
Steps for updating 22.11 Release notes:
|
||||
Steps for updating 23.05 Release notes:
|
||||
|
||||
1. Edit `nixos/doc/manual/release-notes/rl-2211.section.md` with the desired changes
|
||||
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2211.section.xml`
|
||||
3. Include changes to `rl-2211.section.md` and `rl-2211.section.xml` in the same commit.
|
||||
1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
|
||||
2. Run `./nixos/doc/manual/md-to-db.sh` to render `nixos/doc/manual/from_md/release-notes/rl-2305.section.xml`
|
||||
3. Include changes to `rl-2305.section.md` and `rl-2305.section.xml` in the same commit.
|
||||
|
||||
## Reviewing contributions
|
||||
|
||||
|
||||
@@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
|
||||
system, [Hydra](https://hydra.nixos.org/).
|
||||
|
||||
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
|
||||
* [Continuous package builds for the NixOS 22.05 release](https://hydra.nixos.org/jobset/nixos/release-22.05)
|
||||
* [Continuous package builds for the NixOS 22.11 release](https://hydra.nixos.org/jobset/nixos/release-22.11)
|
||||
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
|
||||
* [Tests for the NixOS 22.05 release](https://hydra.nixos.org/job/nixos/release-22.05/tested#tabs-constituents)
|
||||
* [Tests for the NixOS 22.11 release](https://hydra.nixos.org/job/nixos/release-22.11/tested#tabs-constituents)
|
||||
|
||||
Artifacts successfully built with Hydra are published to cache at
|
||||
https://cache.nixos.org/. When successful build and test criteria are
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
--[[
|
||||
Converts some HTML elements commonly used in Markdown to corresponding DocBook elements.
|
||||
]]
|
||||
|
||||
function RawInline(elem)
|
||||
if elem.format == 'html' and elem.text == '<kbd>' then
|
||||
return pandoc.RawInline('docbook', '<keycap>')
|
||||
elseif elem.format == 'html' and elem.text == '</kbd>' then
|
||||
return pandoc.RawInline('docbook', '</keycap>')
|
||||
end
|
||||
end
|
||||
@@ -14,7 +14,7 @@ For example, consider the following fetcher:
|
||||
```nix
|
||||
fetchurl {
|
||||
url = "http://www.example.org/hello-1.0.tar.gz";
|
||||
sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
|
||||
hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
|
||||
};
|
||||
```
|
||||
|
||||
@@ -23,17 +23,17 @@ A common mistake is to update a fetcher’s URL, or a version parameter, without
|
||||
```nix
|
||||
fetchurl {
|
||||
url = "http://www.example.org/hello-1.1.tar.gz";
|
||||
sha256 = "0v6r3wwnsk5pdjr188nip3pjgn1jrn5pc5ajpcfy6had6b3v4dwm";
|
||||
hash = "sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=";
|
||||
};
|
||||
```
|
||||
|
||||
**This will reuse the old contents**.
|
||||
Remember to invalidate the hash argument, in this case by setting the `sha256` attribute to an empty string.
|
||||
Remember to invalidate the hash argument, in this case by setting the `hash` attribute to an empty string.
|
||||
|
||||
```nix
|
||||
fetchurl {
|
||||
url = "http://www.example.org/hello-1.1.tar.gz";
|
||||
sha256 = "";
|
||||
hash = "";
|
||||
};
|
||||
```
|
||||
|
||||
@@ -42,14 +42,14 @@ Use the resulting error message to determine the correct hash.
|
||||
```
|
||||
error: hash mismatch in fixed-output derivation '/path/to/my.drv':
|
||||
specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
|
||||
got: sha256-RApQUm78dswhBLC/rfU9y0u6pSAzHceIJqgmetRD24E=
|
||||
got: sha256-lTeyxzJNQeMdu1IVdovNMtgn77jRIhSybLdMbTkf2Ww=
|
||||
```
|
||||
|
||||
A similar problem arises while testing changes to a fetcher's implementation. If the output of the derivation already exists in the Nix store, test failures can go undetected. The [`invalidateFetcherByDrvHash`](#tester-invalidateFetcherByDrvHash) function helps prevent reusing cached derivations.
|
||||
|
||||
## `fetchurl` and `fetchzip` {#fetchurl}
|
||||
|
||||
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `sha256`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `sha256`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
|
||||
Two basic fetchers are `fetchurl` and `fetchzip`. Both of these have two required arguments, a URL and a hash. The hash is typically `hash`, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use `hash`. This hash will be used by Nix to identify your source. A typical usage of `fetchurl` is provided below.
|
||||
|
||||
```nix
|
||||
{ stdenv, fetchurl }:
|
||||
@@ -58,7 +58,7 @@ stdenv.mkDerivation {
|
||||
name = "hello";
|
||||
src = fetchurl {
|
||||
url = "http://www.example.org/hello.tar.gz";
|
||||
sha256 = "1111111111111111111111111111111111111111111111111111";
|
||||
hash = "sha256-BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB=";
|
||||
};
|
||||
}
|
||||
```
|
||||
@@ -76,18 +76,18 @@ The main difference between `fetchurl` and `fetchzip` is in how they store the c
|
||||
- `includes`: Include only files matching these patterns (applies after the above arguments).
|
||||
- `revert`: Revert the patch.
|
||||
|
||||
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `sha256` argument is changed as well.
|
||||
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the `hash` argument is changed as well.
|
||||
|
||||
|
||||
Most other fetchers return a directory rather than a single file.
|
||||
|
||||
## `fetchsvn` {#fetchsvn}
|
||||
|
||||
Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `sha256`.
|
||||
Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `hash`.
|
||||
|
||||
## `fetchgit` {#fetchgit}
|
||||
|
||||
Used with Git. Expects `url` to a Git repo, `rev`, and `sha256`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
|
||||
Used with Git. Expects `url` to a Git repo, `rev`, and `hash`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
|
||||
|
||||
Additionally, the following optional arguments can be given: `fetchSubmodules = true` makes `fetchgit` also fetch the submodules of a repository. If `deepClone` is set to true, the entire repository is cloned as opposing to just creating a shallow clone. `deepClone = true` also implies `leaveDotGit = true` which means that the `.git` directory of the clone won't be removed after checkout.
|
||||
|
||||
@@ -100,36 +100,36 @@ stdenv.mkDerivation {
|
||||
name = "hello";
|
||||
src = fetchgit {
|
||||
url = "https://...";
|
||||
sparseCheckout = ''
|
||||
directory/to/be/included
|
||||
another/directory
|
||||
'';
|
||||
sha256 = "0000000000000000000000000000000000000000000000000000";
|
||||
sparseCheckout = [
|
||||
"directory/to/be/included"
|
||||
"another/directory"
|
||||
];
|
||||
hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## `fetchfossil` {#fetchfossil}
|
||||
|
||||
Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `sha256`.
|
||||
Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `hash`.
|
||||
|
||||
## `fetchcvs` {#fetchcvs}
|
||||
|
||||
Used with CVS. Expects `cvsRoot`, `tag`, and `sha256`.
|
||||
Used with CVS. Expects `cvsRoot`, `tag`, and `hash`.
|
||||
|
||||
## `fetchhg` {#fetchhg}
|
||||
|
||||
Used with Mercurial. Expects `url`, `rev`, and `sha256`.
|
||||
Used with Mercurial. Expects `url`, `rev`, and `hash`.
|
||||
|
||||
A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
|
||||
|
||||
## `fetchFromGitea` {#fetchfromgitea}
|
||||
|
||||
`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `sha256` is currently preferred.
|
||||
`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `hash` is currently preferred.
|
||||
|
||||
## `fetchFromGitHub` {#fetchfromgithub}
|
||||
|
||||
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `sha256` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `sha256` is currently preferred.
|
||||
`fetchFromGitHub` expects four arguments. `owner` is a string corresponding to the GitHub user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available, but `hash` is currently preferred.
|
||||
|
||||
`fetchFromGitHub` uses `fetchzip` to download the source archive generated by GitHub for the specified revision. If `leaveDotGit`, `deepClone` or `fetchSubmodules` are set to `true`, `fetchFromGitHub` will use `fetchgit` instead. Refer to its section for documentation of these options.
|
||||
|
||||
@@ -156,7 +156,7 @@ This is used with repo.or.cz repositories. The arguments expected are very simil
|
||||
## `fetchFromSourcehut` {#fetchfromsourcehut}
|
||||
|
||||
This is used with sourcehut repositories. Similar to `fetchFromGitHub` above,
|
||||
it expects `owner`, `repo`, `rev` and `sha256`, but don't forget the tilde (~)
|
||||
it expects `owner`, `repo`, `rev` and `hash`, but don't forget the tilde (~)
|
||||
in front of the username! Expected arguments also include `vc` ("git" (default)
|
||||
or "hg"), `domain` and `fetchSubmodules`.
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ appimageTools.wrapType2 { # or wrapType1
|
||||
name = "patchwork";
|
||||
src = fetchurl {
|
||||
url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
|
||||
sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
|
||||
hash = "sha256-OqTitCeZ6xmWbqYTXp8sDrmVgTNjPZNW0hzUPW++mq4=";
|
||||
};
|
||||
extraPkgs = pkgs: with pkgs; [ ];
|
||||
}
|
||||
|
||||
@@ -62,6 +62,8 @@ The above example will build a Docker image `redis/latest` from the given base i
|
||||
|
||||
- `config` is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
|
||||
|
||||
- `architecture` is _optional_ and used to specify the image architecture, this is useful for multi-architecture builds that don't need cross compiling. If not specified it will default to `hostPlatform`.
|
||||
|
||||
- `diskSize` is used to specify the disk size of the VM used to build the image in megabytes. By default it's 1024 MiB.
|
||||
|
||||
- `buildVMMemorySize` is used to specify the memory size of the VM to build the image in megabytes. By default it's 512 MiB.
|
||||
@@ -141,6 +143,8 @@ Create a Docker image with many of the store paths being on their own layer to i
|
||||
|
||||
`config` _optional_
|
||||
|
||||
`architecture` is _optional_ and used to specify the image architecture, this is useful for multi-architecture builds that don't need cross compiling. If not specified it will default to `hostPlatform`.
|
||||
|
||||
: Run-time configuration of the container. A full list of the options are available at in the [Docker Image Specification v1.2.0](https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions).
|
||||
|
||||
*Default:* `{}`
|
||||
@@ -245,10 +249,10 @@ Its parameters are described in the example below:
|
||||
pullImage {
|
||||
imageName = "nixos/nix";
|
||||
imageDigest =
|
||||
"sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b";
|
||||
"sha256:473a2b527958665554806aea24d0131bacec46d23af09fef4598eeab331850fa";
|
||||
finalImageName = "nix";
|
||||
finalImageTag = "1.11";
|
||||
sha256 = "0mqjy3zq2v6rrhizgb9nvhczl87lcfphq9601wcprdika2jz7qh8";
|
||||
finalImageTag = "2.11.1";
|
||||
sha256 = "sha256-qvhj+Hlmviz+KEBVmsyPIzTB3QlVAFzwAY1zDPIBGxc=";
|
||||
os = "linux";
|
||||
arch = "x86_64";
|
||||
}
|
||||
@@ -394,3 +398,142 @@ buildImage {
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
## buildNixShellImage {#ssec-pkgs-dockerTools-buildNixShellImage}
|
||||
|
||||
Create a Docker image that sets up an environment similar to that of running `nix-shell` on a derivation.
|
||||
When run in Docker, this environment somewhat resembles the Nix sandbox typically used by `nix-build`, with a major difference being that access to the internet is allowed.
|
||||
It additionally also behaves like an interactive `nix-shell`, running things like `shellHook` and setting an interactive prompt.
|
||||
If the derivation is fully buildable (i.e. `nix-build` can be used on it), running `buildDerivation` inside such a Docker image will build the derivation, with all its outputs being available in the correct `/nix/store` paths, pointed to by the respective environment variables like `$out`, etc.
|
||||
|
||||
::: {.warning}
|
||||
The behavior doesn't match `nix-shell` or `nix-build` exactly and this function is known not to work correctly for e.g. fixed-output derivations, content-addressed derivations, impure derivations and other special types of derivations.
|
||||
:::
|
||||
|
||||
### Arguments
|
||||
|
||||
`drv`
|
||||
|
||||
: The derivation on which to base the Docker image.
|
||||
|
||||
Adding packages to the Docker image is possible by e.g. extending the list of `nativeBuildInputs` of this derivation like
|
||||
|
||||
```nix
|
||||
buildNixShellImage {
|
||||
drv = someDrv.overrideAttrs (old: {
|
||||
nativeBuildInputs = old.nativeBuildInputs or [] ++ [
|
||||
somethingExtra
|
||||
];
|
||||
});
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
Similarly, you can extend the image initialization script by extending `shellHook`
|
||||
|
||||
`name` _optional_
|
||||
|
||||
: The name of the resulting image.
|
||||
|
||||
*Default:* `drv.name + "-env"`
|
||||
|
||||
`tag` _optional_
|
||||
|
||||
: Tag of the generated image.
|
||||
|
||||
*Default:* the resulting image derivation output path's hash
|
||||
|
||||
`uid`/`gid` _optional_
|
||||
|
||||
: The user/group ID to run the container as. This is like a `nixbld` build user.
|
||||
|
||||
*Default:* 1000/1000
|
||||
|
||||
`homeDirectory` _optional_
|
||||
|
||||
: The home directory of the user the container is running as
|
||||
|
||||
*Default:* `/build`
|
||||
|
||||
`shell` _optional_
|
||||
|
||||
: The path to the `bash` binary to use as the shell. This shell is started when running the image.
|
||||
|
||||
*Default:* `pkgs.bashInteractive + "/bin/bash"`
|
||||
|
||||
`command` _optional_
|
||||
|
||||
: Run this command in the environment of the derivation, in an interactive shell. See the `--command` option in the [`nix-shell` documentation](https://nixos.org/manual/nix/stable/command-ref/nix-shell.html?highlight=nix-shell#options).
|
||||
|
||||
*Default:* (none)
|
||||
|
||||
`run` _optional_
|
||||
|
||||
: Same as `command`, but runs the command in a non-interactive shell instead. See the `--run` option in the [`nix-shell` documentation](https://nixos.org/manual/nix/stable/command-ref/nix-shell.html?highlight=nix-shell#options).
|
||||
|
||||
*Default:* (none)
|
||||
|
||||
### Example
|
||||
|
||||
The following shows how to build the `pkgs.hello` package inside a Docker container built with `buildNixShellImage`.
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
dockerTools.buildNixShellImage {
|
||||
drv = hello;
|
||||
}
|
||||
```
|
||||
|
||||
Build the derivation:
|
||||
|
||||
```console
|
||||
nix-build hello.nix
|
||||
```
|
||||
|
||||
these 8 derivations will be built:
|
||||
/nix/store/xmw3a5ln29rdalavcxk1w3m4zb2n7kk6-nix-shell-rc.drv
|
||||
...
|
||||
Creating layer 56 from paths: ['/nix/store/crpnj8ssz0va2q0p5ibv9i6k6n52gcya-stdenv-linux']
|
||||
Creating layer 57 with customisation...
|
||||
Adding manifests...
|
||||
Done.
|
||||
/nix/store/cpyn1lc897ghx0rhr2xy49jvyn52bazv-hello-2.12-env.tar.gz
|
||||
|
||||
Load the image:
|
||||
|
||||
```console
|
||||
docker load -i result
|
||||
```
|
||||
|
||||
0d9f4c4cd109: Loading layer [==================================================>] 2.56MB/2.56MB
|
||||
...
|
||||
ab1d897c0697: Loading layer [==================================================>] 10.24kB/10.24kB
|
||||
Loaded image: hello-2.12-env:pgj9h98nal555415faa43vsydg161bdz
|
||||
|
||||
Run the container:
|
||||
|
||||
```console
|
||||
docker run -it hello-2.12-env:pgj9h98nal555415faa43vsydg161bdz
|
||||
```
|
||||
|
||||
[nix-shell:/build]$
|
||||
|
||||
In the running container, run the build:
|
||||
|
||||
```console
|
||||
buildDerivation
|
||||
```
|
||||
|
||||
unpacking sources
|
||||
unpacking source archive /nix/store/8nqv6kshb3vs5q5bs2k600xpj5bkavkc-hello-2.12.tar.gz
|
||||
...
|
||||
patching script interpreter paths in /nix/store/z5wwy5nagzy15gag42vv61c2agdpz2f2-hello-2.12
|
||||
checking for references to /build/ in /nix/store/z5wwy5nagzy15gag42vv61c2agdpz2f2-hello-2.12...
|
||||
|
||||
Check the build result:
|
||||
|
||||
```console
|
||||
$out/bin/hello
|
||||
```
|
||||
|
||||
Hello, world!
|
||||
|
||||
@@ -15,7 +15,7 @@ This allows using Nix to build images which can be run on many recent Linux dist
|
||||
The primary tool for interacting with Portable Services is `portablectl`,
|
||||
and they are managed by the `systemd-portabled` system service.
|
||||
|
||||
:::{.note}
|
||||
::: {.note}
|
||||
Portable services are supported starting with systemd 239 (released on 2018-06-22).
|
||||
:::
|
||||
|
||||
@@ -37,7 +37,7 @@ dependencies of the two derivations in the `units` list.
|
||||
`units` must be a list of derivations, and their names must be prefixed with the service name (`"demo"` in this case).
|
||||
Otherwise `systemd-portabled` will ignore them.
|
||||
|
||||
:::{.Note}
|
||||
::: {.note}
|
||||
The `.raw` file extension of the image is required by the portable services specification.
|
||||
:::
|
||||
|
||||
@@ -76,6 +76,6 @@ portablectl attach demo_1.0.raw
|
||||
systemctl enable --now demo.socket
|
||||
systemctl enable --now demo.service
|
||||
```
|
||||
:::{.Note}
|
||||
::: {.note}
|
||||
See the [man page](https://www.freedesktop.org/software/systemd/man/portablectl.html) of `portablectl` for more info on its usage.
|
||||
:::
|
||||
|
||||
@@ -103,7 +103,7 @@ let
|
||||
owner = "Someone";
|
||||
repo = "AwesomeMod";
|
||||
rev = "...";
|
||||
sha256 = "...";
|
||||
hash = "...";
|
||||
};
|
||||
# Path to be installed in the unpacked source (default: ".")
|
||||
modRoot = "contents/under/this/path/will/be/installed";
|
||||
|
||||
@@ -43,11 +43,11 @@ packageOverrides = pkgs: {
|
||||
name = "myplugin1-1.0";
|
||||
srcFeature = fetchurl {
|
||||
url = "http://…/features/myplugin1.jar";
|
||||
sha256 = "123…";
|
||||
hash = "sha256-123…";
|
||||
};
|
||||
srcPlugin = fetchurl {
|
||||
url = "http://…/plugins/myplugin1.jar";
|
||||
sha256 = "123…";
|
||||
hash = "sha256-123…";
|
||||
};
|
||||
});
|
||||
(plugins.buildEclipseUpdateSite {
|
||||
@@ -55,7 +55,7 @@ packageOverrides = pkgs: {
|
||||
src = fetchurl {
|
||||
stripRoot = false;
|
||||
url = "http://…/myplugin2.zip";
|
||||
sha256 = "123…";
|
||||
hash = "sha256-123…";
|
||||
};
|
||||
});
|
||||
];
|
||||
|
||||
@@ -12,7 +12,7 @@ The `wrapFirefox` function allows to pass policies, preferences and extensions t
|
||||
(fetchFirefoxAddon {
|
||||
name = "ublock"; # Has to be unique!
|
||||
url = "https://addons.mozilla.org/firefox/downloads/file/3679754/ublock_origin-1.31.0-an+fx.xpi";
|
||||
sha256 = "1h768ljlh3pi23l27qp961v1hd0nbj2vasgy11bmcrlqp40zgvnr";
|
||||
hash = "sha256-2e73AbmYZlZXCP5ptYVcFjQYdjDp4iPoEPEOSCVF5sA=";
|
||||
})
|
||||
];
|
||||
|
||||
|
||||
@@ -73,7 +73,7 @@ stdenv.mkDerivation {
|
||||
name = "exemplary-weechat-script";
|
||||
src = fetchurl {
|
||||
url = "https://scripts.tld/your-scripts.tar.gz";
|
||||
sha256 = "...";
|
||||
hash = "...";
|
||||
};
|
||||
passthru.scripts = [ "foo.py" "bar.lua" ];
|
||||
installPhase = ''
|
||||
|
||||
@@ -35,6 +35,70 @@ passthru.tests.version = testers.testVersion {
|
||||
};
|
||||
```
|
||||
|
||||
## `testBuildFailure` {#tester-testBuildFailure}
|
||||
|
||||
Make sure that a build does not succeed. This is useful for testing testers.
|
||||
|
||||
This returns a derivation with an override on the builder, with the following effects:
|
||||
|
||||
- Fail the build when the original builder succeeds
|
||||
- Move `$out` to `$out/result`, if it exists (assuming `out` is the default output)
|
||||
- Save the build log to `$out/testBuildFailure.log` (same)
|
||||
|
||||
Example:
|
||||
|
||||
```nix
|
||||
runCommand "example" {
|
||||
failed = testers.testBuildFailure (runCommand "fail" {} ''
|
||||
echo ok-ish >$out
|
||||
echo failing though
|
||||
exit 3
|
||||
'');
|
||||
} ''
|
||||
grep -F 'ok-ish' $failed/result
|
||||
grep -F 'failing though' $failed/testBuildFailure.log
|
||||
[[ 3 = $(cat $failed/testBuildFailure.exit) ]]
|
||||
touch $out
|
||||
'';
|
||||
```
|
||||
|
||||
While `testBuildFailure` is designed to keep changes to the original builder's
|
||||
environment to a minimum, some small changes are inevitable.
|
||||
|
||||
- The file `$TMPDIR/testBuildFailure.log` is present. It should not be deleted.
|
||||
- `stdout` and `stderr` are a pipe instead of a tty. This could be improved.
|
||||
- One or two extra processes are present in the sandbox during the original
|
||||
builder's execution.
|
||||
- The derivation and output hashes are different, but not unusual.
|
||||
- The derivation includes a dependency on `buildPackages.bash` and
|
||||
`expect-failure.sh`, which is built to include a transitive dependency on
|
||||
`buildPackages.coreutils` and possibly more. These are not added to `PATH`
|
||||
or any other environment variable, so they should be hard to observe.
|
||||
|
||||
## `testEqualContents` {#tester-equalContents}
|
||||
|
||||
Check that two paths have the same contents.
|
||||
|
||||
Example:
|
||||
|
||||
```nix
|
||||
testers.testEqualContents {
|
||||
assertion = "sed -e performs replacement";
|
||||
expected = writeText "expected" ''
|
||||
foo baz baz
|
||||
'';
|
||||
actual = runCommand "actual" {
|
||||
# not really necessary for a package that's in stdenv
|
||||
nativeBuildInputs = [ gnused ];
|
||||
base = writeText "base" ''
|
||||
foo bar baz
|
||||
'';
|
||||
} ''
|
||||
sed -e 's/bar/baz/g' $base >$out
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
## `testEqualDerivation` {#tester-testEqualDerivation}
|
||||
|
||||
Checks that two packages produce the exact same build instructions.
|
||||
@@ -83,7 +147,7 @@ tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
|
||||
name = "nix-source";
|
||||
url = "https://github.com/NixOS/nix";
|
||||
rev = "9d9dbe6ed05854e03811c361a3380e09183f4f4a";
|
||||
sha256 = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
|
||||
hash = "sha256-7DszvbCNTjpzGRmpIVAWXk20P0/XTrWZ79KSOGLrUWY=";
|
||||
};
|
||||
```
|
||||
|
||||
|
||||
@@ -426,9 +426,10 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
|
||||
|
||||
```nix
|
||||
src = fetchgit {
|
||||
url = "git@github.com:NixOS/nix.git"
|
||||
url = "git://github.com/NixOS/nix.git";
|
||||
rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
|
||||
sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
|
||||
hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
|
||||
}
|
||||
```
|
||||
|
||||
@@ -438,7 +439,7 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
|
||||
src = fetchgit {
|
||||
url = "https://github.com/NixOS/nix.git";
|
||||
rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
|
||||
sha256 = "1cw5fszffl5pkpa6s6wjnkiv6lm5k618s32sp60kvmvpy7a2v9kg";
|
||||
hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
|
||||
}
|
||||
```
|
||||
|
||||
@@ -449,14 +450,14 @@ In the file `pkgs/top-level/all-packages.nix` you can find fetch helpers, these
|
||||
owner = "NixOS";
|
||||
repo = "nix";
|
||||
rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
|
||||
sha256 = "1i2yxndxb6yc9l6c99pypbd92lfq5aac4klq7y2v93c9qvx2cgpc";
|
||||
hash = "ha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=;
|
||||
}
|
||||
```
|
||||
|
||||
When fetching from GitHub, commits must always be referenced by their full commit hash. This is because GitHub shares commit hashes among all forks and returns `404 Not Found` when a short commit hash is ambiguous. It already happens for some short, 6-character commit hashes in `nixpkgs`.
|
||||
It is a practical vector for a denial-of-service attack by pushing large amounts of auto generated commits into forks and was already [demonstrated against GitHub Actions Beta](https://blog.teddykatz.com/2019/11/12/github-actions-dos.html).
|
||||
|
||||
Find the value to put as `sha256` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`.
|
||||
Find the value to put as `hash` by running `nix-shell -p nix-prefetch-github --run "nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix"`.
|
||||
|
||||
## Obtaining source hash {#sec-source-hashes}
|
||||
|
||||
@@ -480,15 +481,23 @@ Preferred source hash type is sha256. There are several ways to get it.
|
||||
|
||||
4. Extracting hash from local source tarball can be done with `sha256sum`. Use `nix-prefetch-url file:///path/to/tarball` if you want base32 hash.
|
||||
|
||||
5. Fake hash: set fake hash in package expression, perform build and extract correct hash from error Nix prints.
|
||||
5. Fake hash: set the hash to one of
|
||||
|
||||
For package updates it is enough to change one symbol to make hash fake. For new packages, you can use `lib.fakeSha256`, `lib.fakeSha512` or any other fake hash.
|
||||
- `""`
|
||||
- `lib.fakeHash`
|
||||
- `lib.fakeSha256`
|
||||
- `lib.fakeSha512`
|
||||
|
||||
in the package expression, attempt build and extract correct hash from error messages.
|
||||
|
||||
::: {.warning}
|
||||
You must use one of these four fake hashes and not some arbitrarily-chosen hash.
|
||||
|
||||
See [](#sec-source-hashes-security).
|
||||
:::
|
||||
|
||||
This is last resort method when reconstructing source URL is non-trivial and `nix-prefetch-url -A` isn’t applicable (for example, [one of `kodi` dependencies](https://github.com/NixOS/nixpkgs/blob/d2ab091dd308b99e4912b805a5eb088dd536adb9/pkgs/applications/video/kodi/default.nix#L73)). The easiest way then would be replace hash with a fake one and rebuild. Nix build will fail and error message will contain desired hash.
|
||||
|
||||
::: {.warning}
|
||||
This method has security problems. Check below for details.
|
||||
:::
|
||||
|
||||
### Obtaining hashes securely {#sec-source-hashes-security}
|
||||
|
||||
@@ -500,7 +509,7 @@ Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of f
|
||||
|
||||
- `https://` URLs are secure in methods 1, 2, 3;
|
||||
|
||||
- `https://` URLs are not secure in method 5. When obtaining hashes with fake hash method, TLS checks are disabled. So refetch source hash from several different networks to exclude MITM scenario. Alternatively, use fake hash method to make Nix error, but instead of extracting hash from error, extract `https://` URL and prefetch it with method 1.
|
||||
- `https://` URLs are secure in method 5 *only if* you use one of the listed fake hashes. If you use any other hash, `fetchurl` will pass `--insecure` to `curl` and may then degrade to HTTP in case of TLS certificate expiration.
|
||||
|
||||
## Patches {#sec-patches}
|
||||
|
||||
@@ -511,7 +520,7 @@ patches = [
|
||||
(fetchpatch {
|
||||
name = "fix-check-for-using-shared-freetype-lib.patch";
|
||||
url = "http://git.ghostscript.com/?p=ghostpdl.git;a=patch;h=8f5d285";
|
||||
sha256 = "1f0k043rng7f0rfl9hhb89qzvvksqmkrikmm38p61yfx51l325xr";
|
||||
hash = "sha256-uRcxaCjd+WAuGrXOmGfFeu79cUILwkRdBu48mwcBE7g=";
|
||||
})
|
||||
];
|
||||
```
|
||||
@@ -661,3 +670,18 @@ stdenv.mkDerivation {
|
||||
...
|
||||
}
|
||||
```
|
||||
|
||||
### Import From Derivation {#ssec-import-from-derivation}
|
||||
|
||||
Import From Derivation (IFD) is disallowed in Nixpkgs for performance reasons:
|
||||
[Hydra] evaluates the entire package set, and sequential builds during evaluation would increase evaluation times to become impractical.
|
||||
|
||||
[Hydra]: https://github.com/NixOS/hydra
|
||||
|
||||
Import From Derivation can be worked around in some cases by committing generated intermediate files to version control and reading those instead.
|
||||
|
||||
<!-- TODO: remove the following and link to Nix manual once https://github.com/NixOS/nix/pull/7332 is merged -->
|
||||
|
||||
See also [NixOS Wiki: Import From Derivation].
|
||||
|
||||
[NixOS Wiki: Import From Derivation]: https://nixos.wiki/wiki/Import_From_Derivation
|
||||
|
||||
@@ -302,6 +302,12 @@ Container system, boot system and library changes are some examples of the pull
|
||||
|
||||
It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
|
||||
|
||||
In case the PR is stuck waiting for the original author to apply a trivial
|
||||
change (a typo, capitalisation change, etc.) and the author allowed the members
|
||||
to modify the PR, consider applying it yourself. (or commit the existing review
|
||||
suggestion) You should pay extra attention to make sure the addition doesn't go
|
||||
against the idea of the original PR and would not be opposed by the author.
|
||||
|
||||
<!--
|
||||
The following paragraphs about how to deal with unactive contributors is just a proposition and should be modified to what the community agrees to be the right policy.
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ Security fixes are submitted in the same way as other changes and thus the same
|
||||
(fetchpatch {
|
||||
name = "CVE-2019-11068.patch";
|
||||
url = "https://gitlab.gnome.org/GNOME/libxslt/commit/e03553605b45c88f0b4b2980adfbbb8f6fca2fd6.patch";
|
||||
sha256 = "0pkpb4837km15zgg6h57bncp66d5lwrlvkr73h0lanywq7zrwhj8";
|
||||
hash = "sha256-SEKe/8HcW0UBHCfPTTOnpRlzmV2nQPPeL6HOMxBZd14=";
|
||||
})
|
||||
```
|
||||
|
||||
@@ -244,12 +244,16 @@ The `master` branch is the main development branch. It should only see non-break
|
||||
|
||||
The `staging` branch is a development branch where mass-rebuilds go. Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it's 'light' packages, 1000). It should only see non-breaking mass-rebuild commits. That means it is not to be used for testing, and changes must have been well tested already. If the branch is already in a broken state, please refrain from adding extra new breakages.
|
||||
|
||||
During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes.
|
||||
|
||||
### Staging-next branch {#submitting-changes-staging-next-branch}
|
||||
|
||||
The `staging-next` branch is for stabilizing mass-rebuilds submitted to the `staging` branch prior to merging them into `master`. Mass-rebuilds must go via the `staging` branch. It must only see non-breaking commits that are fixing issues blocking it from being merged into the `master` branch.
|
||||
|
||||
If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
|
||||
|
||||
During the process of a releasing a new NixOS version, this branch or the release-critical packages can be restricted to non-breaking changes.
|
||||
|
||||
### Stable release branches {#submitting-changes-stable-release-branches}
|
||||
|
||||
The same staging workflow applies to stable release branches, but the main branch is called `release-*` instead of `master`.
|
||||
|
||||
@@ -17,11 +17,14 @@ with pkgs; stdenv.mkDerivation {
|
||||
mkdir -p $out
|
||||
ln -s ${locationsXml} $out/locations.xml
|
||||
|
||||
docgen asserts 'Assert functions'
|
||||
docgen attrsets 'Attribute-set functions'
|
||||
docgen strings 'String manipulation functions'
|
||||
docgen trivial 'Miscellaneous functions'
|
||||
docgen lists 'List manipulation functions'
|
||||
docgen debug 'Debugging functions'
|
||||
docgen options 'NixOS / nixpkgs option handling'
|
||||
docgen filesystem 'Filesystem functions'
|
||||
docgen sources 'Source filtering functions'
|
||||
'';
|
||||
}
|
||||
|
||||
@@ -2,11 +2,14 @@
|
||||
<xsl:stylesheet
|
||||
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
|
||||
version="1.0">
|
||||
<xsl:param name="section.autolabel" select="1" />
|
||||
<xsl:param name="section.label.includes.component.label" select="1" />
|
||||
<xsl:param name="chapter.autolabel" select="0" />
|
||||
<xsl:param name="part.autolabel" select="0" />
|
||||
<xsl:param name="preface.autolabel" select="0" />
|
||||
<xsl:param name="reference.autolabel" select="0" />
|
||||
<xsl:param name="section.autolabel" select="0" />
|
||||
<xsl:param name="html.stylesheet" select="'style.css overrides.css highlightjs/mono-blue.css'" />
|
||||
<xsl:param name="html.script" select="'./highlightjs/highlight.pack.js ./highlightjs/loader.js'" />
|
||||
<xsl:param name="xref.with.number.and.title" select="1" />
|
||||
<xsl:param name="xref.with.number.and.title" select="0" />
|
||||
<xsl:param name="use.id.as.filename" select="1" />
|
||||
<xsl:param name="toc.section.depth" select="0" />
|
||||
<xsl:param name="admon.style" select="''" />
|
||||
|
||||
@@ -8,14 +8,14 @@
|
||||
Nixpkgs provides a standard library at <varname>pkgs.lib</varname>, or through <code>import <nixpkgs/lib></code>.
|
||||
</para>
|
||||
|
||||
<xi:include href="./library/asserts.xml" />
|
||||
|
||||
<xi:include href="./library/attrsets.xml" />
|
||||
|
||||
<!-- These docs are generated via nixdoc. To add another generated
|
||||
library function file to this list, the file
|
||||
`lib-function-docs.nix` must also be updated. -->
|
||||
|
||||
<xi:include href="./library/generated/asserts.xml" />
|
||||
|
||||
<xi:include href="./library/generated/attrsets.xml" />
|
||||
|
||||
<xi:include href="./library/generated/strings.xml" />
|
||||
|
||||
<xi:include href="./library/generated/trivial.xml" />
|
||||
@@ -26,5 +26,7 @@
|
||||
|
||||
<xi:include href="./library/generated/options.xml" />
|
||||
|
||||
<xi:include href="./library/generated/filesystem.xml" />
|
||||
|
||||
<xi:include href="./library/generated/sources.xml" />
|
||||
</section>
|
||||
|
||||
0
doc/functions/library/.gitkeep
Normal file
0
doc/functions/library/.gitkeep
Normal file
@@ -1,112 +0,0 @@
|
||||
<section xmlns="http://docbook.org/ns/docbook"
|
||||
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||
xml:id="sec-functions-library-asserts">
|
||||
<title>Assert functions</title>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertMsg">
|
||||
<title><function>lib.asserts.assertMsg</function></title>
|
||||
|
||||
<subtitle><literal>assertMsg :: Bool -> String -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertMsg" />
|
||||
|
||||
<para>
|
||||
Print a trace message if <literal>pred</literal> is false.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Intended to be used to augment asserts with helpful error messages.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>pred</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Condition under which the <varname>msg</varname> should <emphasis>not</emphasis> be printed.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>msg</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
Message to print.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertMsg-example-false">
|
||||
<title>Printing when the predicate is false</title>
|
||||
<programlisting><![CDATA[
|
||||
assert lib.asserts.assertMsg ("foo" == "bar") "foo is not bar, silly"
|
||||
stderr> trace: foo is not bar, silly
|
||||
stderr> assert failed
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
|
||||
<section xml:id="function-library-lib.asserts.assertOneOf">
|
||||
<title><function>lib.asserts.assertOneOf</function></title>
|
||||
|
||||
<subtitle><literal>assertOneOf :: String -> String ->
|
||||
StringList -> Bool</literal>
|
||||
</subtitle>
|
||||
|
||||
<xi:include href="./locations.xml" xpointer="lib.asserts.assertOneOf" />
|
||||
|
||||
<para>
|
||||
Specialized <function>asserts.assertMsg</function> for checking if <varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
|
||||
</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>name</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>val</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The value of what the user provided, to be compared against the values in <varname>xs</varname>.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>
|
||||
<varname>xs</varname>
|
||||
</term>
|
||||
<listitem>
|
||||
<para>
|
||||
The list of valid values.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<example xml:id="function-library-lib.asserts.assertOneOf-example">
|
||||
<title>Ensuring a user provided a possible value</title>
|
||||
<programlisting><![CDATA[
|
||||
let sslLibrary = "bearssl";
|
||||
in lib.asserts.assertOneOf "sslLibrary" sslLibrary [ "openssl" "libressl" ];
|
||||
=> false
|
||||
stderr> trace: sslLibrary must be one of "openssl", "libressl", but is: "bearssl"
|
||||
]]></programlisting>
|
||||
</example>
|
||||
</section>
|
||||
</section>
|
||||
File diff suppressed because it is too large
Load Diff
4
doc/hooks/autoconf.section.md
Normal file
4
doc/hooks/autoconf.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### Autoconf {#setup-hook-autoconf}
|
||||
|
||||
The `autoreconfHook` derivation adds `autoreconfPhase`, which runs autoreconf, libtoolize and automake, essentially preparing the configure script in autotools-based builds. Most autotools-based packages come with the configure script pre-generated, but this hook is necessary for a few packages and when you need to patch the package’s configure scripts.
|
||||
4
doc/hooks/automake.section.md
Normal file
4
doc/hooks/automake.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### Automake {#setup-hook-automake}
|
||||
|
||||
Adds the `share/aclocal` subdirectory of each build input to the `ACLOCAL_PATH` environment variable.
|
||||
12
doc/hooks/autopatchelf.section.md
Normal file
12
doc/hooks/autopatchelf.section.md
Normal file
@@ -0,0 +1,12 @@
|
||||
|
||||
### autoPatchelfHook {#setup-hook-autopatchelfhook}
|
||||
|
||||
This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given `buildInputs` and `nativeBuildInputs`.
|
||||
|
||||
You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime.
|
||||
|
||||
In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
|
||||
|
||||
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
|
||||
|
||||
The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.
|
||||
18
doc/hooks/breakpoint.section.md
Normal file
18
doc/hooks/breakpoint.section.md
Normal file
@@ -0,0 +1,18 @@
|
||||
|
||||
### breakpointHook {#breakpointhook}
|
||||
|
||||
This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
|
||||
|
||||
```nix
|
||||
nativeBuildInputs = [ breakpointHook ];
|
||||
```
|
||||
|
||||
When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
|
||||
|
||||
::: {.note}
|
||||
::: {.title}
|
||||
Caution with remote builds
|
||||
:::
|
||||
|
||||
This won’t work with remote builds as the build environment is on a different machine and can’t be accessed by `cntr`. Remote builds can be turned off by setting `--option builders ''` for `nix-build` or `--builders ''` for `nix build`.
|
||||
:::
|
||||
4
doc/hooks/cmake.section.md
Normal file
4
doc/hooks/cmake.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### cmake {#cmake}
|
||||
|
||||
Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to `CMAKE_PREFIX_PATH` so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`. `cmakeFlags` controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.
|
||||
4
doc/hooks/gdk-pixbuf.section.md
Normal file
4
doc/hooks/gdk-pixbuf.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### gdk-pixbuf {#setup-hook-gdk-pixbuf}
|
||||
|
||||
Exports `GDK_PIXBUF_MODULE_FILE` environment variable to the builder. Add librsvg package to `buildInputs` to get svg support. See also the [setup hook description in GNOME platform docs](#ssec-gnome-hooks-gdk-pixbuf).
|
||||
4
doc/hooks/ghc.section.md
Normal file
4
doc/hooks/ghc.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### GHC {#ghc}
|
||||
|
||||
Creates a temporary package database and registers every Haskell build input in it (TODO: how?).
|
||||
4
doc/hooks/gnome.section.md
Normal file
4
doc/hooks/gnome.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### GNOME platform {#gnome-platform}
|
||||
|
||||
Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in [](#sec-language-gnome).
|
||||
@@ -6,5 +6,32 @@
|
||||
<para>
|
||||
Nixpkgs has several hook packages that augment the stdenv phases.
|
||||
</para>
|
||||
<para>
|
||||
The stdenv built-in hooks are documented in <xref linkend="ssec-setup-hooks"/>.
|
||||
</para>
|
||||
<xi:include href="./autoconf.section.xml" />
|
||||
<xi:include href="./automake.section.xml" />
|
||||
<xi:include href="./autopatchelf.section.xml" />
|
||||
<xi:include href="./breakpoint.section.xml" />
|
||||
<xi:include href="./cmake.section.xml" />
|
||||
<xi:include href="./gdk-pixbuf.section.xml" />
|
||||
<xi:include href="./ghc.section.xml" />
|
||||
<xi:include href="./gnome.section.xml" />
|
||||
<xi:include href="./installShellFiles.section.xml" />
|
||||
<xi:include href="./libiconv.section.xml" />
|
||||
<xi:include href="./libxml2.section.xml" />
|
||||
<xi:include href="./meson.section.xml" />
|
||||
<xi:include href="./ninja.section.xml" />
|
||||
<xi:include href="./patch-rc-path-hooks.section.xml" />
|
||||
<xi:include href="./perl.section.xml" />
|
||||
<xi:include href="./pkg-config.section.xml" />
|
||||
<xi:include href="./postgresql-test-hook.section.xml" />
|
||||
<xi:include href="./python.section.xml" />
|
||||
<xi:include href="./qt-4.section.xml" />
|
||||
<xi:include href="./scons.section.xml" />
|
||||
<xi:include href="./tetex-tex-live.section.xml" />
|
||||
<xi:include href="./unzip.section.xml" />
|
||||
<xi:include href="./validatePkgConfig.section.xml" />
|
||||
<xi:include href="./waf.section.xml" />
|
||||
<xi:include href="./xcbuild.section.xml" />
|
||||
</chapter>
|
||||
|
||||
26
doc/hooks/installShellFiles.section.md
Normal file
26
doc/hooks/installShellFiles.section.md
Normal file
@@ -0,0 +1,26 @@
|
||||
|
||||
### `installShellFiles` {#installshellfiles}
|
||||
|
||||
This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
|
||||
|
||||
The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct directory.
|
||||
|
||||
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
|
||||
|
||||
```nix
|
||||
nativeBuildInputs = [ installShellFiles ];
|
||||
postInstall = ''
|
||||
installManPage doc/foobar.1 doc/barfoo.3
|
||||
# explicit behavior
|
||||
installShellCompletion --bash --name foobar.bash share/completions.bash
|
||||
installShellCompletion --fish --name foobar.fish share/completions.fish
|
||||
installShellCompletion --zsh --name _foobar share/completions.zsh
|
||||
# implicit behavior
|
||||
installShellCompletion share/completions/foobar.{bash,fish,zsh}
|
||||
# using named fd
|
||||
installShellCompletion --cmd foobar \
|
||||
--bash <($out/bin/foobar --bash-completion) \
|
||||
--fish <($out/bin/foobar --fish-completion) \
|
||||
--zsh <($out/bin/foobar --zsh-completion)
|
||||
'';
|
||||
```
|
||||
4
doc/hooks/libiconv.section.md
Normal file
4
doc/hooks/libiconv.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### libiconv, libintl {#libiconv-libintl}
|
||||
|
||||
A few libraries automatically add to `NIX_LDFLAGS` their library, making their symbols automatically available to the linker. This includes libiconv and libintl (gettext). This is done to provide compatibility between GNU Linux, where libiconv and libintl are bundled in, and other systems where that might not be the case. Sometimes, this behavior is not desired. To disable this behavior, set `dontAddExtraLibs`.
|
||||
4
doc/hooks/libxml2.section.md
Normal file
4
doc/hooks/libxml2.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### libxml2 {#setup-hook-libxml2}
|
||||
|
||||
Adds every file named `catalog.xml` found under the `xml/dtd` and `xml/xsl` subdirectories of each build input to the `XML_CATALOG_FILES` environment variable.
|
||||
26
doc/hooks/meson.section.md
Normal file
26
doc/hooks/meson.section.md
Normal file
@@ -0,0 +1,26 @@
|
||||
|
||||
### Meson {#meson}
|
||||
|
||||
Overrides the configure phase to run meson to generate Ninja files. To run these files, you should accompany Meson with ninja. By default, `enableParallelBuilding` is enabled as Meson supports parallel building almost everywhere.
|
||||
|
||||
#### Variables controlling Meson {#variables-controlling-meson}
|
||||
|
||||
##### `mesonFlags` {#mesonflags}
|
||||
|
||||
Controls the flags passed to meson.
|
||||
|
||||
##### `mesonBuildType` {#mesonbuildtype}
|
||||
|
||||
Which [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to pass to Meson. We default to `plain`.
|
||||
|
||||
##### `mesonAutoFeatures` {#mesonautofeatures}
|
||||
|
||||
What value to set [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `enabled`.
|
||||
|
||||
##### `mesonWrapMode` {#mesonwrapmode}
|
||||
|
||||
What value to set [`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `nodownload` as we disallow network access.
|
||||
|
||||
##### `dontUseMesonConfigure` {#dontusemesonconfigure}
|
||||
|
||||
Disables using Meson’s `configurePhase`.
|
||||
4
doc/hooks/ninja.section.md
Normal file
4
doc/hooks/ninja.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### ninja {#ninja}
|
||||
|
||||
Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with the `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.
|
||||
50
doc/hooks/patch-rc-path-hooks.section.md
Normal file
50
doc/hooks/patch-rc-path-hooks.section.md
Normal file
@@ -0,0 +1,50 @@
|
||||
|
||||
# `patchRcPath` hooks {#sec-patchRcPathHooks}
|
||||
|
||||
These hooks provide shell-specific utilities (with the same name as the hook) to patch shell scripts meant to be sourced by software users.
|
||||
|
||||
The typical usage is to patch initialisation or [rc](https://unix.stackexchange.com/questions/3467/what-does-rc-in-bashrc-stand-for) scripts inside `$out/bin` or `$out/etc`.
|
||||
Such scripts, when being sourced, would insert the binary locations of certain commands into `PATH`, modify other environment variables or run a series of start-up commands.
|
||||
When shipped from the upstream, they sometimes use commands that might not be available in the environment they are getting sourced in.
|
||||
|
||||
The compatible shells for each hook are:
|
||||
|
||||
- `patchRcPathBash`: [Bash](https://www.gnu.org/software/bash/), [ksh](http://www.kornshell.org/), [zsh](https://www.zsh.org/) and other shells supporting the Bash-like parameter expansions.
|
||||
- `patchRcPathCsh`: Csh scripts, such as those targeting [tcsh](https://www.tcsh.org/).
|
||||
- `patchRcPathFish`: [Fish](https://fishshell.com/) scripts.
|
||||
- `patchRcPathPosix`: POSIX-conformant shells supporting the limited parameter expansions specified by the POSIX standard. Current implementation uses the parameter expansion `${foo-}` only.
|
||||
|
||||
For each supported shell, it modifies the script with a `PATH` prefix that is later removed when the script ends.
|
||||
It allows nested patching, which guarantees that a patched script may source another patched script.
|
||||
|
||||
Syntax to apply the utility to a script:
|
||||
|
||||
```sh
|
||||
patchRcPath<shell> <file> <PATH-prefix>
|
||||
```
|
||||
|
||||
Example usage:
|
||||
|
||||
Given a package `foo` containing an init script `this-foo.fish` that depends on `coreutils`, `man` and `which`,
|
||||
patch the init script for users to source without having the above dependencies in their `PATH`:
|
||||
|
||||
```nix
|
||||
{ lib, stdenv, patchRcPathFish}:
|
||||
stdenv.mkDerivation {
|
||||
|
||||
# ...
|
||||
|
||||
nativeBuildInputs = [
|
||||
patchRcPathFish
|
||||
];
|
||||
|
||||
postFixup = ''
|
||||
patchRcPathFish $out/bin/this-foo.fish ${lib.makeBinPath [ coreutils man which ]}
|
||||
'';
|
||||
}
|
||||
```
|
||||
|
||||
::: {.note}
|
||||
`patchRcPathCsh` and `patchRcPathPosix` implementation depends on `sed` to do the string processing.
|
||||
The others are in vanilla shell and have no third-party dependencies.
|
||||
:::
|
||||
4
doc/hooks/perl.section.md
Normal file
4
doc/hooks/perl.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### Perl {#setup-hook-perl}
|
||||
|
||||
Adds the `lib/site_perl` subdirectory of each build input to the `PERL5LIB` environment variable. For instance, if `buildInputs` contains Perl, then the `lib/site_perl` subdirectory of each input is added to the `PERL5LIB` environment variable.
|
||||
4
doc/hooks/pkg-config.section.md
Normal file
4
doc/hooks/pkg-config.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### pkg-config {#setup-hook-pkg-config}
|
||||
|
||||
Adds the `lib/pkgconfig` and `share/pkgconfig` subdirectories of each build input to the `PKG_CONFIG_PATH` environment variable.
|
||||
4
doc/hooks/python.section.md
Normal file
4
doc/hooks/python.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### Python {#setup-hook-python}
|
||||
|
||||
Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.
|
||||
4
doc/hooks/qt-4.section.md
Normal file
4
doc/hooks/qt-4.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### Qt 4 {#qt-4}
|
||||
|
||||
Sets the `QTDIR` environment variable to Qt’s path.
|
||||
4
doc/hooks/scons.section.md
Normal file
4
doc/hooks/scons.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### scons {#scons}
|
||||
|
||||
Overrides the build, install, and check phases. This uses the scons build system as a replacement for make. scons does not provide a configure phase, so everything is managed at build and install time.
|
||||
4
doc/hooks/tetex-tex-live.section.md
Normal file
4
doc/hooks/tetex-tex-live.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### teTeX / TeX Live {#tetex-tex-live}
|
||||
|
||||
Adds the `share/texmf-nix` subdirectory of each build input to the `TEXINPUTS` environment variable.
|
||||
4
doc/hooks/unzip.section.md
Normal file
4
doc/hooks/unzip.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### unzip {#unzip}
|
||||
|
||||
This setup hook will allow you to unzip .zip files specified in `$src`. There are many similar packages like `unrar`, `undmg`, etc.
|
||||
4
doc/hooks/validatePkgConfig.section.md
Normal file
4
doc/hooks/validatePkgConfig.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### validatePkgConfig {#validatepkgconfig}
|
||||
|
||||
The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.
|
||||
4
doc/hooks/waf.section.md
Normal file
4
doc/hooks/waf.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### wafHook {#wafhook}
|
||||
|
||||
Overrides the configure, build, and install phases. This will run the “waf” script used by many projects. If `wafPath` (default `./waf`) doesn’t exist, it will copy the version of waf available in Nixpkgs. `wafFlags` can be used to pass flags to the waf script.
|
||||
4
doc/hooks/xcbuild.section.md
Normal file
4
doc/hooks/xcbuild.section.md
Normal file
@@ -0,0 +1,4 @@
|
||||
|
||||
### xcbuildHook {#xcbuildhook}
|
||||
|
||||
Overrides the build and install phases to run the "xcbuild" command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.
|
||||
@@ -52,7 +52,7 @@ agda.withPackages (p: [
|
||||
repo = "agda-stdlib";
|
||||
owner = "agda";
|
||||
rev = "v1.5";
|
||||
sha256 = "16fcb7ssj6kj687a042afaa2gq48rc8abihpm14k684ncihb2k4w";
|
||||
hash = "sha256-nEyxYGSWIDNJqBfGpRDLiOAnlHJKEKAOMnIaqfVZzJk=";
|
||||
};
|
||||
}))
|
||||
])
|
||||
@@ -83,7 +83,7 @@ agda.withPackages (p: [
|
||||
owner = "owner";
|
||||
version = "...";
|
||||
rev = "...";
|
||||
sha256 = "...";
|
||||
hash = "...";
|
||||
};
|
||||
})
|
||||
])
|
||||
|
||||
@@ -115,7 +115,7 @@ If there are git depencencies.
|
||||
owner = "elixir-libraries";
|
||||
repo = "prometheus.ex";
|
||||
rev = "a4e9beb3c1c479d14b352fd9d6dd7b1f6d7deee5";
|
||||
sha256 = "1v0q4bi7sb253i8q016l7gwlv5562wk5zy3l2sa446csvsacnpjk";
|
||||
hash = "sha256-U17LlN6aGUKUFnT4XyYXppRN+TvUBIBRHEUsfeIiGOw=";
|
||||
};
|
||||
# you can re-use the same beamDeps argument as generated
|
||||
beamDeps = with final; [ prometheus ];
|
||||
@@ -124,7 +124,7 @@ If there are git depencencies.
|
||||
};
|
||||
```
|
||||
|
||||
You will need to run the build process once to fix the sha256 to correspond to your new git src.
|
||||
You will need to run the build process once to fix the hash to correspond to your new git src.
|
||||
|
||||
###### FOD {#fixed-output-derivation}
|
||||
|
||||
@@ -138,13 +138,13 @@ Practical steps
|
||||
mixFodDeps = fetchMixDeps {
|
||||
pname = "mix-deps-${pname}";
|
||||
inherit src version;
|
||||
sha256 = lib.fakeSha256;
|
||||
hash = lib.fakeHash;
|
||||
};
|
||||
```
|
||||
|
||||
The first build will complain about the sha256 value, you can replace with the suggested value after that.
|
||||
The first build will complain about the hash value, you can replace with the suggested value after that.
|
||||
|
||||
Note that if after you've replaced the value, nix suggests another sha256, then mix is not fetching the dependencies reproducibly. An FOD will not work in that case and you will have to use mix2nix.
|
||||
Note that if after you've replaced the value, nix suggests another hash, then mix is not fetching the dependencies reproducibly. An FOD will not work in that case and you will have to use mix2nix.
|
||||
|
||||
##### mixRelease - example {#mix-release-example}
|
||||
|
||||
@@ -170,7 +170,7 @@ let
|
||||
pname = "mix-deps-${pname}";
|
||||
inherit src version;
|
||||
# nix will complain and tell you the right value to replace this with
|
||||
sha256 = lib.fakeSha256;
|
||||
hash = lib.fakeHash;
|
||||
# if you have build time environment variables add them here
|
||||
MY_ENV_VAR="my_value";
|
||||
};
|
||||
@@ -282,7 +282,7 @@ mkShell {
|
||||
|
||||
### Using an overlay
|
||||
|
||||
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `sha256`) and then use this overlay in your development environment:
|
||||
If you need to use an overlay to change some attributes of a derivation, e.g. if you need a bugfix from a version that is not yet available in nixpkgs, you can override attributes such as `version` (and the corresponding `hash`) and then use this overlay in your development environment:
|
||||
|
||||
#### `shell.nix`
|
||||
|
||||
@@ -291,7 +291,7 @@ let
|
||||
elixir_1_13_1_overlay = (self: super: {
|
||||
elixir_1_13 = super.elixir_1_13.override {
|
||||
version = "1.13.1";
|
||||
sha256 = "0z0b1w2vvw4vsnb99779c2jgn9bgslg7b1pmd9vlbv02nza9qj5p";
|
||||
sha256 = "sha256-t0ic1LcC7EV3avWGdR7VbyX7pGDpnJSW1ZvwvQUPC3w=";
|
||||
};
|
||||
});
|
||||
pkgs = import <nixpkgs> { overlays = [ elixir_1_13_1_overlay ]; };
|
||||
|
||||
@@ -24,7 +24,7 @@ The recommended way of defining a derivation for a Coq library, is to use the `c
|
||||
* if it is a string of the form `"#N"`, and the domain is github, then it tries to download the current head of the pull request `#N` from github,
|
||||
* `defaultVersion` (optional). Coq libraries may be compatible with some specific versions of Coq only. The `defaultVersion` attribute is used when no `version` is provided (or if `version = null`) to select the version of the library to use by default, depending on the context. This selection will mainly depend on a `coq` version number but also possibly on other packages versions (e.g. `mathcomp`). If its value ends up to be `null`, the package is marked for removal in end-user `coqPackages` attribute set.
|
||||
* `release` (optional, defaults to `{}`), lists all the known releases of the library and for each of them provides an attribute set with at least a `sha256` attribute (you may put the empty string `""` in order to automatically insert a fake sha256, this will trigger an error which will allow you to find the correct sha256), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
|
||||
* `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `sha256` and returns an attribute set with a `version` and `src`.
|
||||
* `fetcher` (optional, defaults to a generic fetching mechanism supporting github or gitlab based infrastructures), is a function that takes at least an `owner`, a `repo`, a `rev`, and a `hash` and returns an attribute set with a `version` and `src`.
|
||||
* `repo` (optional, defaults to the value of `pname`),
|
||||
* `owner` (optional, defaults to `"coq-community"`).
|
||||
* `domain` (optional, defaults to `"github.com"`), domains including the strings `"github"` or `"gitlab"` in their names are automatically supported, otherwise, one must change the `fetcher` argument to support them (cf `pkgs/development/coq-modules/heq/default.nix` for an example),
|
||||
|
||||
@@ -27,7 +27,7 @@ crystal.buildCrystalPackage rec {
|
||||
owner = "mint-lang";
|
||||
repo = "mint";
|
||||
rev = version;
|
||||
sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
|
||||
hash = "sha256-dFN9l5fgrM/TtOPqlQvUYgixE4KPr629aBmkwdDoq28=";
|
||||
};
|
||||
|
||||
# Insert the path to your shards.nix file here
|
||||
@@ -62,7 +62,7 @@ crystal.buildCrystalPackage rec {
|
||||
owner = "mint-lang";
|
||||
repo = "mint";
|
||||
rev = version;
|
||||
sha256 = "0vxbx38c390rd2ysvbwgh89v2232sh5rbsp3nk9wzb70jybpslvl";
|
||||
hash = "sha256-dFN9l5fgrM/TtOPqlQvUYgixE4KPr629aBmkwdDoq28=";
|
||||
};
|
||||
|
||||
shardsFile = ./shards.nix;
|
||||
|
||||
@@ -32,3 +32,22 @@ mypkg = let
|
||||
}});
|
||||
in callPackage { inherit cudaPackages; };
|
||||
```
|
||||
|
||||
The CUDA NVCC compiler requires flags to determine which hardware you
|
||||
want to target for in terms of SASS (real hardware) or PTX (JIT kernels).
|
||||
|
||||
Nixpkgs tries to target support real architecture defaults based on the
|
||||
CUDA toolkit version with PTX support for future hardware. Experienced
|
||||
users may optmize this configuration for a variety of reasons such as
|
||||
reducing binary size and compile time, supporting legacy hardware, or
|
||||
optimizing for specific hardware.
|
||||
|
||||
You may provide capabilities to add support or reduce binary size through
|
||||
`config` using `cudaCapabilities = [ "6.0" "7.0" ];` and
|
||||
`cudaForwardCompat = true;` if you want PTX support for future hardware.
|
||||
|
||||
Please consult [GPUs supported](https://en.wikipedia.org/wiki/CUDA#GPUs_supported)
|
||||
for your specific card(s).
|
||||
|
||||
Library maintainers should consult [NVCC Docs](https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/)
|
||||
and release notes for their software package.
|
||||
|
||||
93
doc/languages-frameworks/cuelang.section.md
Normal file
93
doc/languages-frameworks/cuelang.section.md
Normal file
@@ -0,0 +1,93 @@
|
||||
# Cue (Cuelang) {#cuelang}
|
||||
|
||||
[Cuelang](https://cuelang.org/) is a language to:
|
||||
|
||||
- describe schemas and validate backward-compatibility
|
||||
- generate code and schemas in various formats (e.g. JSON Schema, OpenAPI)
|
||||
- do configuration akin to [Dhall Lang](https://dhall-lang.org/)
|
||||
- perform data validation
|
||||
|
||||
## Cuelang schema quick start
|
||||
|
||||
Cuelang schemas are similar to JSON, here is a quick cheatsheet:
|
||||
|
||||
- Default types includes: `null`, `string`, `bool`, `bytes`, `number`, `int`, `float`, lists as `[...T]` where `T` is a type.
|
||||
- All structures, defined by: `myStructName: { <fields> }` are **open** -- they accept fields which are not specified.
|
||||
- Closed structures can be built by doing `myStructName: close({ <fields> })` -- they are strict in what they accept.
|
||||
- `#X` are **definitions**, referenced definitions are **recursively closed**, i.e. all its children structures are **closed**.
|
||||
- `&` operator is the [unification operator](https://cuelang.org/docs/references/spec/#unification) (similar to a type-level merging operator), `|` is the [disjunction operator](https://cuelang.org/docs/references/spec/#disjunction) (similar to a type-level union operator).
|
||||
- Values **are** types, i.e. `myStruct: { a: 3 }` is a valid type definition that only allows `3` as value.
|
||||
|
||||
- Read <https://cuelang.org/docs/concepts/logic/> to learn more about the semantics.
|
||||
- Read <https://cuelang.org/docs/references/spec/> to learn about the language specification.
|
||||
|
||||
## `writeCueValidator`
|
||||
|
||||
Nixpkgs provides a `pkgs.writeCueValidator` helper, which will write a validation script based on the provided Cuelang schema.
|
||||
|
||||
Here is an example:
|
||||
```
|
||||
pkgs.writeCueValidator
|
||||
(pkgs.writeText "schema.cue" ''
|
||||
#Def1: {
|
||||
field1: string
|
||||
}
|
||||
'')
|
||||
{ document = "#Def1"; }
|
||||
```
|
||||
|
||||
- The first parameter is the Cue schema file.
|
||||
- The second paramter is an options parameter, currently, only: `document` can be passed.
|
||||
|
||||
`document` : match your input data against this fragment of structure or definition, e.g. you may use the same schema file but differents documents based on the data you are validating.
|
||||
|
||||
Another example, given the following `validator.nix` :
|
||||
```
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
let
|
||||
genericValidator = version:
|
||||
pkgs.writeCueValidator
|
||||
(pkgs.writeText "schema.cue" ''
|
||||
#Version1: {
|
||||
field1: string
|
||||
}
|
||||
#Version2: #Version1 & {
|
||||
field1: "unused"
|
||||
}''
|
||||
)
|
||||
{ document = "#Version${toString version}"; };
|
||||
in
|
||||
{
|
||||
validateV1 = genericValidator 1;
|
||||
validateV2 = genericValidator 2;
|
||||
}
|
||||
```
|
||||
|
||||
The result is a script that will validate the file you pass as the first argument against the schema you provided `writeCueValidator`.
|
||||
|
||||
It can be any format that `cue vet` supports, i.e. YAML or JSON for example.
|
||||
|
||||
Here is an example, named `example.json`, given the following JSON:
|
||||
```
|
||||
{ "field1": "abc" }
|
||||
```
|
||||
|
||||
You can run the result script (named `validate`) as the following:
|
||||
|
||||
```console
|
||||
$ nix-build validator.nix
|
||||
$ ./result example.json
|
||||
$ ./result-2 example.json
|
||||
field1: conflicting values "unused" and "abc":
|
||||
./example.json:1:13
|
||||
../../../../../../nix/store/v64dzx3vr3glpk0cq4hzmh450lrwh6sg-schema.cue:5:11
|
||||
$ sed -i 's/"abc"/3/' example.json
|
||||
$ ./result example.json
|
||||
field1: conflicting values 3 and string (mismatched types int and string):
|
||||
./example.json:1:13
|
||||
../../../../../../nix/store/v64dzx3vr3glpk0cq4hzmh450lrwh6sg-schema.cue:5:11
|
||||
```
|
||||
|
||||
**Known limitations**
|
||||
|
||||
* The script will enforce **concrete** values and will not accept lossy transformations (strictness). You can add these options if you need them.
|
||||
@@ -91,7 +91,7 @@ buildDhallPackage {
|
||||
let
|
||||
nixpkgs = builtins.fetchTarball {
|
||||
url = "https://github.com/NixOS/nixpkgs/archive/94b2848559b12a8ed1fe433084686b2a81123c99.tar.gz";
|
||||
sha256 = "1pbl4c2dsaz2lximgd31m96jwbps6apn3anx8cvvhk1gl9rkg107";
|
||||
sha256 = "sha256-B4Q3c6IvTLg3Q92qYa8y+i4uTaphtFdjp+Ir3QQjdN0=";
|
||||
};
|
||||
|
||||
dhallOverlay = self: super: {
|
||||
@@ -295,7 +295,7 @@ terms of `buildDhallPackage` that accepts the following arguments:
|
||||
* `document`: Set to `true` to generate documentation for the package
|
||||
|
||||
Additionally, `buildDhallGitHubPackage` accepts the same arguments as
|
||||
`fetchFromGitHub`, such as `sha256` or `fetchSubmodules`.
|
||||
`fetchFromGitHub`, such as `hash` or `fetchSubmodules`.
|
||||
|
||||
## `dhall-to-nixpkgs` {#ssec-dhall-dhall-to-nixpkgs}
|
||||
|
||||
@@ -316,7 +316,7 @@ $ dhall-to-nixpkgs github https://github.com/Gabriel439/dhall-semver.git
|
||||
repo = "dhall-semver";
|
||||
rev = "2d44ae605302ce5dc6c657a1216887fbb96392a4";
|
||||
fetchSubmodules = false;
|
||||
sha256 = "0y8shvp8srzbjjpmnsvz9c12ciihnx1szs0yzyi9ashmrjvd0jcz";
|
||||
hash = "sha256-n0nQtswVapWi/x7or0O3MEYmAkt/a1uvlOtnje6GGnk=";
|
||||
directory = "";
|
||||
file = "package.dhall";
|
||||
source = false;
|
||||
|
||||
@@ -121,7 +121,7 @@ This `xmlmirror` example features a emscriptenPackage which is defined completel
|
||||
src = pkgs.fetchgit {
|
||||
url = "https://gitlab.com/odfplugfest/xmlmirror.git";
|
||||
rev = "4fd7e86f7c9526b8f4c1733e5c8b45175860a8fd";
|
||||
sha256 = "1jasdqnbdnb83wbcnyrp32f36w3xwhwp0wq8lwwmhqagxrij1r4b";
|
||||
hash = "sha256-i+QgY+5PYVg5pwhzcDnkfXAznBg3e8sWH2jZtixuWsk=";
|
||||
};
|
||||
|
||||
configurePhase = ''
|
||||
|
||||
@@ -11,7 +11,13 @@ The function `buildGoModule` builds Go programs managed with Go modules. It buil
|
||||
|
||||
In the following is an example expression using `buildGoModule`, the following arguments are of special significance to the function:
|
||||
|
||||
- `vendorHash`: is the hash of the output of the intermediate fetcher derivation. `vendorHash` can also take `null` as an input. When `null` is used as a value, rather than fetching the dependencies and vendoring them, we use the vendoring included within the source repo. If you'd like to not have to update this field on dependency changes, run `go mod vendor` in your source repo and set `vendorHash = null;`
|
||||
- `vendorHash`: is the hash of the output of the intermediate fetcher derivation.
|
||||
|
||||
`vendorHash` can also be set to `null`.
|
||||
In that case, rather than fetching the dependencies and vendoring them, the dependencies vendored in the source repo will be used.
|
||||
|
||||
To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`
|
||||
To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).
|
||||
- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.
|
||||
|
||||
```nix
|
||||
@@ -23,7 +29,7 @@ pet = buildGoModule rec {
|
||||
owner = "knqyf263";
|
||||
repo = "pet";
|
||||
rev = "v${version}";
|
||||
sha256 = "0m2fzpqxk7hrbxsgqplkg7h2p7gv6s1miymv3gvw0cz039skag0s";
|
||||
hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
|
||||
};
|
||||
|
||||
vendorHash = "sha256-ciBIR+a1oaYH+H1PcC8cD8ncfJczk1IiJ8iYNM+R6aA=";
|
||||
@@ -59,7 +65,7 @@ deis = buildGoPackage rec {
|
||||
owner = "deis";
|
||||
repo = "deis";
|
||||
rev = "v${version}";
|
||||
sha256 = "1qv9lxqx7m18029lj8cw3k7jngvxs4iciwrypdy0gd2nnghc68sw";
|
||||
hash = "sha256-XCPD4LNWtAd8uz7zyCLRfT8rzxycIUmTACjU03GnaeM=";
|
||||
};
|
||||
|
||||
goDeps = ./deps.nix;
|
||||
@@ -76,11 +82,11 @@ The `goDeps` attribute can be imported from a separate `nix` file that defines w
|
||||
goPackagePath = "gopkg.in/yaml.v2";
|
||||
fetch = {
|
||||
# `fetch type` that needs to be used to get package source.
|
||||
# If `git` is used there should be `url`, `rev` and `sha256` defined next to it.
|
||||
# If `git` is used there should be `url`, `rev` and `hash` defined next to it.
|
||||
type = "git";
|
||||
url = "https://gopkg.in/yaml.v2";
|
||||
rev = "a83829b6f1293c91addabc89d0571c246397bbf4";
|
||||
sha256 = "1m4dsmk90sbi17571h6pld44zxz7jc4lrnl4f27dpd1l8g5xvjhh";
|
||||
hash = "sha256-EMrdy0M0tNuOcITaTAmT5/dPSKPXwHDKCXFpkGbVjdQ=";
|
||||
};
|
||||
}
|
||||
{
|
||||
@@ -89,7 +95,7 @@ The `goDeps` attribute can be imported from a separate `nix` file that defines w
|
||||
type = "git";
|
||||
url = "https://github.com/docopt/docopt-go";
|
||||
rev = "784ddc588536785e7299f7272f39101f7faccc3f";
|
||||
sha256 = "0wwz48jl9fvl1iknvn9dqr4gfy1qs03gxaikrxxp9gry6773v3sj";
|
||||
hash = "sha256-Uo89zjE+v3R7zzOq/gbQOHj3SMYt2W1nDHS7RCUin3M=";
|
||||
};
|
||||
}
|
||||
]
|
||||
|
||||
@@ -90,7 +90,7 @@ build-idris-package {
|
||||
owner = "Heather";
|
||||
repo = "Idris.Yaml";
|
||||
rev = "5afa51ffc839844862b8316faba3bafa15656db4";
|
||||
sha256 = "1g4pi0swmg214kndj85hj50ccmckni7piprsxfdzdfhg87s0avw7";
|
||||
hash = "sha256-h28F9EEPuvab6zrfeE+0k1XGQJGwINnsJEG8yjWIl7w=";
|
||||
};
|
||||
|
||||
meta = with lib; {
|
||||
|
||||
@@ -13,6 +13,7 @@
|
||||
<xi:include href="coq.section.xml" />
|
||||
<xi:include href="crystal.section.xml" />
|
||||
<xi:include href="cuda.section.xml" />
|
||||
<xi:include href="cuelang.section.xml" />
|
||||
<xi:include href="dhall.section.xml" />
|
||||
<xi:include href="dotnet.section.xml" />
|
||||
<xi:include href="emscripten.section.xml" />
|
||||
|
||||
@@ -157,6 +157,61 @@ git config --global url."https://github.com/".insteadOf git://github.com/
|
||||
|
||||
## Tool specific instructions {#javascript-tool-specific}
|
||||
|
||||
### buildNpmPackage {#javascript-buildNpmPackage}
|
||||
|
||||
`buildNpmPackage` allows you to package npm-based projects in Nixpkgs without the use of an auto-generated dependencies file (as used in [node2nix](#javascript-node2nix)). It works by utilizing npm's cache functionality -- creating a reproducible cache that contains the dependencies of a project, and pointing npm to it.
|
||||
|
||||
```nix
|
||||
{ lib, buildNpmPackage, fetchFromGitHub }:
|
||||
|
||||
buildNpmPackage rec {
|
||||
pname = "flood";
|
||||
version = "4.7.0";
|
||||
|
||||
src = fetchFromGitHub {
|
||||
owner = "jesec";
|
||||
repo = pname;
|
||||
rev = "v${version}";
|
||||
hash = "sha256-BR+ZGkBBfd0dSQqAvujsbgsEPFYw/ThrylxUbOksYxM=";
|
||||
};
|
||||
|
||||
patches = [ ./remove-prepack-script.patch ];
|
||||
|
||||
npmDepsHash = "sha256-tuEfyePwlOy2/mOPdXbqJskO6IowvAP4DWg8xSZwbJw=";
|
||||
|
||||
NODE_OPTIONS = "--openssl-legacy-provider";
|
||||
|
||||
meta = with lib; {
|
||||
description = "A modern web UI for various torrent clients with a Node.js backend and React frontend";
|
||||
homepage = "https://flood.js.org";
|
||||
license = licenses.gpl3Only;
|
||||
maintainers = with maintainers; [ winter ];
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
#### Arguments {#javascript-buildNpmPackage-arguments}
|
||||
|
||||
* `npmDepsHash`: The output hash of the dependencies for this project. Can be calculated in advance with [`prefetch-npm-deps`](#javascript-buildNpmPackage-prefetch-npm-deps).
|
||||
* `makeCacheWritable`: Whether to make the cache writable prior to installing dependencies. Don't set this unless npm tries to write to the cache directory, as it can slow down the build.
|
||||
* `npmBuildScript`: The script to run to build the project. Defaults to `"build"`.
|
||||
* `npmFlags`: Flags to pass to all npm commands.
|
||||
* `npmInstallFlags`: Flags to pass to `npm ci` and `npm prune`.
|
||||
* `npmBuildFlags`: Flags to pass to `npm run ${npmBuildScript}`.
|
||||
* `npmPackFlags`: Flags to pass to `npm pack`.
|
||||
|
||||
#### prefetch-npm-deps {#javascript-buildNpmPackage-prefetch-npm-deps}
|
||||
|
||||
`prefetch-npm-deps` can calculate the hash of the dependencies of an npm project ahead of time.
|
||||
|
||||
```console
|
||||
$ ls
|
||||
package.json package-lock.json index.js
|
||||
$ prefetch-npm-deps package-lock.json
|
||||
...
|
||||
sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
|
||||
```
|
||||
|
||||
### node2nix {#javascript-node2nix}
|
||||
|
||||
#### Preparation {#javascript-node2nix-preparation}
|
||||
@@ -187,7 +242,7 @@ If the downloaded files contain the `package.json` and `yarn.lock` files they ca
|
||||
```nix
|
||||
offlineCache = fetchYarnDeps {
|
||||
yarnLock = src + "/yarn.lock";
|
||||
sha256 = "....";
|
||||
hash = "....";
|
||||
};
|
||||
```
|
||||
|
||||
@@ -275,13 +330,16 @@ mkYarnPackage rec {
|
||||
- The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>
|
||||
- Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>
|
||||
|
||||
## Outside of nixpkgs {#javascript-outside-nixpkgs}
|
||||
## Outside Nixpkgs {#javascript-outside-nixpkgs}
|
||||
|
||||
There are some other options available that can't be used inside nixpkgs. Those other options are written in Nix. Importing them in nixpkgs will require moving the source code into nixpkgs. Using [Import From Derivation](https://nixos.wiki/wiki/Import_From_Derivation) is not allowed in Hydra at present. If you are packaging something outside nixpkgs, those can be considered
|
||||
There are some other tools available, which are written in the Nix language.
|
||||
These that can't be used inside Nixpkgs because they require [Import From Derivation](#ssec-import-from-derivation), which is not allowed in Nixpkgs.
|
||||
|
||||
If you are packaging something outside Nixpkgs, consider the following:
|
||||
|
||||
### npmlock2nix {#javascript-npmlock2nix}
|
||||
|
||||
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might be subject to change.
|
||||
[npmlock2nix](https://github.com/nix-community/npmlock2nix) aims at building `node_modules` without code generation. It hasn't reached v1 yet, the API might be subject to change.
|
||||
|
||||
#### Pitfalls {#javascript-npmlock2nix-pitfalls}
|
||||
|
||||
@@ -289,7 +347,7 @@ There are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issue
|
||||
|
||||
### nix-npm-buildpackage {#javascript-nix-npm-buildpackage}
|
||||
|
||||
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building node_modules without code generation. It hasn't reached v1 yet, the API might change. It supports both package-lock.json and yarn.lock.
|
||||
[nix-npm-buildpackage](https://github.com/serokell/nix-npm-buildpackage) aims at building `node_modules` without code generation. It hasn't reached v1 yet, the API might change. It supports both `package-lock.json` and yarn.lock.
|
||||
|
||||
#### Pitfalls {#javascript-nix-npm-buildpackage-pitfalls}
|
||||
|
||||
|
||||
@@ -183,7 +183,7 @@ luaposix = buildLuarocksPackage {
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://raw.githubusercontent.com/rocks-moonscript-org/moonrocks-mirror/master/luaposix-34.0.4-1.src.rock";
|
||||
sha256 = "0yrm5cn2iyd0zjd4liyj27srphvy0gjrjx572swar6zqr4dwjqp2";
|
||||
hash = "sha256-4mLJG8n4m6y4Fqd0meUDfsOb9RHSR0qa/KD5KCwrNXs=";
|
||||
};
|
||||
disabled = (luaOlder "5.1") || (luaAtLeast "5.4");
|
||||
propagatedBuildInputs = [ bit32 lua std_normalize ];
|
||||
@@ -200,7 +200,7 @@ luaposix = buildLuarocksPackage {
|
||||
The `buildLuarocksPackage` delegates most tasks to luarocks:
|
||||
|
||||
* it adds `luarocks` as an unpacker for `src.rock` files (zip files really).
|
||||
* configurePhase` writes a temporary luarocks configuration file which location
|
||||
* `configurePhase` writes a temporary luarocks configuration file which location
|
||||
is exported via the environment variable `LUAROCKS_CONFIG`.
|
||||
* the `buildPhase` does nothing.
|
||||
* `installPhase` calls `luarocks make --deps-mode=none --tree $out` to build and
|
||||
|
||||
@@ -25,7 +25,7 @@ nimPackages.buildNimPackage rec {
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://git.sr.ht/~ehmry/hottext/archive/v${version}.tar.gz";
|
||||
sha256 = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
|
||||
hash = "sha256-hIUofi81zowSMbt1lUsxCnVzfJGN3FEiTtN8CEFpwzY=";
|
||||
};
|
||||
|
||||
buildInputs = with nimPackages; [
|
||||
@@ -65,7 +65,7 @@ buildNimPackage rec {
|
||||
version = "2.0.4";
|
||||
src = fetchNimble {
|
||||
inherit pname version;
|
||||
hash = "sha256-Vtcj8goI4zZPQs2TbFoBFlcR5UqDtOldaXSH/+/xULk=";
|
||||
hash = "sha256-qDtVSnf+7rTq36WAxgsUZ8XoUk4sKwHyt8EJcY5WP+o=";
|
||||
};
|
||||
propagatedBuildInputs = [ SDL2 ];
|
||||
}
|
||||
|
||||
@@ -79,7 +79,7 @@ buildDunePackage rec {
|
||||
owner = "inhabitedtype";
|
||||
repo = pname;
|
||||
rev = version;
|
||||
sha256 = "1hmrkdcdlkwy7rxhngf3cv3sa61cznnd9p5lmqhx20664gx2ibrh";
|
||||
hash = "sha256-MK8o+iPGANEhrrTc1Kz9LBilx2bDPQt7Pp5P2libucI=";
|
||||
};
|
||||
|
||||
checkInputs = [ alcotest ppx_let ];
|
||||
@@ -110,7 +110,7 @@ buildDunePackage rec {
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://github.com/flowtype/ocaml-${pname}/releases/download/v${version}/${pname}-v${version}.tbz";
|
||||
sha256 = "09ygcxxd5warkdzz17rgpidrd0pg14cy2svvnvy1hna080lzg7vp";
|
||||
hash = "sha256-d5/3KUBAWRj8tntr4RkJ74KWW7wvn/B/m1nx0npnzyc=";
|
||||
};
|
||||
|
||||
meta = with lib; {
|
||||
|
||||
@@ -39,7 +39,7 @@ ClassC3 = buildPerlPackage rec {
|
||||
version = "0.21";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/F/FL/FLORA/${pname}-${version}.tar.gz";
|
||||
sha256 = "1bl8z095y4js66pwxnm7s853pi9czala4sqc743fdlnk27kq94gz";
|
||||
hash = "sha256-/5GE5xHT0uYGOQxroqj6LMU7CtKn2s6vMVoSXxL4iK4=";
|
||||
};
|
||||
};
|
||||
```
|
||||
@@ -78,7 +78,7 @@ buildPerlPackage rec {
|
||||
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/P/PM/PMQS/${pname}-${version}.tar.gz";
|
||||
sha256 = "07xf50riarb60l1h6m2dqmql8q5dij619712fsgw7ach04d8g3z1";
|
||||
hash = "sha256-4Y+HGgGQqcOfdiKcFIyMrWBEccVNVAMDBWZlFTMorh8=";
|
||||
};
|
||||
|
||||
preConfigure = ''
|
||||
@@ -96,7 +96,7 @@ ClassC3Componentised = buildPerlPackage rec {
|
||||
version = "1.0004";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/A/AS/ASH/${pname}-${version}.tar.gz";
|
||||
sha256 = "0xql73jkcdbq4q9m0b0rnca6nrlvf5hyzy8is0crdk65bynvs8q1";
|
||||
hash = "sha256-ASO9rV/FzJYZ0BH572Fxm2ZrFLMZLFATJng1NuU4FHc=";
|
||||
};
|
||||
propagatedBuildInputs = [
|
||||
ClassC3 ClassInspector TestException MROCompat
|
||||
@@ -111,11 +111,11 @@ On Darwin, if a script has too many `-Idir` flags in its first line (its “sheb
|
||||
|
||||
ImageExifTool = buildPerlPackage {
|
||||
pname = "Image-ExifTool";
|
||||
version = "11.50";
|
||||
version = "12.50";
|
||||
|
||||
src = fetchurl {
|
||||
url = "https://www.sno.phy.queensu.ca/~phil/exiftool/${pname}-${version}.tar.gz";
|
||||
sha256 = "0d8v48y94z8maxkmw1rv7v9m0jg2dc8xbp581njb6yhr7abwqdv3";
|
||||
url = "https://exiftool.org/${pname}-${version}.tar.gz";
|
||||
hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
|
||||
};
|
||||
|
||||
buildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
|
||||
@@ -146,7 +146,7 @@ $ nix-generate-from-cpan XML::Simple
|
||||
version = "2.22";
|
||||
src = fetchurl {
|
||||
url = "mirror://cpan/authors/id/G/GR/GRANTM/XML-Simple-2.22.tar.gz";
|
||||
sha256 = "b9450ef22ea9644ae5d6ada086dc4300fa105be050a2030ebd4efd28c198eb49";
|
||||
hash = "sha256-uUUO8i6pZErl1q2ghtxDAPoQW+BQogMOvU79KMGY60k=";
|
||||
};
|
||||
propagatedBuildInputs = [ XMLNamespaceSupport XMLSAX XMLSAXExpat ];
|
||||
meta = {
|
||||
|
||||
@@ -356,7 +356,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
|
||||
hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
|
||||
};
|
||||
|
||||
doCheck = false;
|
||||
@@ -401,7 +401,7 @@ with import <nixpkgs> {};
|
||||
|
||||
src = python39.pkgs.fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
|
||||
hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
|
||||
};
|
||||
|
||||
doCheck = false;
|
||||
@@ -450,7 +450,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "14b2ef766d4c9652ab813182e866f493475e65e558bed0822e38bf07bba1a278";
|
||||
hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
|
||||
};
|
||||
|
||||
checkInputs = [ pytest ];
|
||||
@@ -484,7 +484,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "16a0fa97hym9ysdk3rmqz32xdjqmy4w34ld3rm3jf5viqjx65lxk";
|
||||
hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
|
||||
};
|
||||
|
||||
buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
|
||||
@@ -517,7 +517,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "f6bbb6afa93085409ab24885a1a3cdb8909f095a142f4d49e346f2bd1b789074";
|
||||
hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
|
||||
};
|
||||
|
||||
buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
|
||||
@@ -789,7 +789,7 @@ documentation source root.
|
||||
```
|
||||
|
||||
The hook is also available to packages outside the python ecosystem by
|
||||
referencing it using `python3.pkgs.sphinxHook`.
|
||||
referencing it using `sphinxHook` from top-level.
|
||||
|
||||
### Develop local package {#develop-local-package}
|
||||
|
||||
@@ -855,7 +855,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "08fdd5ef7c96480ad11c12d472de21acd32359996f69a5259299b540feba4560";
|
||||
hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
|
||||
};
|
||||
|
||||
meta = with lib; {
|
||||
@@ -988,7 +988,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "cf8436dc59d8695346fcd3ab296de46425ecab00d64096cebe79fb51ecb2eb93";
|
||||
hash = "sha256-z4Q23FnYaVNG/NOrKW3kZCXsqwDWQJbOvnn7Ueyy65M=";
|
||||
};
|
||||
|
||||
postPatch = ''
|
||||
@@ -1098,7 +1098,7 @@ with import <nixpkgs> {};
|
||||
src = super.fetchPypi {
|
||||
pname = "pandas";
|
||||
inherit version;
|
||||
sha256 = "08blshqj9zj1wyjhhw3kl2vas75vhhicvv72flvf1z3jvapgw295";
|
||||
hash = "sha256-JQn+rtpy/OA2deLszSKEuxyttqBzcAil50H+JDHUdCE=";
|
||||
};
|
||||
});
|
||||
};
|
||||
@@ -1158,7 +1158,7 @@ python3.pkgs.buildPythonApplication rec {
|
||||
|
||||
src = python3.pkgs.fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "035w8gqql36zlan0xjrzz9j4lh9hs0qrsgnbyw07qs7lnkvbdv9x";
|
||||
hash = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
|
||||
};
|
||||
|
||||
propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
|
||||
@@ -1670,13 +1670,13 @@ If you need to change a package's attribute(s) from `configuration.nix` you coul
|
||||
|
||||
```nix
|
||||
nixpkgs.config.packageOverrides = super: {
|
||||
python = super.python.override {
|
||||
python3 = super.python3.override {
|
||||
packageOverrides = python-self: python-super: {
|
||||
twisted = python-super.twisted.overrideAttrs (oldAttrs: {
|
||||
twisted = python-super.twisted.overridePythonAttrs (oldAttrs: {
|
||||
src = super.fetchPypi {
|
||||
pname = "twisted";
|
||||
pname = "Twisted";
|
||||
version = "19.10.0";
|
||||
sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
|
||||
hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
|
||||
extension = "tar.bz2";
|
||||
};
|
||||
});
|
||||
@@ -1712,9 +1712,9 @@ self: super: {
|
||||
packageOverrides = python-self: python-super: {
|
||||
twisted = python-super.twisted.overrideAttrs (oldAttrs: {
|
||||
src = super.fetchPypi {
|
||||
pname = "twisted";
|
||||
pname = "Twisted";
|
||||
version = "19.10.0";
|
||||
sha256 = "7394ba7f272ae722a74f3d969dcf599bc4ef093bc392038748a490f1724a515d";
|
||||
hash = "sha256-c5S6fycq5yKnTz2Wnc9Zm8TvCTvDkgOHSKSQ8XJKUV0=";
|
||||
extension = "tar.bz2";
|
||||
};
|
||||
});
|
||||
|
||||
@@ -15,7 +15,7 @@ For other versions such as daily builds (beta and nightly),
|
||||
use either `rustup` from nixpkgs (which will manage the rust installation in your home directory),
|
||||
or use a community maintained [Rust overlay](#using-community-rust-overlays).
|
||||
|
||||
## Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
|
||||
## `buildRustPackage`: Compiling Rust applications with Cargo {#compiling-rust-applications-with-cargo}
|
||||
|
||||
Rust applications are packaged by using the `buildRustPackage` helper from `rustPlatform`:
|
||||
|
||||
@@ -30,10 +30,10 @@ rustPlatform.buildRustPackage rec {
|
||||
owner = "BurntSushi";
|
||||
repo = pname;
|
||||
rev = version;
|
||||
sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
|
||||
hash = "sha256-+s5RBC3XSgb8omTbUNLywZnP6jSxZBKSS1BmXOjRF8M=";
|
||||
};
|
||||
|
||||
cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
|
||||
cargoHash = "sha256-jtBw4ahSl88L0iuCXxQgZVm1EcboWRJMNtjxLVTtzts=";
|
||||
|
||||
meta = with lib; {
|
||||
description = "A fast line-oriented regex search tool, similar to ag and ack";
|
||||
@@ -97,10 +97,10 @@ rustPlatform.buildRustPackage rec {
|
||||
|
||||
src = fetchCrate {
|
||||
inherit pname version;
|
||||
sha256 = "1mqaynrqaas82f5957lx31x80v74zwmwmjxxlbywajb61vh00d38";
|
||||
sha256 = "sha256-aDQA4A5mScX9or3Lyiv/5GyAehidnpKKE0grhbP1Ctc=";
|
||||
};
|
||||
|
||||
cargoHash = "sha256-JmBZcDVYJaK1cK05cxx5BrnGWp4t8ca6FLUbvIot67s=";
|
||||
cargoHash = "sha256-tbrTbutUs5aPSV+yE0IBUZAAytgmZV7Eqxia7g+9zRs=";
|
||||
cargoDepsName = pname;
|
||||
|
||||
# ...
|
||||
@@ -319,6 +319,32 @@ The above are just guidelines, and exceptions may be granted on a case-by-case b
|
||||
However, please check if it's possible to disable a problematic subset of the
|
||||
test suite and leave a comment explaining your reasoning.
|
||||
|
||||
This can be achived with `--skip` in `checkFlags`:
|
||||
|
||||
```nix
|
||||
rustPlatform.buildRustPackage {
|
||||
/* ... */
|
||||
checkFlags = [
|
||||
# reason for disabling test
|
||||
"--skip=example::tests:example_test"
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
#### Using `cargo-nextest` {#using-cargo-nextest}
|
||||
|
||||
Tests can be run with [cargo-nextest](https://github.com/nextest-rs/nextest)
|
||||
by setting `useNextest = true`. The same options still apply, but nextest
|
||||
accepts a different set of arguments and the settings might need to be
|
||||
adapted to be compatible with cargo-nextest.
|
||||
|
||||
```nix
|
||||
rustPlatform.buildRustPackage {
|
||||
/* ... */
|
||||
useNextest = true;
|
||||
}
|
||||
```
|
||||
|
||||
#### Setting `test-threads` {#setting-test-threads}
|
||||
|
||||
`buildRustPackage` will use parallel test threads by default,
|
||||
@@ -391,8 +417,8 @@ cargoDeps = rustPlatform.fetchCargoTarball {
|
||||
```
|
||||
|
||||
The `src` attribute is required, as well as a hash specified through
|
||||
one of the `sha256` or `hash` attributes. The following optional
|
||||
attributes can also be used:
|
||||
one of the `hash` attribute. The following optional attributes can
|
||||
also be used:
|
||||
|
||||
* `name`: the name that is used for the dependencies tarball. If
|
||||
`name` is not specified, then the name `cargo-deps` will be used.
|
||||
@@ -462,6 +488,9 @@ you of the correct hash.
|
||||
flags can be passed to the tests using `checkFlags` and
|
||||
`checkFlagsArray`. By default, tests are run in parallel. This can
|
||||
be disabled by setting `dontUseCargoParallelTests`.
|
||||
* `cargoNextestHook`: run tests using
|
||||
[cargo-nextest](https://github.com/nextest-rs/nextest). The same
|
||||
options for `cargoCheckHook` also applies to `cargoNextestHook`.
|
||||
* `cargoInstallHook`: install binaries and static/shared libraries
|
||||
that were built using `cargoBuildHook`.
|
||||
* `bindgenHook`: for crates which use `bindgen` as a build dependency, lets
|
||||
@@ -502,7 +531,7 @@ buildPythonPackage rec {
|
||||
cargoDeps = rustPlatform.fetchCargoTarball {
|
||||
inherit src sourceRoot;
|
||||
name = "${pname}-${version}";
|
||||
hash = "sha256-BoHIN/519Top1NUBjpB/oEMqi86Omt3zTQcXFWqrek0=";
|
||||
hash = "sha256-miW//pnOmww2i6SOGbkrAIdc/JMDT4FJLqdMFojZeoY=";
|
||||
};
|
||||
|
||||
sourceRoot = "source/bindings/python";
|
||||
@@ -539,7 +568,7 @@ buildPythonPackage rec {
|
||||
|
||||
src = fetchPypi {
|
||||
inherit pname version;
|
||||
sha256 = "1i1mx5y9hkyfi9jrrkcw804hmkcglxi6rmf7vin7jfnbr2bf4q64";
|
||||
hash = "sha256-xGDilsjLOnls3MfVbGKnj80KCUCczZxlis5PmHzpNcQ=";
|
||||
};
|
||||
|
||||
cargoDeps = rustPlatform.fetchCargoTarball {
|
||||
@@ -579,7 +608,7 @@ buildPythonPackage rec {
|
||||
owner = "Qiskit";
|
||||
repo = "retworkx";
|
||||
rev = version;
|
||||
sha256 = "11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20";
|
||||
hash = "sha256-11n30ldg3y3y6qxg3hbj837pnbwjkqw3nxq6frds647mmmprrd20=";
|
||||
};
|
||||
|
||||
cargoDeps = rustPlatform.fetchCargoTarball {
|
||||
@@ -596,227 +625,6 @@ buildPythonPackage rec {
|
||||
}
|
||||
```
|
||||
|
||||
## Compiling Rust crates using Nix instead of Cargo {#compiling-rust-crates-using-nix-instead-of-cargo}
|
||||
|
||||
### Simple operation {#simple-operation}
|
||||
|
||||
When run, `cargo build` produces a file called `Cargo.lock`,
|
||||
containing pinned versions of all dependencies. Nixpkgs contains a
|
||||
tool called `carnix` (`nix-env -iA nixos.carnix`), which can be used
|
||||
to turn a `Cargo.lock` into a Nix expression.
|
||||
|
||||
That Nix expression calls `rustc` directly (hence bypassing Cargo),
|
||||
and can be used to compile a crate and all its dependencies. Here is
|
||||
an example for a minimal `hello` crate:
|
||||
|
||||
```ShellSession
|
||||
$ cargo new hello
|
||||
$ cd hello
|
||||
$ cargo build
|
||||
Compiling hello v0.1.0 (file:///tmp/hello)
|
||||
Finished dev [unoptimized + debuginfo] target(s) in 0.20 secs
|
||||
$ carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
$ nix-build hello.nix -A hello_0_1_0
|
||||
```
|
||||
|
||||
Now, the file produced by the call to `carnix`, called `hello.nix`, looks like:
|
||||
|
||||
```nix
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
# ... (content skipped)
|
||||
in
|
||||
rec {
|
||||
hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
|
||||
hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "hello";
|
||||
version = "0.1.0";
|
||||
authors = [ "pe@pijul.org <pe@pijul.org>" ];
|
||||
src = ./.;
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {};
|
||||
hello_0_1_0_features = f: updateFeatures f (rec {
|
||||
hello_0_1_0.default = (f.hello_0_1_0.default or true);
|
||||
}) [ ];
|
||||
}
|
||||
```
|
||||
|
||||
In particular, note that the argument given as `--src` is copied
|
||||
verbatim to the source. If we look at a more complicated
|
||||
dependencies, for instance by adding a single line `libc="*"` to our
|
||||
`Cargo.toml`, we first need to run `cargo build` to update the
|
||||
`Cargo.lock`. Then, `carnix` needs to be run again, and produces the
|
||||
following nix file:
|
||||
|
||||
```nix
|
||||
# Generated by carnix 0.6.5: carnix -o hello.nix --src ./. Cargo.lock --standalone
|
||||
{ stdenv, buildRustCrate, fetchgit }:
|
||||
let kernel = stdenv.buildPlatform.parsed.kernel.name;
|
||||
# ... (content skipped)
|
||||
in
|
||||
rec {
|
||||
hello = f: hello_0_1_0 { features = hello_0_1_0_features { hello_0_1_0 = f; }; };
|
||||
hello_0_1_0_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "hello";
|
||||
version = "0.1.0";
|
||||
authors = [ "pe@pijul.org <pe@pijul.org>" ];
|
||||
src = ./.;
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
libc_0_2_36_ = { dependencies?[], buildDependencies?[], features?[] }: buildRustCrate {
|
||||
crateName = "libc";
|
||||
version = "0.2.36";
|
||||
authors = [ "The Rust Project Developers" ];
|
||||
sha256 = "01633h4yfqm0s302fm0dlba469bx8y6cs4nqc8bqrmjqxfxn515l";
|
||||
inherit dependencies buildDependencies features;
|
||||
};
|
||||
hello_0_1_0 = { features?(hello_0_1_0_features {}) }: hello_0_1_0_ {
|
||||
dependencies = mapFeatures features ([ libc_0_2_36 ]);
|
||||
};
|
||||
hello_0_1_0_features = f: updateFeatures f (rec {
|
||||
hello_0_1_0.default = (f.hello_0_1_0.default or true);
|
||||
libc_0_2_36.default = true;
|
||||
}) [ libc_0_2_36_features ];
|
||||
libc_0_2_36 = { features?(libc_0_2_36_features {}) }: libc_0_2_36_ {
|
||||
features = mkFeatures (features.libc_0_2_36 or {});
|
||||
};
|
||||
libc_0_2_36_features = f: updateFeatures f (rec {
|
||||
libc_0_2_36.default = (f.libc_0_2_36.default or true);
|
||||
libc_0_2_36.use_std =
|
||||
(f.libc_0_2_36.use_std or false) ||
|
||||
(f.libc_0_2_36.default or false) ||
|
||||
(libc_0_2_36.default or false);
|
||||
}) [];
|
||||
}
|
||||
```
|
||||
|
||||
Here, the `libc` crate has no `src` attribute, so `buildRustCrate`
|
||||
will fetch it from [crates.io](https://crates.io). A `sha256`
|
||||
attribute is still needed for Nix purity.
|
||||
|
||||
### Handling external dependencies {#handling-external-dependencies}
|
||||
|
||||
Some crates require external libraries. For crates from
|
||||
[crates.io](https://crates.io), such libraries can be specified in
|
||||
`defaultCrateOverrides` package in nixpkgs itself.
|
||||
|
||||
Starting from that file, one can add more overrides, to add features
|
||||
or build inputs by overriding the hello crate in a separate file.
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
hello = attrs: { buildInputs = [ openssl ]; };
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Here, `crateOverrides` is expected to be a attribute set, where the
|
||||
key is the crate name without version number and the value a function.
|
||||
The function gets all attributes passed to `buildRustCrate` as first
|
||||
argument and returns a set that contains all attribute that should be
|
||||
overwritten.
|
||||
|
||||
For more complicated cases, such as when parts of the crate's
|
||||
derivation depend on the crate's version, the `attrs` argument of
|
||||
the override above can be read, as in the following example, which
|
||||
patches the derivation:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import ./hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
hello = attrs: lib.optionalAttrs (lib.versionAtLeast attrs.version "1.0") {
|
||||
postPatch = ''
|
||||
substituteInPlace lib/zoneinfo.rs \
|
||||
--replace "/usr/share/zoneinfo" "${tzdata}/share/zoneinfo"
|
||||
'';
|
||||
};
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
Another situation is when we want to override a nested
|
||||
dependency. This actually works in the exact same way, since the
|
||||
`crateOverrides` parameter is forwarded to the crate's
|
||||
dependencies. For instance, to override the build inputs for crate
|
||||
`libc` in the example above, where `libc` is a dependency of the main
|
||||
crate, we could do:
|
||||
|
||||
```nix
|
||||
with import <nixpkgs> {};
|
||||
((import hello.nix).hello {}).override {
|
||||
crateOverrides = defaultCrateOverrides // {
|
||||
libc = attrs: { buildInputs = []; };
|
||||
};
|
||||
}
|
||||
```
|
||||
|
||||
### Options and phases configuration {#options-and-phases-configuration}
|
||||
|
||||
Actually, the overrides introduced in the previous section are more
|
||||
general. A number of other parameters can be overridden:
|
||||
|
||||
- The version of `rustc` used to compile the crate:
|
||||
|
||||
```nix
|
||||
(hello {}).override { rust = pkgs.rust; };
|
||||
```
|
||||
|
||||
- Whether to build in release mode or debug mode (release mode by
|
||||
default):
|
||||
|
||||
```nix
|
||||
(hello {}).override { release = false; };
|
||||
```
|
||||
|
||||
- Whether to print the commands sent to `rustc` when building
|
||||
(equivalent to `--verbose` in cargo:
|
||||
|
||||
```nix
|
||||
(hello {}).override { verbose = false; };
|
||||
```
|
||||
|
||||
- Extra arguments to be passed to `rustc`:
|
||||
|
||||
```nix
|
||||
(hello {}).override { extraRustcOpts = "-Z debuginfo=2"; };
|
||||
```
|
||||
|
||||
- Phases, just like in any other derivation, can be specified using
|
||||
the following attributes: `preUnpack`, `postUnpack`, `prePatch`,
|
||||
`patches`, `postPatch`, `preConfigure` (in the case of a Rust crate,
|
||||
this is run before calling the "build" script), `postConfigure`
|
||||
(after the "build" script),`preBuild`, `postBuild`, `preInstall` and
|
||||
`postInstall`. As an example, here is how to create a new module
|
||||
before running the build script:
|
||||
|
||||
```nix
|
||||
(hello {}).override {
|
||||
preConfigure = ''
|
||||
echo "pub const PATH=\"${hi.out}\";" >> src/path.rs"
|
||||
'';
|
||||
};
|
||||
```
|
||||
|
||||
### Features {#features}
|
||||
|
||||
One can also supply features switches. For example, if we want to
|
||||
compile `diesel_cli` only with the `postgres` feature, and no default
|
||||
features, we would write:
|
||||
|
||||
```nix
|
||||
(callPackage ./diesel.nix {}).diesel {
|
||||
default = false;
|
||||
postgres = true;
|
||||
}
|
||||
```
|
||||
|
||||
Where `diesel.nix` is the file generated by Carnix, as explained above.
|
||||
|
||||
## Setting Up `nix-shell` {#setting-up-nix-shell}
|
||||
|
||||
Oftentimes you want to develop code from within `nix-shell`. Unfortunately
|
||||
@@ -874,7 +682,7 @@ let src = fetchFromGitHub {
|
||||
repo = "nixpkgs-mozilla";
|
||||
# commit from: 2019-05-15
|
||||
rev = "9f35c4b09fd44a77227e79ff0c1b4b6a69dff533";
|
||||
sha256 = "18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0";
|
||||
hash = "sha256-18h0nvh55b5an4gmlgfbvwbyqj91bklf1zymis6lbdh75571qaz0=";
|
||||
};
|
||||
in
|
||||
with import "${src.out}/rust-overlay.nix" pkgs pkgs;
|
||||
@@ -965,7 +773,7 @@ rustPlatform.buildRustPackage rec {
|
||||
owner = "BurntSushi";
|
||||
repo = "ripgrep";
|
||||
rev = version;
|
||||
sha256 = "1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps";
|
||||
hash = "sha256-1hqps7l5qrjh9f914r5i6kmcz6f1yb951nv4lby0cjnp5l253kps=";
|
||||
};
|
||||
|
||||
cargoSha256 = "03wf9r2csi6jpa7v5sw5lpxkrk4wfzwmzx7k3991q3bdjzcwnnwp";
|
||||
|
||||
@@ -55,11 +55,11 @@ let
|
||||
srcs = [
|
||||
(fetchurl {
|
||||
url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.dtx";
|
||||
sha256 = "07frz0krpz7kkcwlayrwrj2a2pixmv0icbngyw92srp9fp23cqpz";
|
||||
hash = "sha256-/2I2xHXpZi0S988uFsGuPV6hhMw8e0U5m/P8myf42R0=";
|
||||
})
|
||||
(fetchurl {
|
||||
url = "http://mirrors.ctan.org/macros/latex/contrib/foiltex/foiltex.ins";
|
||||
sha256 = "09wkyidxk3n3zvqxfs61wlypmbhi1pxmjdi1kns9n2ky8ykbff99";
|
||||
hash = "sha256-KTm3pkd+Cpu0nSE2WfsNEa56PeXBaNfx/sOO2Vv0kyc=";
|
||||
})
|
||||
];
|
||||
|
||||
|
||||
@@ -10,12 +10,21 @@ At the moment we support two different methods for managing plugins:
|
||||
- Vim packages (*recommended*)
|
||||
- vim-plug (vim only)
|
||||
|
||||
Right now two Vim packages are available: `vim` which has most features that require extra
|
||||
dependencies disabled and `vim-full` which has them configurable and enabled by default.
|
||||
|
||||
::: {.note}
|
||||
`vim_configurable` is a deprecated alias for `vim-full` and refers to the fact that its
|
||||
build-time features are configurable. It has nothing to do with user configuration,
|
||||
and both the `vim` and `vim-full` packages can be customized as explained in the next section.
|
||||
:::
|
||||
|
||||
## Custom configuration {#custom-configuration}
|
||||
|
||||
Adding custom .vimrc lines can be done using the following code:
|
||||
|
||||
```nix
|
||||
vim_configurable.customize {
|
||||
vim-full.customize {
|
||||
# `name` optionally specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
|
||||
@@ -62,7 +71,7 @@ neovim-qt.override {
|
||||
To store your plugins in Vim packages (the native Vim plugin manager, see `:help packages`) the following example can be used:
|
||||
|
||||
```nix
|
||||
vim_configurable.customize {
|
||||
vim-full.customize {
|
||||
vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# loaded on launch
|
||||
start = [ youcompleteme fugitive ];
|
||||
@@ -101,7 +110,7 @@ The resulting package can be added to `packageOverrides` in `~/.nixpkgs/config.n
|
||||
```nix
|
||||
{
|
||||
packageOverrides = pkgs: with pkgs; {
|
||||
myVim = vim_configurable.customize {
|
||||
myVim = vim-full.customize {
|
||||
# `name` specifies the name of the executable and package
|
||||
name = "vim-with-plugins";
|
||||
# add here code from the example section
|
||||
@@ -125,13 +134,13 @@ If one of your favourite plugins isn't packaged, you can package it yourself:
|
||||
{ config, pkgs, ... }:
|
||||
|
||||
let
|
||||
easygrep = pkgs.vimUtils.buildVimPlugin {
|
||||
easygrep = pkgs.vimUtils.buildVimPluginFrom2Nix {
|
||||
name = "vim-easygrep";
|
||||
src = pkgs.fetchFromGitHub {
|
||||
owner = "dkprice";
|
||||
repo = "vim-easygrep";
|
||||
rev = "d0c36a77cc63c22648e792796b1815b44164653a";
|
||||
sha256 = "0y2p5mz0d5fhg6n68lhfhl8p4mlwkb82q337c22djs4w5zyzggbc";
|
||||
hash = "sha256-bL33/S+caNmEYGcMLNCanFZyEYUOUmSsedCVBn4tV3g=";
|
||||
};
|
||||
};
|
||||
in
|
||||
@@ -155,6 +164,8 @@ in
|
||||
}
|
||||
```
|
||||
|
||||
If your package requires building specific parts, use instead `pkgs.vimUtils.buildVimPlugin`.
|
||||
|
||||
### Specificities for some plugins
|
||||
#### Treesitter
|
||||
|
||||
@@ -170,8 +181,8 @@ of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
|
||||
start = [
|
||||
(nvim-treesitter.withPlugins (
|
||||
plugins: with plugins; [
|
||||
tree-sitter-nix
|
||||
tree-sitter-python
|
||||
nix
|
||||
python
|
||||
]
|
||||
))
|
||||
];
|
||||
@@ -180,7 +191,7 @@ of precompiled grammars, you can use `nvim-treesitter.withPlugins` function:
|
||||
})
|
||||
```
|
||||
|
||||
To enable all grammars packaged in nixpkgs, use `(pkgs.vimPlugins.nvim-treesitter.withPlugins (plugins: pkgs.tree-sitter.allGrammars))`.
|
||||
To enable all grammars packaged in nixpkgs, use `pkgs.vimPlugins.nvim-treesitter.withAllGrammars`.
|
||||
|
||||
## Managing plugins with vim-plug {#managing-plugins-with-vim-plug}
|
||||
|
||||
@@ -188,7 +199,7 @@ To use [vim-plug](https://github.com/junegunn/vim-plug) to manage your Vim
|
||||
plugins the following example can be used:
|
||||
|
||||
```nix
|
||||
vim_configurable.customize {
|
||||
vim-full.customize {
|
||||
vimrcConfig.packages.myVimPackage = with pkgs.vimPlugins; {
|
||||
# loaded on launch
|
||||
plug.plugins = [ youcompleteme fugitive phpCompletion elm-vim ];
|
||||
@@ -203,6 +214,8 @@ Note: this is not possible anymore for Neovim.
|
||||
|
||||
Nix expressions for Vim plugins are stored in [pkgs/applications/editors/vim/plugins](https://github.com/NixOS/nixpkgs/tree/master/pkgs/applications/editors/vim/plugins). For the vast majority of plugins, Nix expressions are automatically generated by running [`./update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py). This creates a [generated.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/generated.nix) file based on the plugins listed in [vim-plugin-names](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/vim-plugin-names). Plugins are listed in alphabetical order in `vim-plugin-names` using the format `[github username]/[repository]@[gitref]`. For example https://github.com/scrooloose/nerdtree becomes `scrooloose/nerdtree`.
|
||||
|
||||
After running `./update.py`, if nvim-treesitter received an update, also run [`nvim-treesitter/update.py`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/update.py) to update the tree sitter grammars for `nvim-treesitter`.
|
||||
|
||||
Some plugins require overrides in order to function properly. Overrides are placed in [overrides.nix](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/overrides.nix). Overrides are most often required when a plugin requires some dependencies, or extra steps are required during the build process. For example `deoplete-fish` requires both `deoplete-nvim` and `vim-fish`, and so the following override was added:
|
||||
|
||||
```nix
|
||||
|
||||
@@ -61,7 +61,7 @@ stdenv.mkDerivation {
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = "http://ftp.nluug.nl/gnu/binutils/binutils-2.16.1.tar.bz2";
|
||||
sha256 = "1ian3kwh2vg6hr3ymrv48s04gijs539vzrq62xr76bxbhbwnz2np";
|
||||
hash = "sha256-14pv+YKrL3NyFwbnv9MoWsZHgEZk5+pHhuZtAfkcVsU=";
|
||||
};
|
||||
inherit noSysDirs;
|
||||
configureFlags = [ "--target=arm-linux" ];
|
||||
@@ -85,7 +85,7 @@ stdenv.mkDerivation {
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = "http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.13.1.tar.bz2";
|
||||
sha256 = "12qxmc827fjhaz53kjy7vyrzsaqcg78amiqsb3qm20z26w705lma";
|
||||
hash = "sha256-qtICDjfiA1HxWBrHqtB5DCv9s9/HyznKV1C6IxCrHYs=";
|
||||
};
|
||||
}
|
||||
---
|
||||
@@ -151,8 +151,8 @@ stdenv.mkDerivation {
|
||||
name = "gcc-4.0.2-arm";
|
||||
builder = ./builder.sh;
|
||||
src = fetchurl {
|
||||
url = ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2;
|
||||
sha256 = "02fxh0asflm8825w23l2jq1wvs7hbnam0jayrivg7zdv2ifnc0rc";
|
||||
url = "ftp://ftp.nluug.nl/pub/gnu/gcc/gcc-4.0.2/gcc-core-4.0.2.tar.bz2";
|
||||
hash = "sha256-LANmXRS7/fN2zF5JUJVd8OjNA5aCDsGLQKhSpxWA3Qk=";
|
||||
};
|
||||
# !!! apply only if noSysDirs is set
|
||||
patches = [./no-sys-dirs.patch ./gcc-inhibit.patch];
|
||||
|
||||
@@ -250,5 +250,5 @@ Thirdly, it is because everything target-mentioning only exists to accommodate c
|
||||
:::
|
||||
|
||||
::: {.note}
|
||||
If one explores Nixpkgs, they will see derivations with names like `gccCross`. Such `*Cross` derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with “Cross” in the name covered the `build = host != target` case, while the other covered the `host = target`, with build platform the same or not based on whether one was using its `.nativeDrv` or `.crossDrv`. This ugliness will disappear soon.
|
||||
If one explores Nixpkgs, they will see derivations with names like `gccCross`. Such `*Cross` derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with “Cross” in the name covered the `build = host != target` case, while the other covered the `host = target`, with build platform the same or not based on whether one was using its `.__spliced.buildHost` or `.__spliced.hostTarget`.
|
||||
:::
|
||||
|
||||
@@ -11,58 +11,12 @@ meta = with lib; {
|
||||
'';
|
||||
homepage = "https://www.gnu.org/software/hello/manual/";
|
||||
license = licenses.gpl3Plus;
|
||||
maintainers = [ maintainers.eelco ];
|
||||
maintainers = with maintainers; [ eelco ];
|
||||
platforms = platforms.all;
|
||||
};
|
||||
```
|
||||
|
||||
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package. The value of a meta-attribute must be a string.
|
||||
|
||||
The meta-attributes of a package can be queried from the command-line using `nix-env`:
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -qa hello --json
|
||||
{
|
||||
"hello": {
|
||||
"meta": {
|
||||
"description": "A program that produces a familiar, friendly greeting",
|
||||
"homepage": "https://www.gnu.org/software/hello/manual/",
|
||||
"license": {
|
||||
"fullName": "GNU General Public License version 3 or later",
|
||||
"shortName": "GPLv3+",
|
||||
"url": "http://www.fsf.org/licensing/licenses/gpl.html"
|
||||
},
|
||||
"longDescription": "GNU Hello is a program that prints \"Hello, world!\" when you run it.\nIt is fully customizable.\n",
|
||||
"maintainers": [
|
||||
"Ludovic Court\u00e8s <ludo@gnu.org>"
|
||||
],
|
||||
"platforms": [
|
||||
"i686-linux",
|
||||
"x86_64-linux",
|
||||
"armv5tel-linux",
|
||||
"armv7l-linux",
|
||||
"mips32-linux",
|
||||
"x86_64-darwin",
|
||||
"i686-cygwin",
|
||||
"i686-freebsd",
|
||||
"x86_64-freebsd",
|
||||
"i686-openbsd",
|
||||
"x86_64-openbsd"
|
||||
],
|
||||
"position": "/home/user/dev/nixpkgs/pkgs/applications/misc/hello/default.nix:14"
|
||||
},
|
||||
"name": "hello-2.9",
|
||||
"system": "x86_64-linux"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`nix-env` knows about the `description` field specifically:
|
||||
|
||||
```ShellSession
|
||||
$ nix-env -qa hello --description
|
||||
hello-2.3 A program that produces a familiar, friendly greeting
|
||||
```
|
||||
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
|
||||
|
||||
## Standard meta-attributes {#sec-standard-meta-attributes}
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@ stdenv.mkDerivation {
|
||||
name = "libfoo-1.2.3";
|
||||
src = fetchurl {
|
||||
url = "http://example.org/libfoo-1.2.3.tar.bz2";
|
||||
sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
|
||||
hash = "sha256-tWxU/LANbQE32my+9AXyt3nCT7NBVfJ45CX757EMT3Q=";
|
||||
};
|
||||
}
|
||||
```
|
||||
@@ -24,7 +24,7 @@ stdenv.mkDerivation rec {
|
||||
version = "1.2.3";
|
||||
src = fetchurl {
|
||||
url = "http://example.org/libfoo-source-${version}.tar.bz2";
|
||||
sha256 = "0x2g1jqygyr5wiwg4ma1nd7w4ydpy82z9gkcv8vh2v8dn3y58v5m";
|
||||
hash = "sha256-tWxU/LANbQE32my+9AXyt3nCT7NBVfJ45CX757EMT3Q=";
|
||||
};
|
||||
}
|
||||
```
|
||||
@@ -887,7 +887,7 @@ Packages may expect or require other utilities to be available at runtime.
|
||||
|
||||
Use `--prefix` to explicitly set dependencies in `PATH`.
|
||||
|
||||
:::{note}
|
||||
::: {.note}
|
||||
`--prefix` essentially hard-codes dependencies into the wrapper.
|
||||
They cannot be overridden without rebuilding the package.
|
||||
:::
|
||||
@@ -1109,13 +1109,15 @@ This setup hook moves any libraries installed in the `lib64/` subdirectory into
|
||||
|
||||
This setup hook moves any systemd user units installed in the `lib/` subdirectory into `share/`. In addition, a link is provided from `share/` to `lib/` for compatibility. This is needed for systemd to find user services when installed into the user profile.
|
||||
|
||||
This hook only runs when compiling for Linux.
|
||||
|
||||
### `set-source-date-epoch-to-latest.sh` {#set-source-date-epoch-to-latest.sh}
|
||||
|
||||
This sets `SOURCE_DATE_EPOCH` to the modification time of the most recent file.
|
||||
|
||||
### Bintools Wrapper {#bintools-wrapper}
|
||||
### Bintools Wrapper and hook {#bintools-wrapper}
|
||||
|
||||
The Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes. These are GNU Binutils when targetting Linux, and a mix of cctools and GNU binutils for Darwin. \[The “Bintools” name is supposed to be a compromise between “Binutils” and “cctools” not denoting any specific implementation.\] Specifically, the underlying bintools package, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn (at run time) depends on the Bintools Wrapper.
|
||||
The Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes. These are GNU Binutils when targeting Linux, and a mix of cctools and GNU binutils for Darwin. \[The “Bintools” name is supposed to be a compromise between “Binutils” and “cctools” not denoting any specific implementation.\] Specifically, the underlying bintools package, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the Bintools Wrapper. Packages typically depend on CC Wrapper, which in turn (at run time) depends on the Bintools Wrapper.
|
||||
|
||||
The Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out. For example, it shouldn’t care about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux). Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand. It is currently accomplished by collecting directories of host-platform dependencies (i.e. `buildInputs` and `nativeBuildInputs`) in environment variables. The Bintools Wrapper’s setup hook causes any `lib` and `lib64` subdirectories to be added to `NIX_LDFLAGS`. Since the CC Wrapper and the Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to the CC Wrapper. But the CC Wrapper’s code, by contrast, has quite lengthy comments. The Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
|
||||
|
||||
@@ -1123,173 +1125,27 @@ A final task of the setup hook is defining a number of standard environment vari
|
||||
|
||||
A problem with this final task is that the Bintools Wrapper is honest and defines `LD` as `ld`. Most packages, however, firstly use the C compiler for linking, secondly use `LD` anyways, defining it as the C compiler, and thirdly, only so define `LD` when it is undefined as a fallback. This triple-threat means Bintools Wrapper will break those packages, as LD is already defined as the actual linker which the package won’t override yet doesn’t want to use. The workaround is to define, just for the problematic package, `LD` as the C compiler. A good way to do this would be `preConfigure = "LD=$CC"`.
|
||||
|
||||
### CC Wrapper {#cc-wrapper}
|
||||
### CC Wrapper and hook {#cc-wrapper}
|
||||
|
||||
The CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes. Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C standard library (glibc or Darwin’s libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by the CC Wrapper. Packages typically depend on the CC Wrapper, which in turn (at run-time) depends on the Bintools Wrapper.
|
||||
|
||||
Dependency finding is undoubtedly the main task of the CC Wrapper. This works just like the Bintools Wrapper, except that any `include` subdirectory of any relevant dependency is added to `NIX_CFLAGS_COMPILE`. The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
|
||||
Dependency finding is undoubtedly the main task of the CC Wrapper. This works just like the Bintools Wrapper, except that any `include` subdirectory of any relevant dependency is added to `NIX_CFLAGS_COMPILE`. The setup hook itself contains elaborate comments describing the exact mechanism by which this is accomplished.
|
||||
|
||||
Similarly, the CC Wrapper follows the Bintools Wrapper in defining standard environment variables with the names of the tools it wraps, for the same reasons described above. Importantly, while it includes a `cc` symlink to the c compiler for portability, the `CC` will be defined using the compiler’s “real name” (i.e. `gcc` or `clang`). This helps lousy build systems that inspect on the name of the compiler rather than run it.
|
||||
|
||||
Here are some more packages that provide a setup hook. Since the list of hooks is extensible, this is not an exhaustive list. The mechanism is only to be used as a last resort, so it might cover most uses.
|
||||
|
||||
### Perl {#setup-hook-perl}
|
||||
### Other hooks
|
||||
|
||||
Adds the `lib/site_perl` subdirectory of each build input to the `PERL5LIB` environment variable. For instance, if `buildInputs` contains Perl, then the `lib/site_perl` subdirectory of each input is added to the `PERL5LIB` environment variable.
|
||||
Many other packages provide hooks, that are not part of `stdenv`. You can find
|
||||
these in the [Hooks Reference](#chap-hooks).
|
||||
|
||||
### Python {#setup-hook-python}
|
||||
### Compiler and Linker wrapper hooks {#compiler-linker-wrapper-hooks}
|
||||
|
||||
Adds the `lib/${python.libPrefix}/site-packages` subdirectory of each build input to the `PYTHONPATH` environment variable.
|
||||
|
||||
### pkg-config {#setup-hook-pkg-config}
|
||||
|
||||
Adds the `lib/pkgconfig` and `share/pkgconfig` subdirectories of each build input to the `PKG_CONFIG_PATH` environment variable.
|
||||
|
||||
### Automake {#setup-hook-automake}
|
||||
|
||||
Adds the `share/aclocal` subdirectory of each build input to the `ACLOCAL_PATH` environment variable.
|
||||
|
||||
### Autoconf {#setup-hook-autoconf}
|
||||
|
||||
The `autoreconfHook` derivation adds `autoreconfPhase`, which runs autoreconf, libtoolize and automake, essentially preparing the configure script in autotools-based builds. Most autotools-based packages come with the configure script pre-generated, but this hook is necessary for a few packages and when you need to patch the package’s configure scripts.
|
||||
|
||||
### libxml2 {#setup-hook-libxml2}
|
||||
|
||||
Adds every file named `catalog.xml` found under the `xml/dtd` and `xml/xsl` subdirectories of each build input to the `XML_CATALOG_FILES` environment variable.
|
||||
|
||||
### teTeX / TeX Live {#tetex-tex-live}
|
||||
|
||||
Adds the `share/texmf-nix` subdirectory of each build input to the `TEXINPUTS` environment variable.
|
||||
|
||||
### Qt 4 {#qt-4}
|
||||
|
||||
Sets the `QTDIR` environment variable to Qt’s path.
|
||||
|
||||
### gdk-pixbuf {#setup-hook-gdk-pixbuf}
|
||||
|
||||
Exports `GDK_PIXBUF_MODULE_FILE` environment variable to the builder. Add librsvg package to `buildInputs` to get svg support. See also the [setup hook description in GNOME platform docs](#ssec-gnome-hooks-gdk-pixbuf).
|
||||
|
||||
### GHC {#ghc}
|
||||
|
||||
Creates a temporary package database and registers every Haskell build input in it (TODO: how?).
|
||||
|
||||
### GNOME platform {#gnome-platform}
|
||||
|
||||
Hooks related to GNOME platform and related libraries like GLib, GTK and GStreamer are described in [](#sec-language-gnome).
|
||||
|
||||
### autoPatchelfHook {#setup-hook-autopatchelfhook}
|
||||
|
||||
This is a special setup hook which helps in packaging proprietary software in that it automatically tries to find missing shared library dependencies of ELF files based on the given `buildInputs` and `nativeBuildInputs`.
|
||||
|
||||
You can also specify a `runtimeDependencies` variable which lists dependencies to be unconditionally added to rpath of all executables. This is useful for programs that use dlopen 3 to load libraries at runtime.
|
||||
|
||||
In certain situations you may want to run the main command (`autoPatchelf`) of the setup hook on a file or a set of directories instead of unconditionally patching all outputs. This can be done by setting the `dontAutoPatchelf` environment variable to a non-empty value.
|
||||
|
||||
By default `autoPatchelf` will fail as soon as any ELF file requires a dependency which cannot be resolved via the given build inputs. In some situations you might prefer to just leave missing dependencies unpatched and continue to patch the rest. This can be achieved by setting the `autoPatchelfIgnoreMissingDeps` environment variable to a non-empty value. `autoPatchelfIgnoreMissingDeps` can be set to a list like `autoPatchelfIgnoreMissingDeps = [ "libcuda.so.1" "libcudart.so.1" ];` or to simply `[ "*" ]` to ignore all missing dependencies.
|
||||
|
||||
The `autoPatchelf` command also recognizes a `--no-recurse` command line flag, which prevents it from recursing into subdirectories.
|
||||
|
||||
### breakpointHook {#breakpointhook}
|
||||
|
||||
This hook will make a build pause instead of stopping when a failure happens. It prevents nix from cleaning up the build environment immediately and allows the user to attach to a build environment using the `cntr` command. Upon build error it will print instructions on how to use `cntr`, which can be used to enter the environment for debugging. Installing cntr and running the command will provide shell access to the build sandbox of failed build. At `/var/lib/cntr` the sandboxed filesystem is mounted. All commands and files of the system are still accessible within the shell. To execute commands from the sandbox use the cntr exec subcommand. `cntr` is only supported on Linux-based platforms. To use it first add `cntr` to your `environment.systemPackages` on NixOS or alternatively to the root user on non-NixOS systems. Then in the package that is supposed to be inspected, add `breakpointHook` to `nativeBuildInputs`.
|
||||
|
||||
```nix
|
||||
nativeBuildInputs = [ breakpointHook ];
|
||||
```
|
||||
|
||||
When a build failure happens there will be an instruction printed that shows how to attach with `cntr` to the build sandbox.
|
||||
|
||||
::: {.note}
|
||||
::: {.title}
|
||||
Caution with remote builds
|
||||
:::
|
||||
|
||||
This won’t work with remote builds as the build environment is on a different machine and can’t be accessed by `cntr`. Remote builds can be turned off by setting `--option builders ''` for `nix-build` or `--builders ''` for `nix build`.
|
||||
:::
|
||||
|
||||
### installShellFiles {#installshellfiles}
|
||||
|
||||
This hook helps with installing manpages and shell completion files. It exposes 2 shell functions `installManPage` and `installShellCompletion` that can be used from your `postInstall` hook.
|
||||
|
||||
The `installManPage` function takes one or more paths to manpages to install. The manpages must have a section suffix, and may optionally be compressed (with `.gz` suffix). This function will place them into the correct directory.
|
||||
|
||||
The `installShellCompletion` function takes one or more paths to shell completion files. By default it will autodetect the shell type from the completion file extension, but you may also specify it by passing one of `--bash`, `--fish`, or `--zsh`. These flags apply to all paths listed after them (up until another shell flag is given). Each path may also have a custom installation name provided by providing a flag `--name NAME` before the path. If this flag is not provided, zsh completions will be renamed automatically such that `foobar.zsh` becomes `_foobar`. A root name may be provided for all paths using the flag `--cmd NAME`; this synthesizes the appropriate name depending on the shell (e.g. `--cmd foo` will synthesize the name `foo.bash` for bash and `_foo` for zsh). The path may also be a fifo or named fd (such as produced by `<(cmd)`), in which case the shell and name must be provided.
|
||||
|
||||
```nix
|
||||
nativeBuildInputs = [ installShellFiles ];
|
||||
postInstall = ''
|
||||
installManPage doc/foobar.1 doc/barfoo.3
|
||||
# explicit behavior
|
||||
installShellCompletion --bash --name foobar.bash share/completions.bash
|
||||
installShellCompletion --fish --name foobar.fish share/completions.fish
|
||||
installShellCompletion --zsh --name _foobar share/completions.zsh
|
||||
# implicit behavior
|
||||
installShellCompletion share/completions/foobar.{bash,fish,zsh}
|
||||
# using named fd
|
||||
installShellCompletion --cmd foobar \
|
||||
--bash <($out/bin/foobar --bash-completion) \
|
||||
--fish <($out/bin/foobar --fish-completion) \
|
||||
--zsh <($out/bin/foobar --zsh-completion)
|
||||
'';
|
||||
```
|
||||
|
||||
### libiconv, libintl {#libiconv-libintl}
|
||||
|
||||
A few libraries automatically add to `NIX_LDFLAGS` their library, making their symbols automatically available to the linker. This includes libiconv and libintl (gettext). This is done to provide compatibility between GNU Linux, where libiconv and libintl are bundled in, and other systems where that might not be the case. Sometimes, this behavior is not desired. To disable this behavior, set `dontAddExtraLibs`.
|
||||
|
||||
### validatePkgConfig {#validatepkgconfig}
|
||||
|
||||
The `validatePkgConfig` hook validates all pkg-config (`.pc`) files in a package. This helps catching some common errors in pkg-config files, such as undefined variables.
|
||||
|
||||
### cmake {#cmake}
|
||||
|
||||
Overrides the default configure phase to run the CMake command. By default, we use the Make generator of CMake. In addition, dependencies are added automatically to `CMAKE_PREFIX_PATH` so that packages are correctly detected by CMake. Some additional flags are passed in to give similar behavior to configure-based packages. You can disable this hook’s behavior by setting `configurePhase` to a custom value, or by setting `dontUseCmakeConfigure`. `cmakeFlags` controls flags passed only to CMake. By default, parallel building is enabled as CMake supports parallel building almost everywhere. When Ninja is also in use, CMake will detect that and use the ninja generator.
|
||||
|
||||
### xcbuildHook {#xcbuildhook}
|
||||
|
||||
Overrides the build and install phases to run the "xcbuild" command. This hook is needed when a project only comes with build files for the XCode build system. You can disable this behavior by setting buildPhase and configurePhase to a custom value. xcbuildFlags controls flags passed only to xcbuild.
|
||||
|
||||
### Meson {#meson}
|
||||
|
||||
Overrides the configure phase to run meson to generate Ninja files. To run these files, you should accompany Meson with ninja. By default, `enableParallelBuilding` is enabled as Meson supports parallel building almost everywhere.
|
||||
|
||||
#### Variables controlling Meson {#variables-controlling-meson}
|
||||
|
||||
##### `mesonFlags` {#mesonflags}
|
||||
|
||||
Controls the flags passed to meson.
|
||||
|
||||
##### `mesonBuildType` {#mesonbuildtype}
|
||||
|
||||
Which [`--buildtype`](https://mesonbuild.com/Builtin-options.html#core-options) to pass to Meson. We default to `plain`.
|
||||
|
||||
##### `mesonAutoFeatures` {#mesonautofeatures}
|
||||
|
||||
What value to set [`-Dauto_features=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `enabled`.
|
||||
|
||||
##### `mesonWrapMode` {#mesonwrapmode}
|
||||
|
||||
What value to set [`-Dwrap_mode=`](https://mesonbuild.com/Builtin-options.html#core-options) to. We default to `nodownload` as we disallow network access.
|
||||
|
||||
##### `dontUseMesonConfigure` {#dontusemesonconfigure}
|
||||
|
||||
Disables using Meson’s `configurePhase`.
|
||||
|
||||
### ninja {#ninja}
|
||||
|
||||
Overrides the build, install, and check phase to run ninja instead of make. You can disable this behavior with the `dontUseNinjaBuild`, `dontUseNinjaInstall`, and `dontUseNinjaCheck`, respectively. Parallel building is enabled by default in Ninja.
|
||||
|
||||
### unzip {#unzip}
|
||||
|
||||
This setup hook will allow you to unzip .zip files specified in `$src`. There are many similar packages like `unrar`, `undmg`, etc.
|
||||
|
||||
### wafHook {#wafhook}
|
||||
|
||||
Overrides the configure, build, and install phases. This will run the “waf” script used by many projects. If `wafPath` (default `./waf`) doesn’t exist, it will copy the version of waf available in Nixpkgs. `wafFlags` can be used to pass flags to the waf script.
|
||||
|
||||
### scons {#scons}
|
||||
|
||||
Overrides the build, install, and check phases. This uses the scons build system as a replacement for make. scons does not provide a configure phase, so everything is managed at build and install time.
|
||||
If the file `${cc}/nix-support/cc-wrapper-hook` exists, it will be run at the end of the [compiler wrapper](#cc-wrapper).
|
||||
If the file `${binutils}/nix-support/post-link-hook` exists, it will be run at the end of the linker wrapper.
|
||||
These hooks allow a user to inject code into the wrappers.
|
||||
As an example, these hooks can be used to extract `extraBefore`, `params` and `extraAfter` which store all the command line arguments passed to the compiler and linker respectively.
|
||||
|
||||
## Purity in Nixpkgs {#sec-purity-in-nixpkgs}
|
||||
|
||||
|
||||
@@ -310,16 +310,16 @@ For this to work fully, you must also have this script sourced when you are logg
|
||||
|
||||
```ShellSession
|
||||
#!/bin/sh
|
||||
if [ -d $HOME/.nix-profile/etc/profile.d ]; then
|
||||
for i in $HOME/.nix-profile/etc/profile.d/*.sh; do
|
||||
if [ -r $i ]; then
|
||||
. $i
|
||||
if [ -d "${HOME}/.nix-profile/etc/profile.d" ]; then
|
||||
for i in "${HOME}/.nix-profile/etc/profile.d/"*.sh; do
|
||||
if [ -r "$i" ]; then
|
||||
. "$i"
|
||||
fi
|
||||
done
|
||||
fi
|
||||
```
|
||||
|
||||
Now just run `source $HOME/.profile` and you can starting loading man pages from your environment.
|
||||
Now just run `. "${HOME}/.profile"` and you can start loading man pages from your environment.
|
||||
|
||||
### GNU info setup {#sec-gnu-info-setup}
|
||||
|
||||
|
||||
@@ -74,8 +74,8 @@ Example usage:
|
||||
mySed = pkgs.gnused.overrideDerivation (oldAttrs: {
|
||||
name = "sed-4.2.2-pre";
|
||||
src = fetchurl {
|
||||
url = ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2;
|
||||
sha256 = "11nq06d131y4wmf3drm0yk502d2xc6n5qy82cg88rb9nqd2lj41k";
|
||||
url = "ftp://alpha.gnu.org/gnu/sed/sed-4.2.2-pre.tar.bz2";
|
||||
hash = "sha256-MxBJRcM2rYzQYwJ5XKxhXTQByvSg5jZc5cSHEZoB2IY=";
|
||||
};
|
||||
patches = [];
|
||||
});
|
||||
|
||||
14
flake.nix
14
flake.nix
@@ -11,8 +11,7 @@
|
||||
|
||||
lib = import ./lib;
|
||||
|
||||
forAllSystems = f: lib.genAttrs lib.systems.flakeExposed (system: f system);
|
||||
|
||||
forAllSystems = lib.genAttrs lib.systems.flakeExposed;
|
||||
in
|
||||
{
|
||||
lib = lib.extend (final: prev: {
|
||||
@@ -45,10 +44,19 @@
|
||||
}).nixos.manual.x86_64-linux;
|
||||
};
|
||||
|
||||
# The "legacy" in `legacyPackages` doesn't imply that the packages exposed
|
||||
# through this attribute are "legacy" packages. Instead, `legacyPackages`
|
||||
# is used here as a substitute attribute name for `packages`. The problem
|
||||
# with `packages` is that it makes operations like `nix flake show
|
||||
# nixpkgs` unusably slow due to the sheer number of packages the Nix CLI
|
||||
# needs to evaluate. But when the Nix CLI sees a `legacyPackages`
|
||||
# attribute it displays `omitted` instead of evaluating all packages,
|
||||
# which keeps `nix flake show` on Nixpkgs reasonably fast, though less
|
||||
# information rich.
|
||||
legacyPackages = forAllSystems (system: import ./. { inherit system; });
|
||||
|
||||
nixosModules = {
|
||||
notDetected = import ./nixos/modules/installer/scan/not-detected.nix;
|
||||
notDetected = ./nixos/modules/installer/scan/not-detected.nix;
|
||||
};
|
||||
};
|
||||
}
|
||||
|
||||
96
lib/ascii-table.nix
Normal file
96
lib/ascii-table.nix
Normal file
@@ -0,0 +1,96 @@
|
||||
{ " " = 32;
|
||||
"!" = 33;
|
||||
"\"" = 34;
|
||||
"#" = 35;
|
||||
"$" = 36;
|
||||
"%" = 37;
|
||||
"&" = 38;
|
||||
"'" = 39;
|
||||
"(" = 40;
|
||||
")" = 41;
|
||||
"*" = 42;
|
||||
"+" = 43;
|
||||
"," = 44;
|
||||
"-" = 45;
|
||||
"." = 46;
|
||||
"/" = 47;
|
||||
"0" = 48;
|
||||
"1" = 49;
|
||||
"2" = 50;
|
||||
"3" = 51;
|
||||
"4" = 52;
|
||||
"5" = 53;
|
||||
"6" = 54;
|
||||
"7" = 55;
|
||||
"8" = 56;
|
||||
"9" = 57;
|
||||
":" = 58;
|
||||
";" = 59;
|
||||
"<" = 60;
|
||||
"=" = 61;
|
||||
">" = 62;
|
||||
"?" = 63;
|
||||
"@" = 64;
|
||||
"A" = 65;
|
||||
"B" = 66;
|
||||
"C" = 67;
|
||||
"D" = 68;
|
||||
"E" = 69;
|
||||
"F" = 70;
|
||||
"G" = 71;
|
||||
"H" = 72;
|
||||
"I" = 73;
|
||||
"J" = 74;
|
||||
"K" = 75;
|
||||
"L" = 76;
|
||||
"M" = 77;
|
||||
"N" = 78;
|
||||
"O" = 79;
|
||||
"P" = 80;
|
||||
"Q" = 81;
|
||||
"R" = 82;
|
||||
"S" = 83;
|
||||
"T" = 84;
|
||||
"U" = 85;
|
||||
"V" = 86;
|
||||
"W" = 87;
|
||||
"X" = 88;
|
||||
"Y" = 89;
|
||||
"Z" = 90;
|
||||
"[" = 91;
|
||||
"\\" = 92;
|
||||
"]" = 93;
|
||||
"^" = 94;
|
||||
"_" = 95;
|
||||
"`" = 96;
|
||||
"a" = 97;
|
||||
"b" = 98;
|
||||
"c" = 99;
|
||||
"d" = 100;
|
||||
"e" = 101;
|
||||
"f" = 102;
|
||||
"g" = 103;
|
||||
"h" = 104;
|
||||
"i" = 105;
|
||||
"j" = 106;
|
||||
"k" = 107;
|
||||
"l" = 108;
|
||||
"m" = 109;
|
||||
"n" = 110;
|
||||
"o" = 111;
|
||||
"p" = 112;
|
||||
"q" = 113;
|
||||
"r" = 114;
|
||||
"s" = 115;
|
||||
"t" = 116;
|
||||
"u" = 117;
|
||||
"v" = 118;
|
||||
"w" = 119;
|
||||
"x" = 120;
|
||||
"y" = 121;
|
||||
"z" = 122;
|
||||
"{" = 123;
|
||||
"|" = 124;
|
||||
"}" = 125;
|
||||
"~" = 126;
|
||||
}
|
||||
@@ -16,11 +16,15 @@ rec {
|
||||
assertMsg :: Bool -> String -> Bool
|
||||
*/
|
||||
# TODO(Profpatsch): add tests that check stderr
|
||||
assertMsg = pred: msg:
|
||||
assertMsg =
|
||||
# Predicate that needs to succeed, otherwise `msg` is thrown
|
||||
pred:
|
||||
# Message to throw in case `pred` fails
|
||||
msg:
|
||||
pred || builtins.throw msg;
|
||||
|
||||
/* Specialized `assertMsg` for checking if val is one of the elements
|
||||
of a list. Useful for checking enums.
|
||||
/* Specialized `assertMsg` for checking if `val` is one of the elements
|
||||
of the list `xs`. Useful for checking enums.
|
||||
|
||||
Example:
|
||||
let sslLibrary = "libressl";
|
||||
@@ -33,7 +37,14 @@ rec {
|
||||
Type:
|
||||
assertOneOf :: String -> ComparableVal -> List ComparableVal -> Bool
|
||||
*/
|
||||
assertOneOf = name: val: xs: assertMsg
|
||||
assertOneOf =
|
||||
# The name of the variable the user entered `val` into, for inclusion in the error message
|
||||
name:
|
||||
# The value of what the user provided, to be compared against the values in `xs`
|
||||
val:
|
||||
# The list of valid values
|
||||
xs:
|
||||
assertMsg
|
||||
(lib.elem val xs)
|
||||
"${name} must be one of ${
|
||||
lib.generators.toPretty {} xs}, but is: ${
|
||||
|
||||
476
lib/attrsets.nix
476
lib/attrsets.nix
@@ -3,7 +3,7 @@
|
||||
|
||||
let
|
||||
inherit (builtins) head tail length;
|
||||
inherit (lib.trivial) id;
|
||||
inherit (lib.trivial) flip id mergeAttrs pipe;
|
||||
inherit (lib.strings) concatStringsSep concatMapStringsSep escapeNixIdentifier sanitizeDerivationName;
|
||||
inherit (lib.lists) foldr foldl' concatMap concatLists elemAt all partition groupBy take foldl;
|
||||
in
|
||||
@@ -20,13 +20,22 @@ rec {
|
||||
=> 3
|
||||
attrByPath ["z" "z"] 6 x
|
||||
=> 6
|
||||
|
||||
Type:
|
||||
attrByPath :: [String] -> Any -> AttrSet -> Any
|
||||
*/
|
||||
attrByPath = attrPath: default: e:
|
||||
attrByPath =
|
||||
# A list of strings representing the attribute path to return from `set`
|
||||
attrPath:
|
||||
# Default value if `attrPath` does not resolve to an existing value
|
||||
default:
|
||||
# The nested attribute set to select values from
|
||||
set:
|
||||
let attr = head attrPath;
|
||||
in
|
||||
if attrPath == [] then e
|
||||
else if e ? ${attr}
|
||||
then attrByPath (tail attrPath) default e.${attr}
|
||||
if attrPath == [] then set
|
||||
else if set ? ${attr}
|
||||
then attrByPath (tail attrPath) default set.${attr}
|
||||
else default;
|
||||
|
||||
/* Return if an attribute from nested attribute set exists.
|
||||
@@ -38,8 +47,14 @@ rec {
|
||||
hasAttrByPath ["z" "z"] x
|
||||
=> false
|
||||
|
||||
Type:
|
||||
hasAttrByPath :: [String] -> AttrSet -> Bool
|
||||
*/
|
||||
hasAttrByPath = attrPath: e:
|
||||
hasAttrByPath =
|
||||
# A list of strings representing the attribute path to check from `set`
|
||||
attrPath:
|
||||
# The nested attribute set to check
|
||||
e:
|
||||
let attr = head attrPath;
|
||||
in
|
||||
if attrPath == [] then true
|
||||
@@ -48,13 +63,20 @@ rec {
|
||||
else false;
|
||||
|
||||
|
||||
/* Return nested attribute set in which an attribute is set.
|
||||
/* Create a new attribute set with `value` set at the nested attribute location specified in `attrPath`.
|
||||
|
||||
Example:
|
||||
setAttrByPath ["a" "b"] 3
|
||||
=> { a = { b = 3; }; }
|
||||
|
||||
Type:
|
||||
setAttrByPath :: [String] -> Any -> AttrSet
|
||||
*/
|
||||
setAttrByPath = attrPath: value:
|
||||
setAttrByPath =
|
||||
# A list of strings representing the attribute path to set
|
||||
attrPath:
|
||||
# The value to set at the location described by `attrPath`
|
||||
value:
|
||||
let
|
||||
len = length attrPath;
|
||||
atDepth = n:
|
||||
@@ -63,8 +85,8 @@ rec {
|
||||
else { ${elemAt attrPath n} = atDepth (n + 1); };
|
||||
in atDepth 0;
|
||||
|
||||
/* Like `attrByPath' without a default value. If it doesn't find the
|
||||
path it will throw.
|
||||
/* Like `attrByPath', but without a default value. If it doesn't find the
|
||||
path it will throw an error.
|
||||
|
||||
Example:
|
||||
x = { a = { b = 3; }; }
|
||||
@@ -72,29 +94,59 @@ rec {
|
||||
=> 3
|
||||
getAttrFromPath ["z" "z"] x
|
||||
=> error: cannot find attribute `z.z'
|
||||
|
||||
Type:
|
||||
getAttrFromPath :: [String] -> AttrSet -> Value
|
||||
*/
|
||||
getAttrFromPath = attrPath:
|
||||
getAttrFromPath =
|
||||
# A list of strings representing the attribute path to get from `set`
|
||||
attrPath:
|
||||
# The nested attribute set to find the value in.
|
||||
set:
|
||||
let errorMsg = "cannot find attribute `" + concatStringsSep "." attrPath + "'";
|
||||
in attrByPath attrPath (abort errorMsg);
|
||||
in attrByPath attrPath (abort errorMsg) set;
|
||||
|
||||
/* Map each attribute in the given set and merge them into a new attribute set.
|
||||
|
||||
Type:
|
||||
concatMapAttrs ::
|
||||
(String -> a -> AttrSet)
|
||||
-> AttrSet
|
||||
-> AttrSet
|
||||
|
||||
Example:
|
||||
concatMapAttrs
|
||||
(name: value: {
|
||||
${name} = value;
|
||||
${name + value} = value;
|
||||
})
|
||||
{ x = "a"; y = "b"; }
|
||||
=> { x = "a"; xa = "a"; y = "b"; yb = "b"; }
|
||||
*/
|
||||
concatMapAttrs = f: flip pipe [ (mapAttrs f) attrValues (foldl' mergeAttrs { }) ];
|
||||
|
||||
|
||||
/* Update or set specific paths of an attribute set.
|
||||
|
||||
Takes a list of updates to apply and an attribute set to apply them to,
|
||||
and returns the attribute set with the updates applied. Updates are
|
||||
represented as { path = ...; update = ...; } values, where `path` is a
|
||||
represented as `{ path = ...; update = ...; }` values, where `path` is a
|
||||
list of strings representing the attribute path that should be updated,
|
||||
and `update` is a function that takes the old value at that attribute path
|
||||
as an argument and returns the new
|
||||
value it should be.
|
||||
|
||||
Properties:
|
||||
|
||||
- Updates to deeper attribute paths are applied before updates to more
|
||||
shallow attribute paths
|
||||
|
||||
- Multiple updates to the same attribute path are applied in the order
|
||||
they appear in the update list
|
||||
|
||||
- If any but the last `path` element leads into a value that is not an
|
||||
attribute set, an error is thrown
|
||||
|
||||
- If there is an update for an attribute path that doesn't exist,
|
||||
accessing the argument in the update function causes an error, but
|
||||
intermediate attribute sets are implicitly created as needed
|
||||
@@ -115,6 +167,9 @@ rec {
|
||||
}
|
||||
] { a.b.c = 0; }
|
||||
=> { a = { b = { d = 1; }; }; x = { y = "xy"; }; }
|
||||
|
||||
Type:
|
||||
updateManyAttrsByPath :: [AttrSet] -> AttrSet -> AttrSet
|
||||
*/
|
||||
updateManyAttrsByPath = let
|
||||
# When recursing into attributes, instead of updating the `path` of each
|
||||
@@ -180,8 +235,15 @@ rec {
|
||||
Example:
|
||||
attrVals ["a" "b" "c"] as
|
||||
=> [as.a as.b as.c]
|
||||
|
||||
Type:
|
||||
attrVals :: [String] -> AttrSet -> [Any]
|
||||
*/
|
||||
attrVals = nameList: set: map (x: set.${x}) nameList;
|
||||
attrVals =
|
||||
# The list of attributes to fetch from `set`. Each attribute name must exist on the attrbitue set
|
||||
nameList:
|
||||
# The set to get attribute values from
|
||||
set: map (x: set.${x}) nameList;
|
||||
|
||||
|
||||
/* Return the values of all attributes in the given set, sorted by
|
||||
@@ -190,6 +252,8 @@ rec {
|
||||
Example:
|
||||
attrValues {c = 3; a = 1; b = 2;}
|
||||
=> [1 2 3]
|
||||
Type:
|
||||
attrValues :: AttrSet -> [Any]
|
||||
*/
|
||||
attrValues = builtins.attrValues or (attrs: attrVals (attrNames attrs) attrs);
|
||||
|
||||
@@ -200,8 +264,15 @@ rec {
|
||||
Example:
|
||||
getAttrs [ "a" "b" ] { a = 1; b = 2; c = 3; }
|
||||
=> { a = 1; b = 2; }
|
||||
|
||||
Type:
|
||||
getAttrs :: [String] -> AttrSet -> AttrSet
|
||||
*/
|
||||
getAttrs = names: attrs: genAttrs names (name: attrs.${name});
|
||||
getAttrs =
|
||||
# A list of attribute names to get out of `set`
|
||||
names:
|
||||
# The set to get the named attributes from
|
||||
attrs: genAttrs names (name: attrs.${name});
|
||||
|
||||
/* Collect each attribute named `attr' from a list of attribute
|
||||
sets. Sets that don't contain the named attribute are ignored.
|
||||
@@ -209,6 +280,9 @@ rec {
|
||||
Example:
|
||||
catAttrs "a" [{a = 1;} {b = 0;} {a = 2;}]
|
||||
=> [1 2]
|
||||
|
||||
Type:
|
||||
catAttrs :: String -> [AttrSet] -> [Any]
|
||||
*/
|
||||
catAttrs = builtins.catAttrs or
|
||||
(attr: l: concatLists (map (s: if s ? ${attr} then [s.${attr}] else []) l));
|
||||
@@ -220,8 +294,15 @@ rec {
|
||||
Example:
|
||||
filterAttrs (n: v: n == "foo") { foo = 1; bar = 2; }
|
||||
=> { foo = 1; }
|
||||
|
||||
Type:
|
||||
filterAttrs :: (String -> Any -> Bool) -> AttrSet -> AttrSet
|
||||
*/
|
||||
filterAttrs = pred: set:
|
||||
filterAttrs =
|
||||
# Predicate taking an attribute name and an attribute value, which returns `true` to include the attribute, or `false` to exclude the attribute.
|
||||
pred:
|
||||
# The attribute set to filter
|
||||
set:
|
||||
listToAttrs (concatMap (name: let v = set.${name}; in if pred name v then [(nameValuePair name v)] else []) (attrNames set));
|
||||
|
||||
|
||||
@@ -231,8 +312,15 @@ rec {
|
||||
Example:
|
||||
filterAttrsRecursive (n: v: v != null) { foo = { bar = null; }; }
|
||||
=> { foo = {}; }
|
||||
|
||||
Type:
|
||||
filterAttrsRecursive :: (String -> Any -> Bool) -> AttrSet -> AttrSet
|
||||
*/
|
||||
filterAttrsRecursive = pred: set:
|
||||
filterAttrsRecursive =
|
||||
# Predicate taking an attribute name and an attribute value, which returns `true` to include the attribute, or `false` to exclude the attribute.
|
||||
pred:
|
||||
# The attribute set to filter
|
||||
set:
|
||||
listToAttrs (
|
||||
concatMap (name:
|
||||
let v = set.${name}; in
|
||||
@@ -250,23 +338,28 @@ rec {
|
||||
Example:
|
||||
foldAttrs (item: acc: [item] ++ acc) [] [{ a = 2; } { a = 3; }]
|
||||
=> { a = [ 2 3 ]; }
|
||||
|
||||
Type:
|
||||
foldAttrs :: (Any -> Any -> Any) -> Any -> [AttrSets] -> Any
|
||||
*/
|
||||
foldAttrs = op: nul:
|
||||
foldAttrs =
|
||||
# A function, given a value and a collector combines the two.
|
||||
op:
|
||||
# The starting value.
|
||||
nul:
|
||||
# A list of attribute sets to fold together by key.
|
||||
list_of_attrs:
|
||||
foldr (n: a:
|
||||
foldr (name: o:
|
||||
o // { ${name} = op n.${name} (a.${name} or nul); }
|
||||
) a (attrNames n)
|
||||
) {};
|
||||
) {} list_of_attrs;
|
||||
|
||||
|
||||
/* Recursively collect sets that verify a given predicate named `pred'
|
||||
from the set `attrs'. The recursion is stopped when the predicate is
|
||||
verified.
|
||||
|
||||
Type:
|
||||
collect ::
|
||||
(AttrSet -> Bool) -> AttrSet -> [x]
|
||||
|
||||
Example:
|
||||
collect isList { a = { b = ["b"]; }; c = [1]; }
|
||||
=> [["b"] [1]]
|
||||
@@ -274,8 +367,15 @@ rec {
|
||||
collect (x: x ? outPath)
|
||||
{ a = { outPath = "a/"; }; b = { outPath = "b/"; }; }
|
||||
=> [{ outPath = "a/"; } { outPath = "b/"; }]
|
||||
|
||||
Type:
|
||||
collect :: (AttrSet -> Bool) -> AttrSet -> [x]
|
||||
*/
|
||||
collect = pred: attrs:
|
||||
collect =
|
||||
# Given an attribute's value, determine if recursion should stop.
|
||||
pred:
|
||||
# The attribute set to recursively collect.
|
||||
attrs:
|
||||
if pred attrs then
|
||||
[ attrs ]
|
||||
else if isAttrs attrs then
|
||||
@@ -293,8 +393,12 @@ rec {
|
||||
{ a = 2; b = 10; }
|
||||
{ a = 2; b = 20; }
|
||||
]
|
||||
Type:
|
||||
cartesianProductOfSets :: AttrSet -> [AttrSet]
|
||||
*/
|
||||
cartesianProductOfSets = attrsOfLists:
|
||||
cartesianProductOfSets =
|
||||
# Attribute set with attributes that are lists of values
|
||||
attrsOfLists:
|
||||
foldl' (listOfAttrs: attrName:
|
||||
concatMap (attrs:
|
||||
map (listValue: attrs // { ${attrName} = listValue; }) attrsOfLists.${attrName}
|
||||
@@ -302,25 +406,32 @@ rec {
|
||||
) [{}] (attrNames attrsOfLists);
|
||||
|
||||
|
||||
/* Utility function that creates a {name, value} pair as expected by
|
||||
builtins.listToAttrs.
|
||||
/* Utility function that creates a `{name, value}` pair as expected by `builtins.listToAttrs`.
|
||||
|
||||
Example:
|
||||
nameValuePair "some" 6
|
||||
=> { name = "some"; value = 6; }
|
||||
|
||||
Type:
|
||||
nameValuePair :: String -> Any -> AttrSet
|
||||
*/
|
||||
nameValuePair = name: value: { inherit name value; };
|
||||
nameValuePair =
|
||||
# Attribute name
|
||||
name:
|
||||
# Attribute value
|
||||
value:
|
||||
{ inherit name value; };
|
||||
|
||||
|
||||
/* Apply a function to each element in an attribute set. The
|
||||
function takes two arguments --- the attribute name and its value
|
||||
--- and returns the new value for the attribute. The result is a
|
||||
new attribute set.
|
||||
/* Apply a function to each element in an attribute set, creating a new attribute set.
|
||||
|
||||
Example:
|
||||
mapAttrs (name: value: name + "-" + value)
|
||||
{ x = "foo"; y = "bar"; }
|
||||
=> { x = "x-foo"; y = "y-bar"; }
|
||||
|
||||
Type:
|
||||
mapAttrs :: (String -> Any -> Any) -> AttrSet -> AttrSet
|
||||
*/
|
||||
mapAttrs = builtins.mapAttrs or
|
||||
(f: set:
|
||||
@@ -335,24 +446,35 @@ rec {
|
||||
mapAttrs' (name: value: nameValuePair ("foo_" + name) ("bar-" + value))
|
||||
{ x = "a"; y = "b"; }
|
||||
=> { foo_x = "bar-a"; foo_y = "bar-b"; }
|
||||
|
||||
Type:
|
||||
mapAttrs' :: (String -> Any -> { name = String; value = Any }) -> AttrSet -> AttrSet
|
||||
*/
|
||||
mapAttrs' = f: set:
|
||||
mapAttrs' =
|
||||
# A function, given an attribute's name and value, returns a new `nameValuePair`.
|
||||
f:
|
||||
# Attribute set to map over.
|
||||
set:
|
||||
listToAttrs (map (attr: f attr set.${attr}) (attrNames set));
|
||||
|
||||
|
||||
/* Call a function for each attribute in the given set and return
|
||||
the result in a list.
|
||||
|
||||
Type:
|
||||
mapAttrsToList ::
|
||||
(String -> a -> b) -> AttrSet -> [b]
|
||||
|
||||
Example:
|
||||
mapAttrsToList (name: value: name + value)
|
||||
{ x = "a"; y = "b"; }
|
||||
=> [ "xa" "yb" ]
|
||||
|
||||
Type:
|
||||
mapAttrsToList :: (String -> a -> b) -> AttrSet -> [b]
|
||||
|
||||
*/
|
||||
mapAttrsToList = f: attrs:
|
||||
mapAttrsToList =
|
||||
# A function, given an attribute's name and value, returns a new value.
|
||||
f:
|
||||
# Attribute set to map over.
|
||||
attrs:
|
||||
map (name: f name attrs.${name}) (attrNames attrs);
|
||||
|
||||
|
||||
@@ -360,16 +482,20 @@ rec {
|
||||
attribute sets. Also, the first argument of the argument
|
||||
function is a *list* of the names of the containing attributes.
|
||||
|
||||
Type:
|
||||
mapAttrsRecursive ::
|
||||
([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
|
||||
Example:
|
||||
mapAttrsRecursive (path: value: concatStringsSep "-" (path ++ [value]))
|
||||
{ n = { a = "A"; m = { b = "B"; c = "C"; }; }; d = "D"; }
|
||||
=> { n = { a = "n-a-A"; m = { b = "n-m-b-B"; c = "n-m-c-C"; }; }; d = "d-D"; }
|
||||
|
||||
Type:
|
||||
mapAttrsRecursive :: ([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
*/
|
||||
mapAttrsRecursive = mapAttrsRecursiveCond (as: true);
|
||||
mapAttrsRecursive =
|
||||
# A function, given a list of attribute names and a value, returns a new value.
|
||||
f:
|
||||
# Set to recursively map over.
|
||||
set:
|
||||
mapAttrsRecursiveCond (as: true) f set;
|
||||
|
||||
|
||||
/* Like `mapAttrsRecursive', but it takes an additional predicate
|
||||
@@ -378,10 +504,6 @@ rec {
|
||||
recurse, but does apply the map function. If it returns true, it
|
||||
does recurse, and does not apply the map function.
|
||||
|
||||
Type:
|
||||
mapAttrsRecursiveCond ::
|
||||
(AttrSet -> Bool) -> ([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
|
||||
Example:
|
||||
# To prevent recursing into derivations (which are attribute
|
||||
# sets with the attribute "type" equal to "derivation"):
|
||||
@@ -389,8 +511,17 @@ rec {
|
||||
(as: !(as ? "type" && as.type == "derivation"))
|
||||
(x: ... do something ...)
|
||||
attrs
|
||||
|
||||
Type:
|
||||
mapAttrsRecursiveCond :: (AttrSet -> Bool) -> ([String] -> a -> b) -> AttrSet -> AttrSet
|
||||
*/
|
||||
mapAttrsRecursiveCond = cond: f: set:
|
||||
mapAttrsRecursiveCond =
|
||||
# A function, given the attribute set the recursion is currently at, determine if to recurse deeper into that attribute set.
|
||||
cond:
|
||||
# A function, given a list of attribute names and a value, returns a new value.
|
||||
f:
|
||||
# Attribute set to recursively map over.
|
||||
set:
|
||||
let
|
||||
recurse = path:
|
||||
let
|
||||
@@ -409,13 +540,20 @@ rec {
|
||||
Example:
|
||||
genAttrs [ "foo" "bar" ] (name: "x_" + name)
|
||||
=> { foo = "x_foo"; bar = "x_bar"; }
|
||||
|
||||
Type:
|
||||
genAttrs :: [ String ] -> (String -> Any) -> AttrSet
|
||||
*/
|
||||
genAttrs = names: f:
|
||||
genAttrs =
|
||||
# Names of values in the resulting attribute set.
|
||||
names:
|
||||
# A function, given the name of the attribute, returns the attribute's value.
|
||||
f:
|
||||
listToAttrs (map (n: nameValuePair n (f n)) names);
|
||||
|
||||
|
||||
/* Check whether the argument is a derivation. Any set with
|
||||
{ type = "derivation"; } counts as a derivation.
|
||||
`{ type = "derivation"; }` counts as a derivation.
|
||||
|
||||
Example:
|
||||
nixpkgs = import <nixpkgs> {}
|
||||
@@ -423,25 +561,36 @@ rec {
|
||||
=> true
|
||||
isDerivation "foobar"
|
||||
=> false
|
||||
*/
|
||||
isDerivation = x: x.type or null == "derivation";
|
||||
|
||||
/* Converts a store path to a fake derivation. */
|
||||
toDerivation = path:
|
||||
let
|
||||
path' = builtins.storePath path;
|
||||
res =
|
||||
{ type = "derivation";
|
||||
name = sanitizeDerivationName (builtins.substring 33 (-1) (baseNameOf path'));
|
||||
outPath = path';
|
||||
outputs = [ "out" ];
|
||||
out = res;
|
||||
outputName = "out";
|
||||
};
|
||||
Type:
|
||||
isDerivation :: Any -> Bool
|
||||
*/
|
||||
isDerivation =
|
||||
# Value to check.
|
||||
value: value.type or null == "derivation";
|
||||
|
||||
/* Converts a store path to a fake derivation.
|
||||
|
||||
Type:
|
||||
toDerivation :: Path -> Derivation
|
||||
*/
|
||||
toDerivation =
|
||||
# A store path to convert to a derivation.
|
||||
path:
|
||||
let
|
||||
path' = builtins.storePath path;
|
||||
res =
|
||||
{ type = "derivation";
|
||||
name = sanitizeDerivationName (builtins.substring 33 (-1) (baseNameOf path'));
|
||||
outPath = path';
|
||||
outputs = [ "out" ];
|
||||
out = res;
|
||||
outputName = "out";
|
||||
};
|
||||
in res;
|
||||
|
||||
|
||||
/* If `cond' is true, return the attribute set `as',
|
||||
/* If `cond` is true, return the attribute set `as`,
|
||||
otherwise an empty attribute set.
|
||||
|
||||
Example:
|
||||
@@ -449,47 +598,82 @@ rec {
|
||||
=> { my = "set"; }
|
||||
optionalAttrs (false) { my = "set"; }
|
||||
=> { }
|
||||
|
||||
Type:
|
||||
optionalAttrs :: Bool -> AttrSet
|
||||
*/
|
||||
optionalAttrs = cond: as: if cond then as else {};
|
||||
optionalAttrs =
|
||||
# Condition under which the `as` attribute set is returned.
|
||||
cond:
|
||||
# The attribute set to return if `cond` is `true`.
|
||||
as:
|
||||
if cond then as else {};
|
||||
|
||||
|
||||
/* Merge sets of attributes and use the function f to merge attributes
|
||||
/* Merge sets of attributes and use the function `f` to merge attributes
|
||||
values.
|
||||
|
||||
Example:
|
||||
zipAttrsWithNames ["a"] (name: vs: vs) [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; }
|
||||
|
||||
Type:
|
||||
zipAttrsWithNames :: [ String ] -> (String -> [ Any ] -> Any) -> [ AttrSet ] -> AttrSet
|
||||
*/
|
||||
zipAttrsWithNames = names: f: sets:
|
||||
zipAttrsWithNames =
|
||||
# List of attribute names to zip.
|
||||
names:
|
||||
# A function, accepts an attribute name, all the values, and returns a combined value.
|
||||
f:
|
||||
# List of values from the list of attribute sets.
|
||||
sets:
|
||||
listToAttrs (map (name: {
|
||||
inherit name;
|
||||
value = f name (catAttrs name sets);
|
||||
}) names);
|
||||
|
||||
/* Implementation note: Common names appear multiple times in the list of
|
||||
|
||||
/* Merge sets of attributes and use the function f to merge attribute values.
|
||||
Like `lib.attrsets.zipAttrsWithNames` with all key names are passed for `names`.
|
||||
|
||||
Implementation note: Common names appear multiple times in the list of
|
||||
names, hopefully this does not affect the system because the maximal
|
||||
laziness avoid computing twice the same expression and listToAttrs does
|
||||
laziness avoid computing twice the same expression and `listToAttrs` does
|
||||
not care about duplicated attribute names.
|
||||
|
||||
Example:
|
||||
zipAttrsWith (name: values: values) [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
|
||||
Type:
|
||||
zipAttrsWith :: (String -> [ Any ] -> Any) -> [ AttrSet ] -> AttrSet
|
||||
*/
|
||||
zipAttrsWith =
|
||||
builtins.zipAttrsWith or (f: sets: zipAttrsWithNames (concatMap attrNames sets) f sets);
|
||||
/* Like `zipAttrsWith' with `(name: values: values)' as the function.
|
||||
|
||||
Example:
|
||||
zipAttrs [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
|
||||
/* Merge sets of attributes and combine each attribute value in to a list.
|
||||
|
||||
Like `lib.attrsets.zipAttrsWith' with `(name: values: values)' as the function.
|
||||
|
||||
Example:
|
||||
zipAttrs [{a = "x";} {a = "y"; b = "z";}]
|
||||
=> { a = ["x" "y"]; b = ["z"] }
|
||||
|
||||
Type:
|
||||
zipAttrs :: [ AttrSet ] -> AttrSet
|
||||
*/
|
||||
zipAttrs = zipAttrsWith (name: values: values);
|
||||
zipAttrs =
|
||||
# List of attribute sets to zip together.
|
||||
sets:
|
||||
zipAttrsWith (name: values: values) sets;
|
||||
|
||||
|
||||
/* Does the same as the update operator '//' except that attributes are
|
||||
merged until the given predicate is verified. The predicate should
|
||||
accept 3 arguments which are the path to reach the attribute, a part of
|
||||
the first attribute set and a part of the second attribute set. When
|
||||
the predicate is verified, the value of the first attribute set is
|
||||
the predicate is satisfied, the value of the first attribute set is
|
||||
replaced by the value of the second attribute set.
|
||||
|
||||
Example:
|
||||
@@ -505,15 +689,23 @@ rec {
|
||||
baz = 4;
|
||||
}
|
||||
|
||||
returns: {
|
||||
=> {
|
||||
foo.bar = 1; # 'foo.*' from the second set
|
||||
foo.quz = 2; #
|
||||
bar = 3; # 'bar' from the first set
|
||||
baz = 4; # 'baz' from the second set
|
||||
}
|
||||
|
||||
*/
|
||||
recursiveUpdateUntil = pred: lhs: rhs:
|
||||
Type:
|
||||
recursiveUpdateUntil :: ( [ String ] -> AttrSet -> AttrSet -> Bool ) -> AttrSet -> AttrSet -> AttrSet
|
||||
*/
|
||||
recursiveUpdateUntil =
|
||||
# Predicate, taking the path to the current attribute as a list of strings for attribute names, and the two values at that path from the original arguments.
|
||||
pred:
|
||||
# Left attribute set of the merge.
|
||||
lhs:
|
||||
# Right attribute set of the merge.
|
||||
rhs:
|
||||
let f = attrPath:
|
||||
zipAttrsWith (n: values:
|
||||
let here = attrPath ++ [n]; in
|
||||
@@ -525,6 +717,7 @@ rec {
|
||||
);
|
||||
in f [] [rhs lhs];
|
||||
|
||||
|
||||
/* A recursive variant of the update operator ‘//’. The recursion
|
||||
stops when one of the attribute values is not an attribute set,
|
||||
in which case the right hand side value takes precedence over the
|
||||
@@ -543,16 +736,32 @@ rec {
|
||||
boot.loader.grub.device = "";
|
||||
}
|
||||
|
||||
*/
|
||||
recursiveUpdate = recursiveUpdateUntil (path: lhs: rhs: !(isAttrs lhs && isAttrs rhs));
|
||||
Type:
|
||||
recursiveUpdate :: AttrSet -> AttrSet -> AttrSet
|
||||
*/
|
||||
recursiveUpdate =
|
||||
# Left attribute set of the merge.
|
||||
lhs:
|
||||
# Right attribute set of the merge.
|
||||
rhs:
|
||||
recursiveUpdateUntil (path: lhs: rhs: !(isAttrs lhs && isAttrs rhs)) lhs rhs;
|
||||
|
||||
|
||||
/* Returns true if the pattern is contained in the set. False otherwise.
|
||||
|
||||
Example:
|
||||
matchAttrs { cpu = {}; } { cpu = { bits = 64; }; }
|
||||
=> true
|
||||
*/
|
||||
matchAttrs = pattern: attrs: assert isAttrs pattern;
|
||||
|
||||
Type:
|
||||
matchAttrs :: AttrSet -> AttrSet -> Bool
|
||||
*/
|
||||
matchAttrs =
|
||||
# Attribute set strucutre to match
|
||||
pattern:
|
||||
# Attribute set to find patterns in
|
||||
attrs:
|
||||
assert isAttrs pattern;
|
||||
all id (attrValues (zipAttrsWithNames (attrNames pattern) (n: values:
|
||||
let pat = head values; val = elemAt values 1; in
|
||||
if length values == 1 then false
|
||||
@@ -560,6 +769,7 @@ rec {
|
||||
else pat == val
|
||||
) [pattern attrs]));
|
||||
|
||||
|
||||
/* Override only the attributes that are already present in the old set
|
||||
useful for deep-overriding.
|
||||
|
||||
@@ -570,10 +780,18 @@ rec {
|
||||
=> { b = 2; }
|
||||
overrideExisting { a = 3; b = 2; } { a = 1; }
|
||||
=> { a = 1; b = 2; }
|
||||
|
||||
Type:
|
||||
overrideExisting :: AttrSet -> AttrSet -> AttrSet
|
||||
*/
|
||||
overrideExisting = old: new:
|
||||
overrideExisting =
|
||||
# Original attribute set
|
||||
old:
|
||||
# Attribute set with attributes to override in `old`.
|
||||
new:
|
||||
mapAttrs (name: value: new.${name} or value) old;
|
||||
|
||||
|
||||
/* Turns a list of strings into a human-readable description of those
|
||||
strings represented as an attribute path. The result of this function is
|
||||
not intended to be machine-readable.
|
||||
@@ -583,44 +801,120 @@ rec {
|
||||
=> "foo.\"10\".bar"
|
||||
showAttrPath []
|
||||
=> "<root attribute path>"
|
||||
|
||||
Type:
|
||||
showAttrPath :: [String] -> String
|
||||
*/
|
||||
showAttrPath = path:
|
||||
showAttrPath =
|
||||
# Attribute path to render to a string
|
||||
path:
|
||||
if path == [] then "<root attribute path>"
|
||||
else concatMapStringsSep "." escapeNixIdentifier path;
|
||||
|
||||
|
||||
/* Get a package output.
|
||||
If no output is found, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput "dev" pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-dev"
|
||||
|
||||
Type:
|
||||
getOutput :: String -> Derivation -> String
|
||||
*/
|
||||
getOutput = output: pkg:
|
||||
if ! pkg ? outputSpecified || ! pkg.outputSpecified
|
||||
then pkg.${output} or pkg.out or pkg
|
||||
else pkg;
|
||||
|
||||
/* Get a package's `bin` output.
|
||||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
*/
|
||||
getBin = getOutput "bin";
|
||||
|
||||
|
||||
/* Get a package's `lib` output.
|
||||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-lib"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
*/
|
||||
getLib = getOutput "lib";
|
||||
|
||||
|
||||
/* Get a package's `dev` output.
|
||||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-dev"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
*/
|
||||
getDev = getOutput "dev";
|
||||
|
||||
|
||||
/* Get a package's `man` output.
|
||||
If the output does not exist, fallback to `.out` and then to the default.
|
||||
|
||||
Example:
|
||||
getOutput pkgs.openssl
|
||||
=> "/nix/store/9rz8gxhzf8sw4kf2j2f1grr49w8zx5vj-openssl-1.0.1r-man"
|
||||
|
||||
Type:
|
||||
getOutput :: Derivation -> String
|
||||
*/
|
||||
getMan = getOutput "man";
|
||||
|
||||
/* Pick the outputs of packages to place in buildInputs */
|
||||
chooseDevOutputs = drvs: builtins.map getDev drvs;
|
||||
/* Pick the outputs of packages to place in `buildInputs` */
|
||||
chooseDevOutputs =
|
||||
# List of packages to pick `dev` outputs from
|
||||
drvs:
|
||||
builtins.map getDev drvs;
|
||||
|
||||
/* Make various Nix tools consider the contents of the resulting
|
||||
attribute set when looking for what to build, find, etc.
|
||||
|
||||
This function only affects a single attribute set; it does not
|
||||
apply itself recursively for nested attribute sets.
|
||||
|
||||
Example:
|
||||
{ pkgs ? import <nixpkgs> {} }:
|
||||
{
|
||||
myTools = pkgs.lib.recurseIntoAttrs {
|
||||
inherit (pkgs) hello figlet;
|
||||
};
|
||||
}
|
||||
|
||||
Type:
|
||||
recurseIntoAttrs :: AttrSet -> AttrSet
|
||||
*/
|
||||
recurseIntoAttrs =
|
||||
attrs: attrs // { recurseForDerivations = true; };
|
||||
# An attribute set to scan for derivations.
|
||||
attrs:
|
||||
attrs // { recurseForDerivations = true; };
|
||||
|
||||
/* Undo the effect of recurseIntoAttrs.
|
||||
|
||||
Type:
|
||||
recurseIntoAttrs :: AttrSet -> AttrSet
|
||||
*/
|
||||
dontRecurseIntoAttrs =
|
||||
attrs: attrs // { recurseForDerivations = false; };
|
||||
# An attribute set to not scan for derivations.
|
||||
attrs:
|
||||
attrs // { recurseForDerivations = false; };
|
||||
|
||||
/* `unionOfDisjoint x y` is equal to `x // y // z` where the
|
||||
attrnames in `z` are the intersection of the attrnames in `x` and
|
||||
@@ -636,9 +930,9 @@ rec {
|
||||
in
|
||||
(x // y) // mask;
|
||||
|
||||
/*** deprecated stuff ***/
|
||||
|
||||
# deprecated
|
||||
zipWithNames = zipAttrsWithNames;
|
||||
# deprecated
|
||||
zip = builtins.trace
|
||||
"lib.zip is deprecated, use lib.zipAttrsWith instead" zipAttrsWith;
|
||||
}
|
||||
|
||||
@@ -38,12 +38,15 @@ rec {
|
||||
//
|
||||
(drv.passthru or {})
|
||||
//
|
||||
(if (drv ? crossDrv && drv ? nativeDrv)
|
||||
then {
|
||||
crossDrv = overrideDerivation drv.crossDrv f;
|
||||
nativeDrv = overrideDerivation drv.nativeDrv f;
|
||||
}
|
||||
else { }));
|
||||
# TODO(@Artturin): remove before release 23.05 and only have __spliced.
|
||||
(lib.optionalAttrs (drv ? crossDrv && drv ? nativeDrv) {
|
||||
crossDrv = overrideDerivation drv.crossDrv f;
|
||||
nativeDrv = overrideDerivation drv.nativeDrv f;
|
||||
})
|
||||
//
|
||||
lib.optionalAttrs (drv ? __spliced) {
|
||||
__spliced = {} // (lib.mapAttrs (_: sDrv: overrideDerivation sDrv f) drv.__spliced);
|
||||
});
|
||||
|
||||
|
||||
/* `makeOverridable` takes a function from attribute set to attribute set and
|
||||
|
||||
@@ -78,7 +78,7 @@ let
|
||||
inherit (self.attrsets) attrByPath hasAttrByPath setAttrByPath
|
||||
getAttrFromPath attrVals attrValues getAttrs catAttrs filterAttrs
|
||||
filterAttrsRecursive foldAttrs collect nameValuePair mapAttrs
|
||||
mapAttrs' mapAttrsToList mapAttrsRecursive mapAttrsRecursiveCond
|
||||
mapAttrs' mapAttrsToList concatMapAttrs mapAttrsRecursive mapAttrsRecursiveCond
|
||||
genAttrs isDerivation toDerivation optionalAttrs
|
||||
zipAttrsWithNames zipAttrsWith zipAttrs recursiveUpdateUntil
|
||||
recursiveUpdate matchAttrs overrideExisting showAttrPath getOutput getBin
|
||||
@@ -101,9 +101,10 @@ let
|
||||
upperChars toLower toUpper addContextFrom splitString
|
||||
removePrefix removeSuffix versionOlder versionAtLeast
|
||||
getName getVersion
|
||||
mesonOption mesonBool mesonEnable
|
||||
nameFromURL enableFeature enableFeatureAs withFeature
|
||||
withFeatureAs fixedWidthString fixedWidthNumber isStorePath
|
||||
toInt readPathsFromFile fileContents;
|
||||
toInt toIntBase10 readPathsFromFile fileContents;
|
||||
inherit (self.stringsWithDeps) textClosureList textClosureMap
|
||||
noDepEntry fullDepEntry packEntry stringAfter;
|
||||
inherit (self.customisation) overrideDerivation makeOverridable
|
||||
|
||||
@@ -157,7 +157,36 @@ rec {
|
||||
}
|
||||
);
|
||||
|
||||
closePropagation = list: (uniqList {inputList = (innerClosePropagation [] list);});
|
||||
closePropagationSlow = list: (uniqList {inputList = (innerClosePropagation [] list);});
|
||||
|
||||
# This is an optimisation of lib.closePropagation which avoids the O(n^2) behavior
|
||||
# Using a list of derivations, it generates the full closure of the propagatedXXXBuildInputs
|
||||
# The ordering / sorting / comparison is done based on the `outPath`
|
||||
# attribute of each derivation.
|
||||
# On some benchmarks, it performs up to 15 times faster than lib.closePropagation.
|
||||
# See https://github.com/NixOS/nixpkgs/pull/194391 for details.
|
||||
closePropagationFast = list:
|
||||
builtins.map (x: x.val) (builtins.genericClosure {
|
||||
startSet = builtins.map (x: {
|
||||
key = x.outPath;
|
||||
val = x;
|
||||
}) (builtins.filter (x: x != null) list);
|
||||
operator = item:
|
||||
if !builtins.isAttrs item.val then
|
||||
[ ]
|
||||
else
|
||||
builtins.concatMap (x:
|
||||
if x != null then [{
|
||||
key = x.outPath;
|
||||
val = x;
|
||||
}] else
|
||||
[ ]) ((item.val.propagatedBuildInputs or [ ])
|
||||
++ (item.val.propagatedNativeBuildInputs or [ ]));
|
||||
});
|
||||
|
||||
closePropagation = if builtins ? genericClosure
|
||||
then closePropagationFast
|
||||
else closePropagationSlow;
|
||||
|
||||
# calls a function (f attr value ) for each record item. returns a list
|
||||
mapAttrsFlatten = f: r: map (attr: f attr r.${attr}) (attrNames r);
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user