Compare commits

..

1 Commits

Author SHA1 Message Date
Sandro
51a9e8c3db nixos/installer: fix defaultText rendering as plain string 2026-06-11 17:24:36 +02:00
17566 changed files with 279746 additions and 440070 deletions

View File

@@ -23,15 +23,15 @@ insert_final_newline = false
# see https://nixos.org/nixpkgs/manual/#chap-conventions
[*.{bash,css,js,json,lock,md,nix,pl,pm,py,rb,sh,ts,xml}]
[*.{bash,css,js,json,lock,md,nix,pl,pm,py,rb,sh,xml}]
indent_style = space
# Match docbook files, set indent width of one
[*.xml]
indent_size = 1
# Match js/json/lockfiles/markdown/nix/ruby/ts files, set indent width of two
[*.{js,json,lock,md,nix,rb,ts}]
# Match json/lockfiles/markdown/nix/ruby files, set indent width of two
[*.{js,json,lock,md,nix,rb}]
indent_size = 2
# Match all the Bash code in Nix files, set indent width of two
@@ -79,7 +79,7 @@ indent_size = unset
trim_trailing_whitespace = true
# binaries
[*.{nib,torrent}]
[*.nib]
end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset

3
.gitattributes vendored
View File

@@ -62,6 +62,3 @@ ci/OWNERS linguist-language=CODEOWNERS
# patching CRLF line endings from an upstream source package.
*.diff !text !eol
*.patch !text !eol
# Torrent files are binary files and should not be re-encoded.
*.torrent !text !eol

View File

@@ -56,12 +56,12 @@ body:
description: |
Can [Hydra](https://hydra.nixos.org), Nixpkgs' Continuous Integration system, reproduce this build failure?
Please use the search function in the header bar to locate the last build job for the package in question.
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/subprojects/hydra/root/static/images/emojione-red-x-274c.svg" width="20px" align="top" alt="Red X"> icon near the package entry, say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/subprojects/hydra/root/static/images/emojione-gray-x-2716.svg" width="20px" align="top" alt="Dark Gray X"> icon near the package entry, then the build failure occurs with another package, and you need to track the original failing package by going down the chain of 'Cached failures' until you reach the final package in the failing dependency chain. Once you locate the failing package, re-write this report against that package and say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/subprojects/hydra/root/static/images/emojione-check-2714.svg" width="20px" align="top" alt="Green Check Mark"> icon near the package entry, then it most likely means it's a local issue with your system. (Maybe you ran out of space?)
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-red-x-274c.svg" width="20px" align="top" alt="Red X"> icon near the package entry, say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-gray-x-2716.svg" width="20px" align="top" alt="Dark Gray X"> icon near the package entry, then the build failure occurs with another package, and you need to track the original failing package by going down the chain of 'Cached failures' until you reach the final package in the failing dependency chain. Once you locate the failing package, re-write this report against that package and say '**Yes, Hydra can reproduce this build failure.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-check-2714.svg" width="20px" align="top" alt="Green Check Mark"> icon near the package entry, then it most likely means it's a local issue with your system. (Maybe you ran out of space?)
You can still open a build failure report, but please say '**No, Hydra cannot reproduce this build failure.**' below.
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/subprojects/hydra/root/static/images/emojione-question-2754.svg" width="20px" align="top" alt="Gray Question Mark"> icon near the package entry, say '**Hydra is currently rebuilding this package.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/subprojects/hydra/root/static/images/emojione-stopsign-1f6d1.svg" width="20px" align="top" alt="Red Stop Sign"> icon near the package entry, then the build job was stopped manually. If this occurs, please coordinate with the [Infrastructure Team](https://matrix.to/#/#infra:nixos.org), and say '**The last build job was manually cancelled.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-question-2754.svg" width="20px" align="top" alt="Gray Question Mark"> icon near the package entry, say '**Hydra is currently rebuilding this package.**'
- If there's a <img src="https://raw.githubusercontent.com/NixOS/hydra/refs/heads/master/src/root/static/images/emojione-stopsign-1f6d1.svg" width="20px" align="top" alt="Red Stop Sign"> icon near the package entry, then the build job was stopped manually. If this occurs, please coordinate with the [Infrastructure Team](https://matrix.to/#/#infra:nixos.org), and say '**The last build job was manually cancelled.**'
- If Hydra isn't supposed to build the package at all, say '**Hydra doesnt try to build the package.**'
options:
- "Please select the Hydra Status."

View File

@@ -13,6 +13,7 @@ For new packages please briefly describe the package or provide a link to its ho
- Built on platform:
- [ ] x86_64-linux
- [ ] aarch64-linux
- [ ] x86_64-darwin
- [ ] aarch64-darwin
- Tested, as applicable:
- [ ] [NixOS tests] in [nixos/tests].

View File

@@ -13,13 +13,12 @@ inputs:
runs:
using: composite
steps:
- uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
- uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd # v8.0.0
env:
MERGED_SHA: ${{ inputs.merged-as-untrusted-at }}
TARGET_SHA: ${{ inputs.target-as-trusted-at }}
PIN_BUMP_SHA: ${{ inputs.untrusted-pin-bump }}
with:
retries: 3
script: |
const { rm, writeFile } = require('node:fs/promises')
const { spawn } = require('node:child_process')

View File

@@ -1,9 +1,7 @@
version: 2
updates:
- package-ecosystem: "github-actions"
directories:
- "/"
- ".github/actions/*/*"
directory: "/"
schedule:
interval: "weekly"
labels: []

View File

@@ -22,6 +22,17 @@
- doc/**/*
- nixos/doc/**/*
"backport release-25.11":
- all:
- changed-files:
- any-glob-to-any-file:
- .github/actions/**/*
- .github/workflows/*
- .github/labeler*.yml
- ci/**/*.*
- maintainers/github-teams.json
- base-branch: ['master']
"backport release-26.05":
- all:
- changed-files:

20
.github/labeler.yml vendored
View File

@@ -43,6 +43,14 @@
- .github/**/*
- ci/**/*.*
"6.topic: coq":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/applications/science/logic/coq/**/*
- pkgs/development/coq-modules/**/*
- pkgs/top-level/coq-packages.nix
"6.topic: COSMIC":
- any:
- changed-files:
@@ -458,18 +466,6 @@
- any-glob-to-any-file:
- pkgs/development/rocm-modules/**/*
"6.topic: rocq":
- any:
- changed-files:
- any-glob-to-any-file:
- pkgs/applications/science/logic/coq/**/*
- pkgs/applications/science/logic/rocq-core/**/*
- pkgs/build-support/coq/**/*
- pkgs/build-support/rocq/**/*
- pkgs/development/rocq-modules/**/*
- pkgs/top-level/coq-packages.nix
- pkgs/top-level/rocq-packages.nix
"6.topic: ruby":
- any:
- changed-files:

View File

@@ -39,8 +39,6 @@ jobs:
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
with:
ref: ${{ github.event.pull_request.head.sha }}
# Avoid materializing full nixpkgs tree
sparse-checkout: .
token: ${{ steps.app-token.outputs.token }}
persist-credentials: true
@@ -51,7 +49,7 @@ jobs:
- name: Create backport PRs
id: backport
uses: korthout/backport-action@2e830a1d0b8269505846ddd407a70876913ad1f8 # v4.6.0
uses: korthout/backport-action@66065406958f46e82238fd59546f5a99e69e22aa # v4.5.2
with:
# Config README: https://github.com/korthout/backport-action#backport-action
add_author_as_reviewer: true

View File

@@ -41,6 +41,10 @@ jobs:
run:
runs-on: ubuntu-slim
if: github.event_name != 'schedule' || github.repository_owner == 'NixOS'
env:
# TODO: Remove after 2026-03-04, when Node 24 becomes the default.
# https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true"
steps:
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
with:
@@ -49,8 +53,7 @@ jobs:
ci/github-script
- name: Install dependencies
run: npm ci --package-lock-only=false @actions/artifact bottleneck
working-directory: ci/github-script
run: npm install @actions/artifact@6.2.1 bottleneck@2.19.5
# Use a GitHub App, because it has much higher rate limits: 12,500 instead of 5,000 req / hour.
- uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
@@ -88,7 +91,7 @@ jobs:
GH_TOKEN: ${{ steps.app-token.outputs.token || github.token }}
run: gh api /rate_limit | jq
- uses: actions/labeler@bf12e9b00b37c5c0ca2b87b79b2daf7891dbda13 # v7.0.0
- uses: actions/labeler@f27b608878404679385c85cfa523b85ccb86e213 # v6.1.0
name: Labels from touched files
if: |
github.event_name == 'pull_request_target' &&
@@ -98,7 +101,7 @@ jobs:
configuration-path: .github/labeler.yml # default
sync-labels: true
- uses: actions/labeler@bf12e9b00b37c5c0ca2b87b79b2daf7891dbda13 # v7.0.0
- uses: actions/labeler@f27b608878404679385c85cfa523b85ccb86e213 # v6.1.0
name: Labels from touched files (no sync)
if: |
github.event_name == 'pull_request_target' &&
@@ -108,7 +111,7 @@ jobs:
configuration-path: .github/labeler-no-sync.yml
sync-labels: false
- uses: actions/labeler@bf12e9b00b37c5c0ca2b87b79b2daf7891dbda13 # v7.0.0
- uses: actions/labeler@f27b608878404679385c85cfa523b85ccb86e213 # v6.1.0
name: Labels from touched files (development branches)
# Development branches like staging-next, haskell-updates and python-updates get special labels.
# This is to avoid the mass of labels there, which is mostly useless - and really annoying for

View File

@@ -34,18 +34,21 @@ jobs:
matrix:
include:
- runner: ubuntu-24.04
system: x86_64-linux
name: x86_64-linux
systems: x86_64-linux
builds: [shell, manual-nixos, lib-tests, tarball]
desc: shell, docs, lib, tarball
- runner: ubuntu-24.04-arm
system: aarch64-linux
name: aarch64-linux
systems: aarch64-linux
builds: [shell, manual-nixos, manual-nixpkgs]
desc: shell, docs
- runner: macos-14
system: aarch64-darwin
name: darwin
systems: aarch64-darwin x86_64-darwin
builds: [shell]
desc: shell
name: '${{ matrix.system }}: ${{ matrix.desc }}'
name: '${{ matrix.name }}: ${{ matrix.desc }}'
runs-on: ${{ matrix.runner }}
timeout-minutes: 60
steps:
@@ -59,7 +62,7 @@ jobs:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
target-as-trusted-at: ${{ inputs.targetSha }}
- uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
- uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
with:
# Sandbox is disabled on MacOS by default.
extra_nix_config: sandbox = true
@@ -77,9 +80,7 @@ jobs:
- name: Build shell
if: contains(matrix.builds, 'shell')
env:
system: ${{ matrix.system }}
run: nix-build-uncached nixpkgs/untrusted/ci --arg nixpkgs ./nixpkgs/untrusted-pinned -A shell --argstr system "$system"
run: echo "${{ matrix.systems }}" | xargs -n1 nix-build-uncached nixpkgs/untrusted/ci --arg nixpkgs ./nixpkgs/untrusted-pinned -A shell --argstr system
- name: Build NixOS manual
if: |
@@ -107,5 +108,5 @@ jobs:
contains(fromJSON(inputs.baseBranch).type, 'primary')
uses: actions/upload-artifact@043fb46d1a93c77aae656e7c1c64a875d1fc6a0a # v7.0.1
with:
name: ${{ inputs.artifact-prefix }}nixos-manual-${{ matrix.system }}
name: ${{ inputs.artifact-prefix }}nixos-manual-${{ matrix.name }}
path: nixos-manual

View File

@@ -51,8 +51,7 @@ jobs:
ci/github-script
- name: Install dependencies
run: npm ci --package-lock-only=false bottleneck
working-directory: trusted/ci/github-script
run: npm install bottleneck@2.19.5
- uses: actions/create-github-app-token@bcd2ba49218906704ab6c1aa796996da409d3eb1 # v3.2.0
if: github.event_name != 'pull_request' && vars.NIXPKGS_COMMIT_CHECK_CLIENT_ID
@@ -93,8 +92,8 @@ jobs:
if: inputs.baseBranch && inputs.headBranch
permissions:
pull-requests: write
runs-on: ubuntu-24.04-arm
timeout-minutes: 8
runs-on: ubuntu-slim
timeout-minutes: 3
steps:
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
with:
@@ -134,35 +133,6 @@ jobs:
GH_TOKEN: ${{ steps.app-token.outputs.token || github.token }}
run: gh api /rate_limit | jq
github-script:
runs-on: ubuntu-24.04-arm
timeout-minutes: 5
steps:
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
with:
persist-credentials: false
sparse-checkout: .github/actions
- name: Checkout merge and target commits
uses: ./.github/actions/checkout
with:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
target-as-trusted-at: ${{ inputs.targetSha }}
- name: Install dependencies to trusted/
run: |
npm ci --package-lock-only=false
echo "$PWD/node_modules/.bin" >> "$GITHUB_PATH"
working-directory: nixpkgs/trusted/ci/github-script
- name: Link trusted/ dependencies to untrusted/
run: ln -s "$PWD/trusted/ci/github-script/node_modules" untrusted/ci/github-script/node_modules
working-directory: nixpkgs
- name: Type-check ci/github-script
run: tsc --build
working-directory: nixpkgs/untrusted/ci/github-script
owners:
runs-on: ubuntu-24.04-arm
timeout-minutes: 5
@@ -171,14 +141,13 @@ jobs:
with:
persist-credentials: false
sparse-checkout: .github/actions
- name: Checkout merge and target commits
uses: ./.github/actions/checkout
with:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
target-as-trusted-at: ${{ inputs.targetSha }}
- uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
- uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- uses: cachix/cachix-action@5f2d7c5294214f71b873db4b969586b980625e71 # v17
continue-on-error: true

View File

@@ -15,9 +15,6 @@ on:
targetSha:
required: true
type: string
baseBranch:
required: true
type: string
systems:
required: true
type: string
@@ -139,7 +136,7 @@ jobs:
core.info(`Found pinned.json commit: ${ciPinBumpCommit}`)
- name: Install Nix
uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- name: Load supported versions
id: versions
@@ -187,7 +184,7 @@ jobs:
target-as-trusted-at: ${{ inputs.targetSha }}
- name: Install Nix
uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- uses: cachix/cachix-action@5f2d7c5294214f71b873db4b969586b980625e71 # v17
continue-on-error: true
@@ -277,7 +274,7 @@ jobs:
merge-multiple: true
- name: Install Nix
uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- name: Combine all output paths and eval stats
run: |
@@ -294,7 +291,6 @@ jobs:
- name: Compare against the target branch
env:
TARGET_SHA: ${{ inputs.mergedSha }}
BASE_BRANCH: ${{ fromJSON(inputs.baseBranch).branch }}
run: |
git -C nixpkgs/trusted diff --name-only "$TARGET_SHA" \
| jq --raw-input --slurp 'split("\n")[:-1]' > touched-files.json
@@ -303,7 +299,6 @@ jobs:
nix-build nixpkgs/trusted/ci --arg nixpkgs ./nixpkgs/trusted-pinned -A eval.compare \
--arg combinedDir ./combined \
--arg touchedFilesJson ./touched-files.json \
--argstr baseBranch "$BASE_BRANCH" \
--out-link comparison
cat comparison/step-summary.md >> "$GITHUB_STEP_SUMMARY"
@@ -375,7 +370,7 @@ jobs:
with:
github-token: ${{ steps.app-token.outputs.token || github.token }}
script: |
require('./nixpkgs/trusted/ci/github-script/check-target-branch.ts')({
require('./nixpkgs/trusted/ci/github-script/check-target-branch.js')({
github,
context,
core,
@@ -486,7 +481,7 @@ jobs:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
- name: Install Nix
uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- name: Ensure flake outputs on all systems still evaluate
run: nix flake check --all-systems --no-build './nixpkgs/untrusted?shallow=1'

View File

@@ -35,7 +35,7 @@ jobs:
with:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
- uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
- uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
# TODO: Figure out how to best enable caching for the treefmt job. Cachix won't work well,
# because the cache would be invalidated on every commit - treefmt checks every file.
@@ -70,7 +70,7 @@ jobs:
with:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
- uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
- uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- uses: cachix/cachix-action@5f2d7c5294214f71b873db4b969586b980625e71 # v17
continue-on-error: true
@@ -100,7 +100,7 @@ jobs:
merged-as-untrusted-at: ${{ inputs.mergedSha }}
target-as-trusted-at: ${{ inputs.targetSha }}
- uses: cachix/install-nix-action@13d8dd58da0234aa297dedd986986ccb8e7f3e24 # v31.11.1
- uses: cachix/install-nix-action@8aa03977d8d733052d78f4e008a241fd1dbf36b3 # v31.10.6
- uses: cachix/cachix-action@5f2d7c5294214f71b873db4b969586b980625e71 # v17
continue-on-error: true
@@ -131,8 +131,8 @@ jobs:
# Luckily there's no need to lint commit messages in the Merge Queue, because
# changes to the target branch can't change commit messages on the base branch.
if: ${{ github.event.pull_request.number }}
runs-on: ubuntu-24.04-arm
timeout-minutes: 8
runs-on: ubuntu-slim
timeout-minutes: 5
steps:
- uses: actions/checkout@df4cb1c069e1874edd31b4311f1884172cec0e10 # v6.0.3
with:

View File

@@ -97,7 +97,6 @@ jobs:
artifact-prefix: ${{ inputs.artifact-prefix }}
mergedSha: ${{ needs.prepare.outputs.mergedSha }}
targetSha: ${{ needs.prepare.outputs.targetSha }}
baseBranch: ${{ needs.prepare.outputs.baseBranch }}
systems: ${{ needs.prepare.outputs.systems }}
build:

View File

@@ -31,6 +31,12 @@ jobs:
max-parallel: 1
matrix:
pairs:
- from: release-25.11
into: staging-next-25.11
- from: staging-next-25.11
into: staging-25.11
- from: release-25.11
into: staging-nixos-25.11
- from: release-26.05
into: staging-next-26.05
- from: staging-next-26.05

View File

@@ -110,7 +110,6 @@ jobs:
mergedSha: ${{ needs.prepare.outputs.mergedSha }}
headSha: ${{ github.event.pull_request.head.sha }}
targetSha: ${{ needs.prepare.outputs.targetSha }}
baseBranch: ${{ needs.prepare.outputs.baseBranch }}
systems: ${{ needs.prepare.outputs.systems }}
testVersions: ${{ contains(fromJSON(needs.prepare.outputs.touched), 'pinned') && !contains(fromJSON(needs.prepare.outputs.headBranch).type, 'development') }}

View File

@@ -38,8 +38,7 @@ jobs:
maintainers/github-teams.json
- name: Install dependencies
run: npm ci --package-lock-only=false bottleneck
working-directory: ci/github-script
run: npm install bottleneck@2.19.5
- name: Synchronise teams
uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0

View File

@@ -64,7 +64,6 @@ jobs:
'ci/github-script/supportedSystems.js',
'ci/pinned.json',
'ci/supportedBranches.js',
'pkgs/top-level/release-supported-systems.json',
].includes(file))) core.setOutput('merge-group', true)
if (files.some(file => [
@@ -77,7 +76,7 @@ jobs:
'.github/workflows/pull-request-target.yml',
'.github/workflows/test.yml',
'ci/github-script/bot.js',
'ci/github-script/check-target-branch.ts',
'ci/github-script/check-target-branch.js',
'ci/github-script/commits.js',
'ci/github-script/get-pr-commit-details.js',
'ci/github-script/lint-commits.js',
@@ -89,7 +88,6 @@ jobs:
'ci/github-script/withRateLimit.js',
'ci/pinned.json',
'ci/supportedBranches.js',
'pkgs/top-level/release-supported-systems.json',
].includes(file))) core.setOutput('pr', true)
merge-group:

3
.gitignore vendored
View File

@@ -27,9 +27,6 @@ tags
.mypy_cache
__pycache__
/AGENTS.md
/CLAUDE.md
/pkgs/development/libraries/qt-5/*/tmp/
/pkgs/desktops/kde-5/*/tmp/
/pkgs/development/mobile/androidenv/xml/*

View File

@@ -6,7 +6,6 @@ Christina Sørensen <christina@cafkafk.com> <christinaafk@gmail.com>
Christina Sørensen <christina@cafkafk.com> <89321978+cafkafk@users.noreply.github.com>
Daniel Løvbrøtte Olsen <me@dandellion.xyz> <daniel.olsen99@gmail.com>
Ethan Carter Edwards <ethan@ethancedwards.com> Ethan Edwards <ethancarteredwards@gmail.com>
Ethan Carter Edwards <ethan@ethancedwards.com> <ethancedwards8@users.noreply.github.com>
Fabian Affolter <mail@fabian-affolter.ch> <fabian@affolter-engineering.ch>
Fiona Behrens <me@kloenk.dev>
Fiona Behrens <me@kloenk.dev> <me@kloenk.de>

View File

@@ -571,10 +571,7 @@ If a contributor does not want committers to push to their branch, they must unc
### Release notes
If you add or remove a NixOS module, or make other breaking or significant NixOS changes, write about it in the next NixOS release notes in [`nixos/doc/manual/release-notes`](./nixos/doc/manual/release-notes).
If you make major or breaking changes to a package (other than removal), write about it in the next Nixpkgs release notes in [`doc/release-notes`](./doc/release-notes).
Package removals should not get a Nixpkgs release note, [a throwing alias should be added instead](./pkgs/README.md#steps-to-remove-a-package-from-nixpkgs).
If you removed packages or made some major NixOS changes, write about it in the next release notes in [`nixos/doc/manual/release-notes`](./nixos/doc/manual/release-notes).
### File naming and organisation
@@ -957,6 +954,7 @@ The following situations are fully or partially exempt:
If you believe that someone is using automation without appropriate disclosure and review, you can politely ask them if thats the case and point them to this policy as appropriate.
Please assume good faith and remain civil; its not always possible to determine, and it is more likely that someone overlooked this policy than deliberately violated it.
If you think someone is continuing to break the policy after this, please escalate to the [Nixpkgs core team](https://nixos.org/community/teams/nixpkgs-core/) rather than fighting over it.
If a contribution is clearly in violation of the policy (e.g. the contributor admits it was not followed, or there are AI tool attributions that do not meet our required format), it can be closed or hidden, preferably after informing the contributor of the policy and giving them a chance to address the violations.
Deliberate violations of this policy are considered to break the [Code of Conduct](https://github.com/NixOS/.github/blob/master/CODE_OF_CONDUCT.md) clause against “Wasting other peoples time with low quality contributions, including but not limited to LLM and bot spam”.

127
ci/OWNERS
View File

@@ -25,27 +25,26 @@
/shell.nix @infinisil @NixOS/Security
# Libraries
/lib @infinisil @hsjobeki @llakala
/lib/generators.nix @infinisil @hsjobeki @llakala
/lib/cli.nix @infinisil @hsjobeki @llakala
/lib/debug.nix @infinisil @hsjobeki @llakala
/lib/asserts.nix @infinisil @hsjobeki @llakala
/lib/path/* @infinisil @hsjobeki @llakala
/lib/fileset @infinisil @hsjobeki @llakala
/maintainers/github-teams.json @infinisil @llakala
/maintainers/computed-team-list.nix @infinisil @llakala
/lib @infinisil @hsjobeki
/lib/generators.nix @infinisil @hsjobeki
/lib/cli.nix @infinisil @hsjobeki
/lib/debug.nix @infinisil @hsjobeki
/lib/asserts.nix @infinisil @hsjobeki
/lib/path/* @infinisil @hsjobeki
/lib/fileset @infinisil @hsjobeki
/maintainers/github-teams.json @infinisil
/maintainers/computed-team-list.nix @infinisil
## Standard environmentrelated libraries
/lib/customisation.nix @alyssais @NixOS/stdenv @llakala
/lib/derivations.nix @NixOS/stdenv @llakala
/lib/fetchers.nix @alyssais @NixOS/stdenv @llakala
/lib/meta.nix @alyssais @NixOS/stdenv @llakala
/lib/meta-types.nix @infinisil @adisbladis @NixOS/stdenv @llakala
/lib/source-types.nix @alyssais @NixOS/stdenv @llakala
/lib/customisation.nix @alyssais @NixOS/stdenv
/lib/derivations.nix @NixOS/stdenv
/lib/fetchers.nix @alyssais @NixOS/stdenv
/lib/meta.nix @alyssais @NixOS/stdenv
/lib/source-types.nix @alyssais @NixOS/stdenv
/lib/systems @alyssais @NixOS/stdenv
## Libraries / Module system
/lib/modules.nix @infinisil @roberth @hsjobeki @llakala
/lib/types.nix @infinisil @roberth @hsjobeki @llakala
/lib/options.nix @infinisil @roberth @hsjobeki @llakala
/lib/modules.nix @infinisil @roberth @hsjobeki
/lib/types.nix @infinisil @roberth @hsjobeki
/lib/options.nix @infinisil @roberth @hsjobeki
/lib/tests/modules.sh @infinisil @roberth @hsjobeki
/lib/tests/modules @infinisil @roberth @hsjobeki
@@ -63,17 +62,20 @@
/pkgs/top-level/packages-info.nix @jopejoe1
/pkgs/top-level/release-lib.nix @jopejoe1
/pkgs/top-level/release.nix @jopejoe1
/pkgs/stdenv @philiptaron @NixOS/stdenv @llakala
/pkgs/stdenv/generic @Ericson2314 @NixOS/stdenv @llakala
/pkgs/stdenv/generic/problems.nix @infinisil @llakala
/pkgs/stdenv @philiptaron @NixOS/stdenv
/pkgs/stdenv/generic @Ericson2314 @NixOS/stdenv
/pkgs/stdenv/generic/problems.nix @infinisil
/pkgs/test/problems @infinisil
/pkgs/stdenv/generic/check-meta.nix @infinisil @Ericson2314 @adisbladis @NixOS/stdenv @llakala
/pkgs/stdenv/generic/check-meta.nix @infinisil @Ericson2314 @adisbladis @NixOS/stdenv
/pkgs/stdenv/generic/meta-types.nix @infinisil @adisbladis @NixOS/stdenv
/pkgs/stdenv/cross @Ericson2314 @NixOS/stdenv
/pkgs/build-support @philiptaron
/pkgs/build-support/cc-wrapper @Ericson2314
/pkgs/build-support/bintools-wrapper @Ericson2314
/pkgs/build-support/setup-hooks @Ericson2314
/pkgs/build-support/setup-hooks/arrayUtilities @ConnorBaker
/pkgs/build-support/setup-hooks/auto-patchelf.sh @layus
/pkgs/by-name/au/auto-patchelf @layus
## Format generators/serializers
/pkgs/pkgs-lib @Stunkymonkey @h7x4
@@ -82,6 +84,10 @@
# Nixpkgs build-support
/pkgs/build-support/writers @lassulus
# Nixpkgs make-disk-image
/doc/build-helpers/images/makediskimage.section.md @raitobezarius
/nixos/lib/make-disk-image.nix @raitobezarius
# Nix, the package manager
# @raitobezarius is not "code owner", but is listed here to be notified of changes
# pertaining to the Nix package manager.
@@ -95,16 +101,16 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @Artturin @Ericson2314 @lo
/maintainers/scripts/doc @jtojnar @ryantm
# Contributor documentation
/CONTRIBUTING.md
/.github/PULL_REQUEST_TEMPLATE.md
/doc/contributing/
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar
/lib/README.md
/doc/README.md
/nixos/README.md
/pkgs/README.md
/pkgs/by-name/README.md
/maintainers/README.md
/CONTRIBUTING.md @infinisil
/.github/PULL_REQUEST_TEMPLATE.md @infinisil
/doc/contributing/ @infinisil
/doc/contributing/contributing-to-documentation.chapter.md @jtojnar @infinisil
/lib/README.md @infinisil
/doc/README.md @infinisil
/nixos/README.md @infinisil
/pkgs/README.md @infinisil
/pkgs/by-name/README.md @infinisil
/maintainers/README.md @infinisil
# User-facing development documentation
/doc/development.md @infinisil
@@ -123,6 +129,10 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @Artturin @Ericson2314 @lo
/doc/redirects.json @GetPsyched
/nixos/doc/manual/redirects.json @GetPsyched
# NixOS integration test driver
/nixos/lib/test-driver @tfc
/nixos/lib/testing @tfc
# NixOS QEMU virtualisation
/nixos/modules/virtualisation/qemu-vm.nix @raitobezarius
/nixos/modules/services/backup/libvirtd-autosnapshot.nix @6543
@@ -182,10 +192,10 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @Artturin @Ericson2314 @lo
/pkgs/by-name/an/android* @NixOS/android
# Python-related code and docs
/doc/languages-frameworks/python.section.md @mweinelt
/maintainers/scripts/update-python-libraries @mweinelt
/pkgs/by-name/up/update-python-libraries @mweinelt
/pkgs/development/interpreters/python @mweinelt
/doc/languages-frameworks/python.section.md @mweinelt @natsukium
/maintainers/scripts/update-python-libraries @mweinelt @natsukium
/pkgs/by-name/up/update-python-libraries @mweinelt @natsukium
/pkgs/development/interpreters/python @mweinelt @natsukium
# CUDA
/pkgs/top-level/cuda-packages.nix @NixOS/cuda-maintainers
@@ -211,14 +221,14 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @Artturin @Ericson2314 @lo
/pkgs/development/perl-modules @stigtsp @marcusramberg
# R
/pkgs/by-name/r/R @jbedo
/pkgs/applications/science/math/R @jbedo
/pkgs/development/r-modules @jbedo
# Rust
/pkgs/development/compilers/rust @NixOS/rust @alyssais
/pkgs/build-support/rust @NixOS/rust
/pkgs/development/compilers/rust @alyssais @Mic92 @winterqt
/pkgs/build-support/rust @winterqt
/pkgs/build-support/rust/fetch-cargo-vendor* @TomaSajt
/doc/languages-frameworks/rust.section.md @NixOS/rust
/doc/languages-frameworks/rust.section.md @winterqt
# Tcl
/pkgs/development/interpreters/tcl @fgaz
@@ -230,10 +240,14 @@ nixos/modules/installer/tools/nix-fallback-paths.nix @Artturin @Ericson2314 @lo
# C compilers
/pkgs/development/compilers/gcc
/pkgs/development/compilers/llvm @NixOS/llvm
/pkgs/development/compilers/emscripten @raitobezarius
/doc/toolchains/llvm.chapter.md @NixOS/llvm
/doc/languages-frameworks/emscripten.section.md @raitobezarius
# Audio
/nixos/modules/services/audio/botamusique.nix @mweinelt
/nixos/modules/services/audio/snapserver.nix @mweinelt
/nixos/tests/botamusique.nix @mweinelt
/nixos/tests/snapcast.nix @mweinelt
# Browsers
@@ -263,15 +277,15 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
/lib/licenses @alyssais @emilazy @jopejoe1
# Qt
/pkgs/development/libraries/qt-5 @NixOS/qt-kde
/pkgs/development/libraries/qt-6 @NixOS/qt-kde
/pkgs/development/libraries/qt-5 @K900 @NickCao @SuperSandro2000
/pkgs/development/libraries/qt-6 @K900 @NickCao @SuperSandro2000
# KDE Frameworks 5
/pkgs/development/libraries/kde-frameworks @NixOS/qt-kde
/pkgs/development/libraries/kde-frameworks @K900 @NickCao @SuperSandro2000
# KDE / Plasma 6
/pkgs/kde @NixOS/qt-kde
/maintainers/scripts/kde @NixOS/qt-kde
/pkgs/kde @K900 @NickCao @SuperSandro2000
/maintainers/scripts/kde @K900 @NickCao @SuperSandro2000
# PostgreSQL and related stuff
/pkgs/by-name/po/postgresqlTestHook @NixOS/postgres
@@ -322,9 +336,9 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
/nixos/tests/knot.nix @mweinelt
# Web servers
/doc/packages/nginx.section.md @leona-ya @Ma27
/pkgs/servers/http/nginx/ @helsinki-Jo @leona-ya @Ma27
/nixos/modules/services/web-servers/nginx/ @leona-ya @Ma27
/doc/packages/nginx.section.md @raitobezarius
/pkgs/servers/http/nginx/ @raitobezarius
/nixos/modules/services/web-servers/nginx/ @raitobezarius
# D
/pkgs/build-support/dlang @jtbx @TomaSajt
@@ -361,14 +375,10 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
/pkgs/applications/editors/kakoune @philiptaron
# LuaPackages
/pkgs/development/interpreters/lua-5 @NixOS/lua
/pkgs/development/interpreters/luajit @NixOS/lua
/pkgs/development/lua-modules @NixOS/lua
/pkgs/top-level/lua-packages.nix @NixOS/lua
# Neovim
/pkgs/applications/editors/neovim @NixOS/neovim
/doc/languages-frameworks/neovim.section.md @NixOS/neovim
/pkgs/applications/editors/neovim @NixOS/neovim
# VimPlugins
/pkgs/applications/editors/vim/plugins @NixOS/neovim
@@ -469,8 +479,9 @@ nixos/tests/incus/ @adamcstephens
pkgs/by-name/in/incus/ @adamcstephens
pkgs/by-name/lx/lxc* @adamcstephens
# Flutter
# ExpidusOS, Flutter
/pkgs/development/compilers/flutter @RossComputerGuy
/pkgs/desktops/expidus @RossComputerGuy
# GNU Tar & Zip
/pkgs/by-name/gn/gnutar @RossComputerGuy
@@ -508,7 +519,7 @@ pkgs/by-name/oc/octodns/ @anthonyroussel
pkgs/by-name/te/teleport* @arianvp @justinas @sigma @tomberek @techknowlogick @JuliusFreudenberger
# Warp-terminal
pkgs/by-name/wa/warp-terminal/ @emilytrau @imadnyc @4evy @johnrtitor
pkgs/by-name/wa/warp-terminal/ @emilytrau @imadnyc @FlameFlag @johnrtitor
# Nim
/doc/languages-frameworks/nim.section.md @NixOS/nim
@@ -522,9 +533,3 @@ pkgs/by-name/wa/warp-terminal/ @emilytrau @imadnyc @4evy @johnrtitor
# Zellij plugins
/pkgs/by-name/ze/zellij/plugins/ @PerchunPak
# Test-driver
/nixos/lib/test-driver @NixOS/test-driver
/nixos/lib/testing @NixOS/test-driver
/nixos/tests/nixos-test-driver @NixOS/test-driver
/nixos/modules/virtualisation/nspawn-container/run-nspawn @NixOS/test-driver

View File

@@ -51,16 +51,6 @@ To ensure security and a focused utility, the bot adheres to specific limitation
- opened by [@r-ryantm](https://nix-community.github.io/nixpkgs-update/r-ryantm/).
- The user attempting to merge is a member of [@NixOS/nixpkgs-maintainers].
- The user attempting to merge is a maintainer of all packages touched by the PR.
- No [committer][@NixOS/nixpkgs-committers] has an outstanding "changes requested" review.
These block both the merge queue and auto-merge, so the bot refuses to merge until the review is addressed or dismissed.
Once these constraints are met, the bot picks a merge strategy based on the `no PR failures` commit status:
- CI passing: the PR is added to the merge queue.
- CI unfinished (pending or missing status): the bot enables [Auto Merge], which queues the PR once required checks succeed.
Note that if CI later fails, nothing happens until it is fixed and passes.
- CI already failing (`error`/`failure` status): the bot does not enable Auto Merge, because it would never trigger, and fixing CI requires a new push that invalidates the merge command.
A fresh `@NixOS/nixpkgs-merge-bot merge` comment is needed once CI is green again.
### Approving merge bot changes
@@ -114,4 +104,3 @@ This script can also be run locally to print basic test cases.
[@NixOS/nixpkgs-ci]: https://github.com/orgs/NixOS/teams/nixpkgs-ci
[@NixOS/nixpkgs-core]: https://github.com/orgs/NixOS/teams/nixpkgs-core
[RFC 172]: https://github.com/NixOS/rfcs/pull/172
[Auto Merge]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request

View File

@@ -26,7 +26,132 @@ let
fmt =
let
treefmt = pkgs.treefmt.withConfig ./treefmt.nix;
treefmtNixSrc = fetchTarball {
inherit (pinned.treefmt-nix) url;
sha256 = pinned.treefmt-nix.hash;
};
treefmtEval = (import treefmtNixSrc).evalModule pkgs {
# Important: The auto-rebase script uses `git filter-branch --tree-filter`,
# which creates trees within the Git repository under `.git-rewrite/t`,
# notably without having a `.git` themselves.
# So if this projectRootFile were the default `.git/config`,
# having the auto-rebase script use treefmt on such a tree would make it
# format all files in the _parent_ Git tree as well.
projectRootFile = ".git-blame-ignore-revs";
# Be a bit more verbose by default, so we can see progress happening
settings.verbose = 1;
# By default it's info, which is too noisy since we have many unmatched files
settings.on-unmatched = "debug";
programs.actionlint.enable = true;
programs.biome = {
enable = true;
# Disable settings validation because its inputs are liable to hash mismatch
validate.enable = false;
settings.formatter = {
useEditorconfig = true;
};
settings.javascript.formatter = {
quoteStyle = "single";
semicolons = "asNeeded";
};
settings.json.formatter.enabled = false;
};
settings.formatter.biome.excludes = [
"*.min.js"
"pkgs/*"
];
programs.keep-sorted.enable = true;
# This uses nixfmt underneath, the default formatter for Nix code.
# See https://github.com/NixOS/nixfmt
programs.nixfmt = {
enable = true;
package = pkgs.nixfmt;
};
programs.yamlfmt = {
enable = true;
settings.formatter = {
retain_line_breaks = true;
};
};
settings.formatter.yamlfmt.excludes = [
# Aligns comments with whitespace
"pkgs/development/haskell-modules/configuration-hackage2nix/main.yaml"
# TODO: Fix formatting for auto-generated file
"pkgs/development/haskell-modules/configuration-hackage2nix/transitive-broken.yaml"
];
programs.nixf-diagnose = {
enable = true;
ignore = [
# Rule names can currently be looked up here:
# https://github.com/nix-community/nixd/blob/main/libnixf/src/Basic/diagnostic.py
# TODO: Remove the following and fix things.
"sema-unused-def-lambda-noarg-formal"
"sema-unused-def-lambda-witharg-arg"
"sema-unused-def-lambda-witharg-formal"
"sema-unused-def-let"
# Keep this rule, because we have `lib.or`.
"or-identifier"
# TODO: remove after outstanding prelude diagnostics issues are fixed:
# https://github.com/nix-community/nixd/issues/761
# https://github.com/nix-community/nixd/issues/762
"sema-primop-removed-prefix"
"sema-primop-overridden"
"sema-constant-overridden"
"sema-primop-unknown"
];
};
settings.formatter.nixf-diagnose = {
# Ensure nixfmt cleans up after nixf-diagnose.
priority = -1;
excludes = [
# Auto-generated; violates sema-extra-with
# Can only sensibly be removed when --auto-fix supports multiple fixes at once:
# https://github.com/inclyc/nixf-diagnose/issues/13
"pkgs/servers/home-assistant/component-packages.nix"
# https://github.com/nix-community/nixd/issues/708
"nixos/maintainers/scripts/azure-new/examples/basic/system.nix"
];
};
settings.formatter.editorconfig-checker = {
command = "${pkgs.lib.getExe pkgs.editorconfig-checker}";
options = [
"-disable-indent-size"
# TODO: Remove this once this upstream issue is fixed:
# https://github.com/editorconfig-checker/editorconfig-checker/issues/505
"-disable-charset"
];
includes = [ "*" ];
priority = 1;
};
# TODO: Upstream this into treefmt-nix eventually:
# https://github.com/numtide/treefmt-nix/issues/387
settings.formatter.markdown-code-runner = {
command = pkgs.lib.getExe pkgs.markdown-code-runner;
options =
let
config = pkgs.writers.writeTOML "markdown-code-runner-config" {
presets.nixfmt = {
language = "nix";
command = [ (pkgs.lib.getExe pkgs.nixfmt) ];
};
};
in
[ "--config=${config}" ];
includes = [ "*.md" ];
};
programs.zizmor.enable = true;
};
fs = pkgs.lib.fileset;
nixFilesSrc = fs.toSource {
root = ../.;
@@ -34,24 +159,14 @@ let
};
in
{
pkg = treefmt;
check = treefmt.check nixFilesSrc;
shell = treefmtEval.config.build.devShell;
pkg = treefmtEval.config.build.wrapper;
check = treefmtEval.config.build.check nixFilesSrc;
};
# nixos-render-docs and nixos-render-docs-redirects
# Should be used from tree to build the matching in-tree documentation
docPkgs = pkgs.extend (
final: prev: {
nixos-render-docs = final.callPackage ../pkgs/by-name/ni/nixos-render-docs/package.nix { };
nixos-render-docs-redirects =
final.callPackage ../pkgs/by-name/ni/nixos-render-docs-redirects/package.nix
{ };
}
);
in
rec {
inherit pkgs docPkgs fmt;
inherit pkgs fmt;
codeownersValidator = pkgs.callPackage ./codeowners-validator { };
# FIXME(lf-): it might be useful to test other Nix implementations
@@ -64,13 +179,13 @@ rec {
# CI jobs
lib-tests = import ../lib/tests/release.nix { inherit pkgs; };
manual-nixos = (import ../nixos/release.nix { }).manual.${system} or null;
manual-nixpkgs = (import ../doc { pkgs = docPkgs; });
manual-nixpkgs = (import ../doc { inherit pkgs; });
nixpkgs-vet = pkgs.callPackage ./nixpkgs-vet.nix {
nix = pkgs.nixVersions.latest;
};
parse = pkgs.lib.recurseIntoAttrs {
nix_latest = pkgs.callPackage ./parse.nix { nix = pkgs.nixVersions.latest; };
stable = pkgs.callPackage ./parse.nix { nix = pkgs.nixVersions.stable; };
nix_2_28 = pkgs.callPackage ./parse.nix { nix = pkgs.nixVersions.nix_2_28; };
lix = pkgs.callPackage ./parse.nix { nix = pkgs.lix; };
lix_latest = pkgs.callPackage ./parse.nix { nix = pkgs.lixPackageSets.latest.lix; };
};

85
ci/eval/attrpaths.nix Normal file
View File

@@ -0,0 +1,85 @@
# This expression will, as efficiently as possible, dump a
# *superset* of all attrpaths of derivations which might be
# part of a release on *any* platform.
#
# This expression runs single-threaded under all current Nix
# implementations, but much faster and with much less memory
# used than ./outpaths.nix itself.
#
# Once you have the list of attrnames you can split it up into
# $NUM_CORES batches and evaluate the outpaths separately for each
# batch, in parallel.
#
# To dump the attrnames:
#
# nix-instantiate --eval --strict --json ci/eval/attrpaths.nix -A names
#
{
lib ? import (path + "/lib"),
trace ? false,
path ? ./../..,
extraNixpkgsConfigJson ? "{}",
}:
let
# TODO: Use mapAttrsToListRecursiveCond when this PR lands:
# https://github.com/NixOS/nixpkgs/pull/395160
justAttrNames =
path: value:
let
result =
if path == [ "AAAAAASomeThingsFailToEvaluate" ] || !(lib.isAttrs value) then
[ ]
else if lib.isDerivation value then
[ path ]
else
lib.pipe value [
(lib.mapAttrsToList (
name: value:
lib.addErrorContext "while evaluating package set attribute path '${
lib.showAttrPath (path ++ [ name ])
}'" (justAttrNames (path ++ [ name ]) value)
))
lib.concatLists
];
in
lib.traceIf trace "** ${lib.showAttrPath path}" result;
outpaths = import ./outpaths.nix {
inherit path;
extraNixpkgsConfig = builtins.fromJSON extraNixpkgsConfigJson;
attrNamesOnly = true;
};
paths = [
# Some of the following are based on variants, which are disabled with `attrNamesOnly = true`.
# Until these have been removed from release.nix / hydra, we manually add them to the list.
[
"pkgsLLVM"
"stdenv"
]
[
"pkgsArocc"
"stdenv"
]
[
"pkgsZig"
"stdenv"
]
[
"pkgsStatic"
"stdenv"
]
[
"pkgsMusl"
"stdenv"
]
]
++ justAttrNames [ ] outpaths;
names = map lib.showAttrPath paths;
in
{
inherit paths names;
}

View File

@@ -2,8 +2,8 @@
{
lib ? import ../../lib,
path ? ../..,
# The file containing the preEval result
preEvalFile,
# The file containing all available attribute paths, which are split into chunks here
attrpathFile,
chunkSize,
myChunk,
includeBroken,
@@ -12,13 +12,12 @@
}:
let
preEvalResult = lib.importJSON preEvalFile;
myAttrpaths = lib.sublist (chunkSize * myChunk) chunkSize preEvalResult.paths;
attrpaths = lib.importJSON attrpathFile;
myAttrpaths = lib.sublist (chunkSize * myChunk) chunkSize attrpaths;
unfiltered = import ./outpaths.nix {
inherit path;
inherit includeBroken systems;
inherit (preEvalResult) attrPathsDisallowedForInternalUse;
extraNixpkgsConfig = builtins.fromJSON extraNixpkgsConfigJson;
};

View File

@@ -49,7 +49,6 @@ in
{
combinedDir,
touchedFilesJson,
baseBranch,
ownersFile ? ../../OWNERS,
}:
let
@@ -243,7 +242,7 @@ runCommand "compare"
echo
echo "# Performance comparison"
echo
echo "This compares the performance of this branch against the \`${baseBranch}\` branch."
echo "This compares the performance of this branch against its pull request base branch (e.g., 'master')"
echo
} >> $out/step-summary.md

View File

@@ -17,7 +17,6 @@
busybox,
jq,
nix,
perf,
}:
{
@@ -39,7 +38,7 @@ let
fileset = unions (
map (lib.path.append ../..) [
".version"
"ci/eval/pre-eval.nix"
"ci/eval/attrpaths.nix"
"ci/eval/chunk.nix"
"ci/eval/outpaths.nix"
"default.nix"
@@ -57,11 +56,11 @@ let
builtins.readFile ../../pkgs/top-level/release-supported-systems.json
);
preEval =
attrpathsSuperset =
{
evalSystem,
}:
runCommand "pre-eval"
runCommand "attrpaths-superset.json"
{
src = nixpkgs;
# Don't depend on -dev outputs to reduce closure size for CI.
@@ -74,15 +73,15 @@ let
export NIX_STATE_DIR=$(mktemp -d)
mkdir $out
export GC_INITIAL_HEAP_SIZE=4g
command time -f "Pre-eval done [%MKB max resident, %Es elapsed] %C" \
command time -f "Attribute eval done [%MKB max resident, %Es elapsed] %C" \
nix-instantiate --eval --strict --json --show-trace \
"$src/ci/eval/pre-eval.nix" \
-A result \
"$src/ci/eval/attrpaths.nix" \
-A paths \
-I "$src" \
--argstr extraNixpkgsConfigJson ${lib.escapeShellArg (builtins.toJSON extraNixpkgsConfig)} \
--option restrict-eval true \
--option allow-import-from-derivation false \
--option eval-system "${evalSystem}" > $out/result.json
--option eval-system "${evalSystem}" > $out/paths.json
'';
singleSystem =
@@ -91,10 +90,8 @@ let
# Note that this is intentionally not called `system`,
# because `--argstr system` would only be passed to the ci/default.nix file!
evalSystem ? builtins.currentSystem,
# The path to the `result.json` file from `preEval`
preEvalFile ? "${preEval { inherit evalSystem; }}/result.json",
# Output the number of assembly instructions executed during evaluation
countInstructions ? false,
# The path to the `paths.json` file from `attrpathsSuperset`
attrpathFile ? "${attrpathsSuperset { inherit evalSystem; }}/paths.json",
}:
let
singleChunk = writeShellScript "single-chunk" ''
@@ -103,7 +100,6 @@ let
myChunk=$2
system=$3
outputDir=$4
preEvalFile=$5
# Default is 5, higher values effectively disable the warning.
# This randomly breaks Eval.
@@ -125,12 +121,12 @@ let
--show-trace \
--arg chunkSize "$chunkSize" \
--arg myChunk "$myChunk" \
--arg preEvalFile "$preEvalFile" \
--arg attrpathFile "${attrpathFile}" \
--arg systems "[ \"$system\" ]" \
--arg includeBroken ${lib.boolToString includeBroken} \
--argstr extraNixpkgsConfigJson ${lib.escapeShellArg (builtins.toJSON extraNixpkgsConfig)} \
-I ${nixpkgs} \
-I "$preEvalFile" \
-I ${attrpathFile} \
> "$outputDir/result/$myChunk" \
2> "$outputDir/stderr/$myChunk"
exitCode=$?
@@ -150,16 +146,13 @@ let
runCommand "nixpkgs-eval-${evalSystem}"
{
# Don't depend on -dev outputs to reduce closure size for CI.
nativeBuildInputs = map lib.getBin (
[
busybox
jq
nix
]
++ lib.optionals countInstructions [ perf ]
);
nativeBuildInputs = map lib.getBin [
busybox
jq
nix
];
env = {
inherit evalSystem chunkSize countInstructions;
inherit evalSystem chunkSize;
};
__structuredAttrs = true;
unsafeDiscardReferences.out = true;
@@ -171,6 +164,12 @@ let
echo "System: $evalSystem"
cores=$NIX_BUILD_CORES
echo "Cores: $cores"
attrCount=$(jq length "${attrpathFile}")
echo "Attribute count: $attrCount"
echo "Chunk size: $chunkSize"
# Same as `attrCount / chunkSize` but rounded up
chunkCount=$(( (attrCount - 1) / chunkSize + 1 ))
echo "Chunk count: $chunkCount"
mkdir -p $out/${evalSystem}
@@ -191,78 +190,29 @@ let
done
) &
chunkedEval() {
local chunkOutputDir=$1
local preEvalFile=$2
seq_end=$(( chunkCount - 1 ))
local attrCount=$(jq '.paths | length' "$preEvalFile")
echo "Attribute count: $attrCount"
echo "Chunk size: $chunkSize"
# Same as `attrCount / chunkSize` but rounded up
local chunkCount=$(( (attrCount - 1) / chunkSize + 1 ))
echo "Chunk count: $chunkCount"
${lib.optionalString quickTest ''
seq_end=0
''}
local seq_end=$(( chunkCount - 1 ))
${lib.optionalString quickTest ''
seq_end=0
''}
chunkOutputDir=$(mktemp -d)
mkdir "$chunkOutputDir"/{result,stats,timestats,stderr}
mkdir -p "$chunkOutputDir"/{result,stats,timestats,stderr}
seq -w 0 "$seq_end" |
command time -f "%e" -o "$out/${evalSystem}/total-time" \
xargs -I{} -P"$cores" \
${singleChunk} "$chunkSize" {} "$evalSystem" "$chunkOutputDir"
runAllChunks() {
seq -w 0 "$seq_end" |
xargs -I{} -P"$cores" \
${singleChunk} "$chunkSize" {} "$evalSystem" "$chunkOutputDir" "$preEvalFile"
}
cp -r "$chunkOutputDir"/stats $out/${evalSystem}/stats-by-chunk
if [[ -n "$countInstructions" ]]; then
export seq_end cores chunkSize evalSystem chunkOutputDir preEvalFile
export -f runAllChunks
perf stat \
--event instructions:u --field-separator , --output "$chunkOutputDir"/perf-output-file \
bash -c runAllChunks
cat "$chunkOutputDir"/perf-output-file | tail -n 1 | cut -d, -f1 > "$chunkOutputDir"/instructions
rm "$chunkOutputDir"/perf-output-file
else
runAllChunks
fi
if (( chunkSize * chunkCount != attrCount )); then
# A final incomplete chunk would mess up the stats, don't include it
rm "$chunkOutputDir"/stats/"$seq_end"
fi
}
chunkOutputDirs=$(mktemp -d)
# Preparation for the second eval
disallowedAttributesPreEvalFile=$(mktemp)
jq '{
paths: (.attrPathsDisallowedForInternalUse | map(.attrPath)),
attrPathsDisallowedForInternalUse: []
}' ${preEvalFile} > "$disallowedAttributesPreEvalFile"
startEpoch=$(date +%s)
# The first eval evaluates only attributes that are not disallowed for internal Nixpkgs use, ensuring that they don't depend on disallowed attributes
# Because the first eval doesn't evaluate the disallowed attributes themselves, but we still want to check that they don't fail evaluation, we evaluate them separately in a second eval
# The reason we need two evals is because we want disallowed attributes to be able to depend on other disallowed attributes, which inherently needs a separate Nixpkgs instantiation
# And while we could interleave that instantiation into a single eval, that would ~double memory usage for all chunks, while doing it separately doesn't
echo "Evaluating the internally allowed attributes"
chunkedEval "$chunkOutputDirs"/allowed ${preEvalFile}
echo "Evaluating the internally disallowed attributes"
chunkedEval "$chunkOutputDirs"/disallowed "$disallowedAttributesPreEvalFile"
echo $(( $(date +%s) - startEpoch )) > "$out/${evalSystem}/total-time"
# We only use the stats from the allowed attrs eval, because the disallowed attrs are generally not even a full chunk
cp -r "$chunkOutputDirs"/allowed/stats $out/${evalSystem}/stats-by-chunk
if [[ -f "$chunkOutputDirs"/allowed/instructions ]]; then
cp "$chunkOutputDirs"/allowed/instructions $out/${evalSystem}/instructions
if (( chunkSize * chunkCount != attrCount )); then
# A final incomplete chunk would mess up the stats, don't include it
rm "$chunkOutputDir"/stats/"$seq_end"
fi
cat "$chunkOutputDirs"/*/result/* | jq -s 'add | map_values(.outputs)' > $out/${evalSystem}/paths.json
cat "$chunkOutputDirs"/*/result/* | jq -s 'add | map_values(.meta)' > $out/${evalSystem}/meta.json
cat "$chunkOutputDir"/result/* | jq -s 'add | map_values(.outputs)' > $out/${evalSystem}/paths.json
cat "$chunkOutputDir"/result/* | jq -s 'add | map_values(.meta)' > $out/${evalSystem}/meta.json
'';
diff = callPackage ./diff.nix { };
@@ -299,20 +249,14 @@ let
}) | from_entries
' > $out/maintainers.json
mkdir -p $out/before/stats $out/before/instructions
mkdir -p $out/before/stats
for d in ${diffDir}/before/*; do
cp -r "$d"/stats-by-chunk $out/before/stats/$(basename "$d")
if [[ -f "$d"/instructions ]]; then
cp "$d"/instructions $out/before/instructions/$(basename "$d")
fi
done
mkdir -p $out/after/stats $out/after/instructions
mkdir -p $out/after/stats
for d in ${diffDir}/after/*; do
cp -r "$d"/stats-by-chunk $out/after/stats/$(basename "$d")
if [[ -f "$d"/instructions ]]; then
cp "$d"/instructions $out/after/instructions/$(basename "$d")
fi
done
'';
@@ -322,16 +266,13 @@ let
{
# Whether to evaluate on a specific set of systems, by default all are evaluated
evalSystems ? if quickTest then [ "x86_64-linux" ] else supportedSystems,
# Output the number of assembly instructions executed during evaluation on
# each system
countInstructions ? false,
}:
symlinkJoin {
name = "nixpkgs-eval-baseline";
paths = map (
evalSystem:
singleSystem {
inherit evalSystem countInstructions;
inherit evalSystem;
}
) evalSystems;
};
@@ -347,12 +288,6 @@ let
# | jq --raw-input --slurp 'split("\n")[:-1]' > touched-files.json
# ```
touchedFilesJson ? builtins.toFile "touched-files.json" "[ ]",
# The branch the local comparison is made against; matches the `master`
# used in the touched-files expression above.
baseBranch ? "master",
# Output the number of assembly instructions executed during evaluation on
# each system
countInstructions ? false,
}:
let
diffs = symlinkJoin {
@@ -363,14 +298,14 @@ let
inherit evalSystem;
beforeDir = baseline;
afterDir = singleSystem {
inherit evalSystem countInstructions;
inherit evalSystem;
};
}
) evalSystems;
};
comparisonReport = compare {
combinedDir = combine { diffDir = diffs; };
inherit touchedFilesJson baseBranch;
inherit touchedFilesJson;
};
in
comparisonReport;
@@ -378,7 +313,7 @@ let
in
{
inherit
preEval
attrpathsSuperset
singleSystem
diff
combine

View File

@@ -6,7 +6,7 @@
includeBroken ? true, # set this to false to exclude meta.broken packages from the output
path ? ./../..,
# used by ./pre-eval.nix
# used by ./attrpaths.nix
attrNamesOnly ? false,
# Set this to `null` to build for builtins.currentSystem only
@@ -14,8 +14,6 @@
builtins.readFile (path + "/pkgs/top-level/release-supported-systems.json")
),
attrPathsDisallowedForInternalUse ? [ ],
# Customize the config used to evaluate nixpkgs
extraNixpkgsConfig ? { },
}:
@@ -37,22 +35,6 @@ let
allowVariants = !attrNamesOnly;
checkMeta = true;
# We don't need to care about problems being caught using the
# standard mechanism, because any problems whose kind is not
# nixpkgsInternalUseAllowed cause the corresponding attributes to
# be disallowed entirely for internal use with
# attrPathsDisallowedForInternalUse, see also ./pre-eval.nix
problems.matchers = lib.mkForce [
# We only need to set the broken handler to error, so that CI
# doesn't evaluate those. No reason it couldn't evaluate them
# afaik, but this is how it's been before.
{
kind = "broken";
handler = "error";
}
];
inherit attrPathsDisallowedForInternalUse;
# Silence the `x86_64-darwin` deprecation warning.
allowDeprecatedx86_64Darwin = true;

View File

@@ -1,128 +0,0 @@
# This file does a fast pre-evaluation of Nixpkgs to determine:
# - paths: A *superset* of all attrpaths of derivations which might be part of a release on *any* platform.
# - attrPathsDisallowedForInternalUse: Attribute paths whose meta.problems has problems whose kinds should not be used internally in Nixpkgs
#
# This expression runs single-threaded under all current Nix
# implementations, but much faster and with much less memory
# used than ./outpaths.nix itself.
#
# Once you have the list of attrnames you can split it up into
# $NUM_CORES batches and evaluate the outpaths separately for each
# batch, in parallel.
#
# To dump the result:
#
# nix-instantiate --eval --strict --json ci/eval/pre-eval.nix -A result
#
{
lib ? import (path + "/lib"),
trace ? false,
path ? ./../..,
extraNixpkgsConfigJson ? "{}",
}:
let
# TODO: Use mapAttrsToListRecursiveCond when this PR lands:
# https://github.com/NixOS/nixpkgs/pull/395160
listAttrs =
path: value:
let
result =
if path == [ "AAAAAASomeThingsFailToEvaluate" ] || !(lib.isAttrs value) then
[ ]
else if lib.isDerivation value then
[
{
inherit path value;
}
]
else
lib.pipe value [
(lib.mapAttrsToList (
name: value:
lib.addErrorContext "while evaluating package set attribute path '${
lib.showAttrPath (path ++ [ name ])
}'" (listAttrs (path ++ [ name ]) value)
))
lib.concatLists
];
in
lib.traceIf trace "** ${lib.showAttrPath path}" result;
outpaths = import ./outpaths.nix {
inherit path;
extraNixpkgsConfig = builtins.fromJSON extraNixpkgsConfigJson;
attrNamesOnly = true;
};
list =
map
(path: {
inherit path;
# This looks a bit weird, but the only reason we care about this value
# is for the meta.problems check below, and stdenv's certainly don't
# have any problems, so this is fine :)
value = { };
})
[
# Some of the following are based on variants, which are disabled with `attrNamesOnly = true`.
# Until these have been removed from release.nix / hydra, we manually add them to the list.
[
"pkgsLLVM"
"stdenv"
]
[
"pkgsArocc"
"stdenv"
]
[
"pkgsZig"
"stdenv"
]
[
"pkgsStatic"
"stdenv"
]
[
"pkgsMusl"
"stdenv"
]
]
++ listAttrs [ ] outpaths;
paths = map (attrs: attrs.path) list;
names = map lib.showAttrPath paths;
inherit (import ../../pkgs/stdenv/generic/problems.nix { inherit lib; })
disallowNixpkgsInternalUseKinds
;
# Determine the list of attributes whose packages have any meta.problems
# with a kind that's disallowed from internal Nixpkgs use
attrPathsDisallowedForInternalUse = lib.pipe list [
(lib.map (
attrs:
attrs
// {
problematicProblems = builtins.tryEval (
lib.filterAttrs (name: problem: disallowNixpkgsInternalUseKinds ? ${problem.kind}) (
attrs.value.meta.problems or { }
)
);
}
))
(lib.filter (attrs: attrs.problematicProblems.success && attrs.problematicProblems.value != { }))
(lib.map (attrs: {
attrPath = attrs.path;
reason = "it has certain meta.problems whose kinds are disallowed: ${
lib.generators.toPretty { } attrs.problematicProblems.value
}";
}))
];
in
{
# TODO: Do we still need these? Probably not
inherit paths names;
result = {
inherit paths attrPathsDisallowedForInternalUse;
};
}

View File

@@ -1,5 +1,2 @@
comparison
comparison.zip
node_modules
step-summary.md
*.tsbuildinfo

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
module.exports = async ({ github, context, core, dry }) => {
const path = require('node:path')
const { DefaultArtifactClient } = await import('@actions/artifact')
@@ -207,8 +206,20 @@ module.exports = async ({ github, context, core, dry }) => {
const maintainers = await getMaintainerMap(pull_request.base.ref)
const merge_bot_eligible = await handleMerge({
github,
context,
core,
log,
dry,
pull_request,
events,
maintainers,
getTeamMembers,
getUser,
})
// Check for any human reviews other than the PR author, GitHub actions and other GitHub apps.
// `commit { oid }` is needed by handleMerge to verify approvals are against the current head.
const reviews = (
await github.graphql(
`query($owner: String!, $repo: String!, $pr: Int!) {
@@ -220,7 +231,6 @@ module.exports = async ({ github, context, core, dry }) => {
reviews(first: 100) {
nodes {
state
commit { oid }
user: author {
# Only get users, no bots
... on User {
@@ -256,20 +266,6 @@ module.exports = async ({ github, context, core, dry }) => {
r.user.id !== pull_request.user?.id,
)
const merge_bot_eligible = await handleMerge({
github,
context,
core,
log,
dry,
pull_request,
events,
reviews,
maintainers,
getTeamMembers,
getUser,
})
const approvals = new Set(
reviews
.filter((review) => review.state === 'APPROVED')
@@ -396,13 +392,6 @@ module.exports = async ({ github, context, core, dry }) => {
pull_number,
per_page: 100,
})
// label llm-assisted PRs accordingly
const assistedByPattern = /Assisted-by: (?!nix-init)/i
evalLabels['llm-assisted'] = prCommits.some((c) =>
assistedByPattern.test(c.commit.message),
)
const commitSubjects = prCommits.map(
(c) => c.commit.message.split('\n')[0],
)

View File

@@ -0,0 +1,221 @@
/// @ts-check
// TODO: should this be combined with the branch checks in prepare.js?
// They do seem quite similar, but this needs to run after eval,
// and prepare.js obviously doesn't.
const { classify, split } = require('../supportedBranches.js')
const { readFile } = require('node:fs/promises')
const { postReview, dismissReviews } = require('./reviews.js')
const reviewKey = 'check-target-branch'
/**
* @param {{
* github: InstanceType<import('@actions/github/lib/utils').GitHub>,
* context: import('@actions/github/lib/context').Context
* core: import('@actions/core')
* dry: boolean
* }} CheckTargetBranchProps
*/
async function checkTargetBranch({ github, context, core, dry }) {
/**
* @type {{
* attrdiff: {
* added: string[],
* changed: string[],
* removed: string[],
* },
* attrdiffByKernel: Record<string, {
* added: string[],
* changed: string[],
* removed: string[],
* }>,
* attrdiffByPlatform: Record<string, {
* added: string[],
* changed: string[],
* removed: string[],
* }>,
* labels: Record<string, boolean>,
* rebuildCountByKernel: Record<string, number>,
* rebuildsByKernel: Record<string, string[]>,
* rebuildsByPlatform: Record<string, string[]>,
* }}
*/
const changed = JSON.parse(
await readFile('comparison/changed-paths.json', 'utf-8'),
)
const pull_number = context.payload.pull_request?.number
if (!pull_number) {
core.warning(
'Skipping checkTargetBranch: no pull_request number (is this being run as part of a merge group?)',
)
return
}
const prInfo = (
await github.rest.pulls.get({
...context.repo,
pull_number,
})
).data
const base = prInfo.base.ref
const head = prInfo.head.ref
const baseClassification = classify(base)
const headClassification = classify(head)
// Don't run on, e.g., staging-nixos to master merges.
if (headClassification.type.includes('development')) {
core.info(
`Skipping checkTargetBranch: PR is from a development branch (${head})`,
)
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
return
}
// Don't run on PRs against staging branches, wip branches, haskell-updates, etc.
if (!baseClassification.type.includes('primary')) {
core.info(
`Skipping checkTargetBranch: PR is against a non-primary base branch (${base})`,
)
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
return
}
const maxRebuildCount = Math.max(
...Object.values(changed.rebuildCountByKernel),
)
const rebuildsAllTests =
changed.attrdiff.changed.includes('nixosTests.simple-container') ||
changed.attrdiff.changed.includes('nixosTests.simple-vm')
// https://github.com/NixOS/nixpkgs/pull/521157
// These should go to master and release-xx.xx when backported
let isExemptKernelUpdate = false
if (prInfo.changed_files === 1) {
const changedFiles = (
await github.rest.pulls.listFiles({
...context.repo,
pull_number,
})
).data
isExemptKernelUpdate =
changedFiles.length === 1 &&
changedFiles[0].filename ===
'pkgs/os-specific/linux/kernel/xanmod-kernels.nix'
}
// https://github.com/NixOS/nixpkgs/pull/483194#issuecomment-3793393218
const isExemptHomeAssistantUpdate =
maxRebuildCount <= 1500 && head === 'wip-home-assistant'
core.info(
[
`checkTargetBranch: this PR:`,
` * causes ${maxRebuildCount} rebuilds`,
` * ${rebuildsAllTests ? 'rebuilds' : 'does not rebuild'} all NixOS tests`,
` * ${isExemptKernelUpdate ? 'is' : 'is not'} an exempt kernel update`,
` * ${isExemptHomeAssistantUpdate ? 'is' : 'is not'} an exempt home-assistant update`,
].join('\n'),
)
if (
maxRebuildCount >= 1000 &&
!isExemptHomeAssistantUpdate &&
!isExemptKernelUpdate
) {
const desiredBranch =
base === 'master' ? 'staging' : `staging-${split(base).version}`
const body = [
`The PR's base branch is set to \`${base}\`, but this PR causes ${maxRebuildCount} rebuilds.`,
'It is therefore considered a mass rebuild.',
`Please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) (probably \`${desiredBranch}\`).`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else if (rebuildsAllTests && !isExemptKernelUpdate) {
let branchText
if (base === 'master' && maxRebuildCount >= 500) {
branchText = '(probably either `staging-nixos` or `staging`)'
} else if (base === 'master') {
branchText = '(probably `staging-nixos`)'
} else if (maxRebuildCount >= 500) {
branchText = `(probably either \`staging-nixos-${split(base).version}\` or \`staging-${split(base).version}\`)`
} else {
branchText = `(probably \`staging-nixos-${split(base).version}\`)`
}
const body = [
`The PR's base branch is set to \`${base}\`, but this PR rebuilds all NixOS tests.`,
base === 'master' && maxRebuildCount >= 500
? `Since this PR also causes ${maxRebuildCount} rebuilds, it may also be considered a mass rebuild.`
: '',
`Please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) ${branchText}.`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else if (
maxRebuildCount >= 500 &&
!isExemptKernelUpdate &&
!isExemptHomeAssistantUpdate
) {
const stagingBranch =
base === 'master' ? 'staging' : `staging-${split(base).version}`
const body = [
`The PR's base branch is set to \`${base}\`, and this PR causes ${maxRebuildCount} rebuilds.`,
`Please consider whether this PR causes a mass rebuild according to [our conventions](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions).`,
`If it does cause a mass rebuild, please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) (probably \`${stagingBranch}\`).`,
`If it does not cause a mass rebuild, this message can be ignored.`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else {
core.info('checkTargetBranch: this PR is against an appropriate branch.')
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
}
}
module.exports = checkTargetBranch

View File

@@ -1,231 +0,0 @@
import type * as actionsCore from '@actions/core'
import type { context as actionsContext } from '@actions/github'
import type { GitHub } from '@actions/github/lib/utils'
// TODO: should this be combined with the branch checks in prepare.js?
// They do seem quite similar, but this needs to run after eval,
// and prepare.js obviously doesn't.
const { classify, split } = require('../supportedBranches.js')
const { readFile } = require('node:fs/promises')
const { postReview, dismissReviews } = require('./reviews.js')
const reviewKey = 'check-target-branch'
type ChangedPaths = {
attrdiff: {
added: string[]
changed: string[]
removed: string[]
}
attrdiffByKernel: Record<
string,
{
added: string[]
changed: string[]
removed: string[]
}
>
attrdiffByPlatform: Record<
string,
{
added: string[]
changed: string[]
removed: string[]
}
>
labels: Record<string, boolean>
rebuildCountByKernel: Record<string, number>
rebuildsByKernel: Record<string, string[]>
rebuildsByPlatform: Record<string, string[]>
}
async function checkTargetBranch({
github,
context,
core,
dry,
}: {
github: InstanceType<typeof GitHub>
context: typeof actionsContext
core: typeof actionsCore
dry: boolean
}) {
const changed: ChangedPaths = JSON.parse(
await readFile('comparison/changed-paths.json', 'utf-8'),
)
const pull_number = context.payload.pull_request?.number
if (!pull_number) {
core.warning(
'Skipping checkTargetBranch: no pull_request number (is this being run as part of a merge group?)',
)
return
}
const prInfo = (
await github.rest.pulls.get({
...context.repo,
pull_number,
})
).data
const base = prInfo.base.ref
const head = prInfo.head.ref
const baseClassification = classify(base)
const headClassification = classify(head)
// Don't run on, e.g., staging-nixos to master merges.
if (headClassification.type.includes('development')) {
core.info(
`Skipping checkTargetBranch: PR is from a development branch (${head})`,
)
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
return
}
// Don't run on PRs against staging branches, wip branches, haskell-updates, etc.
if (!baseClassification.type.includes('primary')) {
core.info(
`Skipping checkTargetBranch: PR is against a non-primary base branch (${base})`,
)
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
return
}
const maxRebuildCount = Math.max(
...Object.values(changed.rebuildCountByKernel),
)
const rebuildsAllTests =
changed.attrdiff.changed.includes('nixosTests.simple-container') ||
changed.attrdiff.changed.includes('nixosTests.simple-vm')
// https://github.com/NixOS/nixpkgs/pull/521157
// These should go to master and release-xx.xx when backported
let isExemptKernelUpdate = false
if (prInfo.changed_files === 1) {
const changedFiles = (
await github.rest.pulls.listFiles({
...context.repo,
pull_number,
})
).data
isExemptKernelUpdate =
changedFiles.length === 1 &&
changedFiles[0].filename ===
'pkgs/os-specific/linux/kernel/xanmod-kernels.nix'
}
// https://github.com/NixOS/nixpkgs/pull/483194#issuecomment-3793393218
const isExemptHomeAssistantUpdate =
maxRebuildCount <= 1500 && head === 'wip-home-assistant'
core.info(
[
`checkTargetBranch: this PR:`,
` * causes ${maxRebuildCount} rebuilds`,
` * ${rebuildsAllTests ? 'rebuilds' : 'does not rebuild'} all NixOS tests`,
` * ${isExemptKernelUpdate ? 'is' : 'is not'} an exempt kernel update`,
` * ${isExemptHomeAssistantUpdate ? 'is' : 'is not'} an exempt home-assistant update`,
].join('\n'),
)
if (
maxRebuildCount >= 1000 &&
!isExemptHomeAssistantUpdate &&
!isExemptKernelUpdate
) {
const desiredBranch =
base === 'master' ? 'staging' : `staging-${split(base).version}`
const body = [
`The PR's base branch is set to \`${base}\`, but this PR causes ${maxRebuildCount} rebuilds.`,
'It is therefore considered a mass rebuild.',
`Please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) (probably \`${desiredBranch}\`).`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else if (rebuildsAllTests && !isExemptKernelUpdate) {
let branchText: string
if (base === 'master' && maxRebuildCount >= 500) {
branchText = '(probably either `staging-nixos` or `staging`)'
} else if (base === 'master') {
branchText = '(probably `staging-nixos`)'
} else if (maxRebuildCount >= 500) {
branchText = `(probably either \`staging-nixos-${split(base).version}\` or \`staging-${split(base).version}\`)`
} else {
branchText = `(probably \`staging-nixos-${split(base).version}\`)`
}
const body = [
`The PR's base branch is set to \`${base}\`, but this PR rebuilds all NixOS tests.`,
base === 'master' && maxRebuildCount >= 500
? `Since this PR also causes ${maxRebuildCount} rebuilds, it may also be considered a mass rebuild.`
: '',
`Please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) ${branchText}.`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else if (
maxRebuildCount >= 500 &&
!isExemptKernelUpdate &&
!isExemptHomeAssistantUpdate
) {
const stagingBranch =
base === 'master' ? 'staging' : `staging-${split(base).version}`
const body = [
`The PR's base branch is set to \`${base}\`, and this PR causes ${maxRebuildCount} rebuilds.`,
`Please consider whether this PR causes a mass rebuild according to [our conventions](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions).`,
`If it does cause a mass rebuild, please [change the base branch](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-base-branch-of-a-pull-request) to [the right base branch for your changes](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#branch-conventions) (probably \`${stagingBranch}\`).`,
`If it does not cause a mass rebuild, this message can be ignored.`,
].join('\n')
await postReview({
github,
context,
core,
dry,
body,
event: 'REQUEST_CHANGES',
reviewKey,
})
} else {
core.info('checkTargetBranch: this PR is against an appropriate branch.')
await dismissReviews({
github,
context,
core,
dry,
reviewKey,
})
}
}
module.exports = checkTargetBranch

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
module.exports = async ({ github, context, core, dry, cherryPicks }) => {
const { execFileSync } = require('node:child_process')
const { classify } = require('../supportedBranches.js')

View File

@@ -1,4 +1,4 @@
// @ts-nocheck
// @ts-check
const { promisify } = require('node:util')
const execFile = promisify(require('node:child_process').execFile)
@@ -16,7 +16,7 @@ const execFile = promisify(require('node:child_process').execFile)
/**
* @param {{
* args: string[]
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* quiet?: boolean,
* repoPath?: string,
* }} RunGitProps
@@ -40,7 +40,7 @@ async function runGit({ args, repoPath, core, quiet }) {
* of 250 commits and doesn't return the changed files.
*
* @param {{
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* pr: Awaited<ReturnType<InstanceType<import('@actions/github/lib/utils').GitHub>["rest"]["pulls"]["get"]>>["data"]
* repoPath?: string,
* }} GetCommitMessagesForPRProps
@@ -76,7 +76,7 @@ async function getCommitDetailsForPR({ core, pr, repoPath }) {
return Promise.all(
shas.map(async (sha) => {
// Subject, author name, author email, committer name, committer email (all tab-separated)
// Subject, author name, author email, committer name, committer email (all tab-seperated)
// then a blank line, then filenames.
const result = (
await runGit({

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
const excludeTeams = [
/^voters.*$/,
/^nixpkgs-maintainers$/,

View File

@@ -1,3 +1,4 @@
// @ts-check
const { classify } = require('../supportedBranches.js')
const { getCommitDetailsForPR } = require('./get-pr-commit-details.js')
@@ -5,9 +6,9 @@ const { getCommitDetailsForPR } = require('./get-pr-commit-details.js')
/**
* @param {{
* github: InstanceType<typeof import('@actions/github/lib/utils').GitHub>,
* github: InstanceType<import('@actions/github/lib/utils').GitHub>,
* context: typeof import('@actions/github').context,
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* repoPath?: string,
* }} LintCommitsProps
*/
@@ -56,7 +57,7 @@ async function lintCommits({ github, context, core, repoPath }) {
/**
* @param {{
* commits: Commit[],
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* }} CheckCommitMessagesProps
*/
async function checkCommitMessages({ commits, core }) {
@@ -73,10 +74,8 @@ async function checkCommitMessages({ commits, core }) {
'fix',
'perf',
'refactor',
'services',
'style',
'test',
'update',
]
/**
@@ -169,7 +168,7 @@ async function checkCommitMessages({ commits, core }) {
/**
* @param {{
* commits: Commit[],
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* }} CheckGitFieldsProps
*/
async function checkCommitMetadata({ commits, core }) {

View File

@@ -1,11 +1,12 @@
// @ts-check
const { classify } = require('../supportedBranches.js')
const { getCommitDetailsForPR } = require('./get-pr-commit-details')
/**
* @param {{
* github: InstanceType<typeof import('@actions/github/lib/utils').GitHub>,
* context: typeof import('@actions/github').context,
* core: typeof import('@actions/core'),
* github: InstanceType<import('@actions/github/lib/utils').GitHub>,
* context: import('@actions/github/lib/context').Context,
* core: import('@actions/core'),
* repoPath?: string,
* dry: boolean,
* }} CheckManualFileEditsProps

View File

@@ -1,13 +1,12 @@
// @ts-nocheck
const { classify } = require('../supportedBranches.js')
function runChecklist({
committers,
events,
files,
pull_request,
log,
maintainers,
reviews,
user,
userIsMaintainer,
}) {
@@ -28,35 +27,18 @@ function runChecklist({
.reduce((acc, cur) => acc?.intersection(cur) ?? cur)
const approvals = new Set(
reviews
events
.filter(
({ state, commit }) =>
state === 'APPROVED' &&
({ event, state, commit_id }) =>
event === 'reviewed' &&
state === 'approved' &&
// Only approvals for the current head SHA count, otherwise authors could push
// bad code between the approval and the merge.
commit?.oid === pull_request.head.sha,
commit_id === pull_request.head.sha,
)
.map(({ user }) => user.id),
)
// A "changes requested" review from a committer blocks both the merge queue and
// auto-merge, even if it was made on an older commit (unlike approvals, GitHub does
// not auto-dismiss changes-requested reviews on push). For each committer, take their
// latest actionable review; if it's CHANGES_REQUESTED, they're blocking the PR.
// Dismissed reviews surface as DISMISSED and comment-only follow-ups as COMMENTED, so
// both are skipped naturally — the prior actionable review still stands until the
// committer explicitly approves or requests changes again.
const committerReviewState = new Map()
for (const { user, state } of reviews) {
if (
committers.has(user.id) &&
['APPROVED', 'CHANGES_REQUESTED'].includes(state)
) {
committerReviewState.set(user.id, state)
}
}
const noBlockingReviews = !Array.from(committerReviewState.values()).includes(
'CHANGES_REQUESTED',
.map(({ user }) => user?.id)
// Some users have been deleted, so filter these out.
.filter(Boolean),
)
const checklist = {
@@ -75,11 +57,6 @@ function runChecklist({
pull_request.user.login === 'r-ryantm',
},
'PR is not a draft': !pull_request.draft,
// CI state is intentionally *not* a checklist item: auto-merge exists precisely to
// cover unfinished CI, and an already-failed CI is reported via the merge message
// (see merge() below) rather than a blanket refusal.
'PR is not blocked by a "changes requested" review from a [committer](https://github.com/orgs/NixOS/teams/nixpkgs-committers).':
noBlockingReviews,
}
if (user) {
@@ -146,7 +123,6 @@ async function handleMerge({
dry,
pull_request,
events,
reviews,
maintainers,
getTeamMembers,
getUser,
@@ -172,14 +148,6 @@ async function handleMerge({
// including an early exit when the first non-by-name file is found.
if (files.length >= 100) return false
const noPrFailuresState = (
await github.rest.repos.listCommitStatusesForRef({
...context.repo,
ref: pull_request.head.sha,
per_page: 100,
})
).data.find(({ context }) => context === 'no PR failures')?.state
// Only look through comments *after* the latest (force) push.
const lastPush = events.findLastIndex(
({ event, sha, commit_id }) =>
@@ -205,12 +173,10 @@ async function handleMerge({
)),
)
// Returns `{ reaction, messages }`: the reaction to leave on the merge comment and the
// lines to append to the bot's reply. Throws only on an unexpected API error.
async function merge() {
if (dry) {
core.info(`Merging #${pull_number}... (dry)`)
return { reaction: 'ROCKET', messages: ['Merge completed (dry)'] }
return ['Merge completed (dry)']
}
// Using GraphQL mutations instead of the REST /merge endpoint, because the latter
@@ -231,37 +197,16 @@ async function handleMerge({
{ node_id: pull_request.node_id, sha: pull_request.head.sha },
)
log('merge', 'Queued for merge')
return {
reaction: 'ROCKET',
messages: [
`:heavy_check_mark: [Queued](${resp.enqueuePullRequest.mergeQueueEntry.mergeQueue.url}) for merge (#306934)`,
],
}
return [
`:heavy_check_mark: [Queued](${resp.enqueuePullRequest.mergeQueueEntry.mergeQueue.url}) for merge (#306934)`,
]
} catch (e) {
log('Enqueuing failed', e.response.errors[0].message)
}
// Enqueuing fails when the required status checks are not satisfied, yet. If CI has
// already failed, enabling auto-merge would be pointless: it would never fire, and
// fixing CI requires a new push, which invalidates this merge command anyway (we only
// act on comments after the latest push). So we don't enable auto-merge and instead
// ask for a fresh command once CI is green again.
if (['error', 'failure'].includes(noPrFailuresState)) {
log('merge', 'CI has failed, not enabling auto-merge')
return {
reaction: 'THUMBS_DOWN',
messages: [
':x: Pull Request could not be merged: CI has failed (#305350).',
'',
'> [!TIP]',
'> PRs cannot be merged while CI is failing.',
'> Once CI is passing, comment `@NixOS/nixpkgs-merge-bot merge` again.',
],
}
}
// CI has not finished yet, so we enable auto-merge. We could also only use auto-merge,
// but this often gets stuck for no apparent reason.
// If required status checks are not satisfied, yet, the above will fail. In this case
// we can enable auto-merge. We could also only use auto-merge, but this often gets
// stuck for no apparent reason.
try {
await github.graphql(
`mutation($node_id: ID!, $sha: GitObjectID) {
@@ -274,17 +219,12 @@ async function handleMerge({
{ node_id: pull_request.node_id, sha: pull_request.head.sha },
)
log('merge', 'Auto-merge enabled')
return {
reaction: 'ROCKET',
messages: [
`:heavy_check_mark: Enabled Auto Merge (#306934)`,
'',
'> [!TIP]',
'> [Auto Merge](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/automatically-merging-a-pull-request) will queue this PR once required CI checks succeed.',
'> If CI fails instead, fixing it needs a new push, which disables Auto Merge and invalidates this command — comment `@NixOS/nixpkgs-merge-bot merge` again once CI is green.',
'> If GitHub gets stuck even though CI passed (it sometimes does), leaving another approval should kick off the merge.',
],
}
return [
`:heavy_check_mark: Enabled Auto Merge (#306934)`,
'',
'> [!TIP]',
'> Sometimes GitHub gets stuck after enabling Auto Merge. In this case, leaving another approval should trigger the merge.',
]
} catch (e) {
log('Auto Merge failed', e.response.errors[0].message)
throw new Error(e.response.errors[0].message)
@@ -327,11 +267,11 @@ async function handleMerge({
const { result, eligible, checklist } = runChecklist({
committers,
events,
files,
pull_request,
log,
maintainers,
reviews,
user: comment.user,
userIsMaintainer: await isMaintainer(comment.user.login),
})
@@ -368,12 +308,10 @@ async function handleMerge({
}
if (result) {
await react('ROCKET')
try {
const { reaction, messages } = await merge()
await react(reaction)
body.push(...messages)
body.push(...(await merge()))
} catch (e) {
await react('THUMBS_DOWN')
// Remove the HTML comment with node_id reference to allow retrying this merge on the next run.
body.shift()
body.push(`:x: Merge failed with: ${e} (#371492)`)
@@ -398,11 +336,11 @@ async function handleMerge({
const { result } = runChecklist({
committers,
events,
files,
pull_request,
log,
maintainers,
reviews,
})
// Returns a boolean, which indicates whether the PR is merge-bot eligible in principle.

View File

@@ -4,17 +4,13 @@
"requires": true,
"packages": {
"": {
"name": "github-script",
"dependencies": {
"@actions/artifact": "6.2.1",
"@actions/core": "1.10.1",
"@actions/github": "9.1.0",
"bottleneck": "2.19.5",
"commander": "14.0.3"
},
"devDependencies": {
"@tsconfig/node24": "24.0.4",
"@types/node": "24.13.3",
"typescript": "7.0.2"
}
},
"node_modules/@actions/artifact": {
@@ -593,19 +589,6 @@
"protoc-gen-ts": "bin/protoc-gen-ts"
}
},
"node_modules/@protobuf-ts/plugin/node_modules/typescript": {
"version": "3.9.10",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-3.9.10.tgz",
"integrity": "sha512-w6fIxVE/H1PkLKcCPsFqKE7Kv7QUwhU8qQY2MueZXWx5cPZdwFupLgKK3vntcK98BtNHZtAF4LA/yl2a7k8R6Q==",
"license": "Apache-2.0",
"bin": {
"tsc": "bin/tsc",
"tsserver": "bin/tsserver"
},
"engines": {
"node": ">=4.2.0"
}
},
"node_modules/@protobuf-ts/protoc": {
"version": "2.11.1",
"resolved": "https://registry.npmjs.org/@protobuf-ts/protoc/-/protoc-2.11.1.tgz",
@@ -630,343 +613,6 @@
"@protobuf-ts/runtime": "^2.11.1"
}
},
"node_modules/@tsconfig/node24": {
"version": "24.0.4",
"resolved": "https://registry.npmjs.org/@tsconfig/node24/-/node24-24.0.4.tgz",
"integrity": "sha512-2A933l5P5oCbv6qSxHs7ckKwobs8BDAe9SJ/Xr2Hy+nDlwmLE1GhFh/g/vXGRZWgxBg9nX/5piDtHR9Dkw/XuA==",
"dev": true,
"license": "MIT"
},
"node_modules/@types/node": {
"version": "24.13.3",
"resolved": "https://registry.npmjs.org/@types/node/-/node-24.13.3.tgz",
"integrity": "sha512-Dh8vAsV36ig5wa9OX4pXvMc9D3Veibfw2wix0CUwYODLD8nkj9UsLjASr49nPg+2eKzxhBV+v7L8pXvT4e639Q==",
"dev": true,
"license": "MIT",
"dependencies": {
"undici-types": "~7.18.0"
}
},
"node_modules/@typescript/typescript-aix-ppc64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-aix-ppc64/-/typescript-aix-ppc64-7.0.2.tgz",
"integrity": "sha512-MTKKkWB7p/0E9xi1d1tHtZ5PiLkGEMIq88pK2CubZjOsLtYTLqhgIgi6zepFa+9GHZ6h05NMCkQxGKiPXMxXtQ==",
"cpu": [
"ppc64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"aix"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-darwin-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-darwin-arm64/-/typescript-darwin-arm64-7.0.2.tgz",
"integrity": "sha512-gowzar9MwS/aRWp6f3a4KUqzRjAZjOsmGNCM6LcTgXum+dBfgsBVMN+AgvOCCbguXyick6LJhpBszxMebJ8syA==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"darwin"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-darwin-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-darwin-x64/-/typescript-darwin-x64-7.0.2.tgz",
"integrity": "sha512-SZ9xZInqApNlNGc9s0W1VSsktYSOe9cFqNOIqmN1Gs8SmkjKZYFt017G4VwPxASInODuAdbTW7sXiFUf893RgA==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"darwin"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-freebsd-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-freebsd-arm64/-/typescript-freebsd-arm64-7.0.2.tgz",
"integrity": "sha512-W5NH4y/J0plIIS5b2xvTEkU7JFxyqdMAOgf+Ilhl0vHQXKO5dZoxd+C/jEtq56c4F3wk71RB4BMRQ2XdI+bwYQ==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"freebsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-freebsd-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-freebsd-x64/-/typescript-freebsd-x64-7.0.2.tgz",
"integrity": "sha512-UMGDx5sTpzNw3WiPebH7l90IWfJggEd+egHt/q6p7/Cm3zqoV7VxkGXt+3DxPIw8CcmvAB0j3sVVfbhX+M4Tpw==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"freebsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-arm": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-arm/-/typescript-linux-arm-7.0.2.tgz",
"integrity": "sha512-gffT3xPz9sR7j/YJExkyPntrI0P2EP9XbOyWzth2/Gs0RstK+90RBcO0ncXoXy/beYll1SXw846Nf2zdnEz0QQ==",
"cpu": [
"arm"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-arm64/-/typescript-linux-arm64-7.0.2.tgz",
"integrity": "sha512-Qh4eU4/y3yDjnfjjyPYihMj5/ODIlmt+Bzu17OI+fiSRDW57QmU5SiN63exPRNJPKUzcc1INa1NXdrJ+MqHjUQ==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-loong64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-loong64/-/typescript-linux-loong64-7.0.2.tgz",
"integrity": "sha512-uEHck9i8hoAzXPiYRib1O7miOnz23SxIeVl6F4LXox+qov1K35jHcEW6VHKvZI+pyvl7fZEP4MCU5LYvIq1GuQ==",
"cpu": [
"loong64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-mips64el": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-mips64el/-/typescript-linux-mips64el-7.0.2.tgz",
"integrity": "sha512-R4KvAMnE43W5Qeqb0Ly56O3mWMWIAgsMyz36DCaycd5nbg/9kzm0liw3JocfRqyJY0KPmzFjbswozXyW0DnIYA==",
"cpu": [
"mips64el"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-ppc64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-ppc64/-/typescript-linux-ppc64-7.0.2.tgz",
"integrity": "sha512-DORx5b3sd/4S7eayxm4FQv+A7CrkUIGRaHiwI8oiHTAI1fAPWhF4J0vAlkC8biAlHSVVwxMQ3tjZ2/DVbnQiiA==",
"cpu": [
"ppc64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-riscv64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-riscv64/-/typescript-linux-riscv64-7.0.2.tgz",
"integrity": "sha512-wf0jqEDOjrPRnKwYRyyJDRo11KMbvMFrU+q4zqKyChODBzvlkbhNQfKvLxQCcwTpdDaXSHZTVuh0JoCrKCUMHQ==",
"cpu": [
"riscv64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-s390x": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-s390x/-/typescript-linux-s390x-7.0.2.tgz",
"integrity": "sha512-IkwJc3L7yhytWd/ewjyxNDfOmswCm9GWMJT/ue/dU4aZNbwZeYAetq42VyLmsmSjvoX7z74X6ZaYCtzAr0EuGw==",
"cpu": [
"s390x"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-linux-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-linux-x64/-/typescript-linux-x64-7.0.2.tgz",
"integrity": "sha512-EYdf2cNg7rgCWJnxCdJ+F3V39O8ihb37eHAu1LK8oAFizgTQbPOK7zHHXbPt8rX24COqODXeI3sIf0fCXG7H/A==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"linux"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-netbsd-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-netbsd-arm64/-/typescript-netbsd-arm64-7.0.2.tgz",
"integrity": "sha512-+polYF4MF04aPpO5FTkHran9yUQDSXqy5GiSDKpsll5jy3l3+g9QLhpf39T+ePtefhXLOGrLl0QIjkQP6VnelA==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"netbsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-netbsd-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-netbsd-x64/-/typescript-netbsd-x64-7.0.2.tgz",
"integrity": "sha512-8YIT0EHM/3dq10ZOVF/A7pc/YSMtbcecct4rWtexrnSCHOPcpC2KTLXfTCR6vDpnSiY12heNb1GiN/wu+T/FyA==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"netbsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-openbsd-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-openbsd-arm64/-/typescript-openbsd-arm64-7.0.2.tgz",
"integrity": "sha512-APT8+ClYnuYm1u9+kgGXoMj2VzWzcymwh2gNSQVySHfkRDGOTVkoWLjCmOQSaO+PoqQ57B0flRp9SA+7GnnkzQ==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"openbsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-openbsd-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-openbsd-x64/-/typescript-openbsd-x64-7.0.2.tgz",
"integrity": "sha512-yX7s+Q0Dln0Dt9tEzZsAjXXR/+ytBM7AlglaqyeMPxQszJ1JhlJdZ6jLA+IzldHtflX81em7lDao1xXu+aRRkg==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"openbsd"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-sunos-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-sunos-x64/-/typescript-sunos-x64-7.0.2.tgz",
"integrity": "sha512-dLJDGaLZ1D4HPQn62u1n8mBDkJREwMsAkCdkwd4Ieqw+x3TUyTsqY0YiBCtE6H6OzzgGk3iuZ3vFWRS+E8/d1g==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"sunos"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-win32-arm64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-win32-arm64/-/typescript-win32-arm64-7.0.2.tgz",
"integrity": "sha512-Gyl1Vy6OsWesLzmq+EP0Fb7b4Nid5232AvcA2SFcdYreldpNtYFFofPjnt62y9hQy7VTaZp65ICJjuAQRaVcIQ==",
"cpu": [
"arm64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"win32"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/typescript-win32-x64": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/@typescript/typescript-win32-x64/-/typescript-win32-x64-7.0.2.tgz",
"integrity": "sha512-0BQ3HkAHHlKLSp1qRvf3SUhGpGsDuhB/jgFw75guyqbxJqEaS0Cw/VFO8i2nHglJUzQCRtMMR/IBAKE3ETMC4g==",
"cpu": [
"x64"
],
"license": "Apache-2.0",
"optional": true,
"os": [
"win32"
],
"engines": {
"node": ">=16.20.0"
}
},
"node_modules/@typescript/vfs": {
"version": "1.6.1",
"resolved": "https://registry.npmjs.org/@typescript/vfs/-/vfs-1.6.1.tgz",
@@ -2012,37 +1658,16 @@
}
},
"node_modules/typescript": {
"version": "7.0.2",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-7.0.2.tgz",
"integrity": "sha512-8FYau96o3NKOhbjKi/qNvG/W5jhzxkbdm5sj9AbZ/5T5sWqn3hJgLfGx27sRKZWTvyzCP8dLRBTf5tBTSRVUNA==",
"version": "3.9.10",
"resolved": "https://registry.npmjs.org/typescript/-/typescript-3.9.10.tgz",
"integrity": "sha512-w6fIxVE/H1PkLKcCPsFqKE7Kv7QUwhU8qQY2MueZXWx5cPZdwFupLgKK3vntcK98BtNHZtAF4LA/yl2a7k8R6Q==",
"license": "Apache-2.0",
"bin": {
"tsc": "bin/tsc"
"tsc": "bin/tsc",
"tsserver": "bin/tsserver"
},
"engines": {
"node": ">=16.20.0"
},
"optionalDependencies": {
"@typescript/typescript-aix-ppc64": "7.0.2",
"@typescript/typescript-darwin-arm64": "7.0.2",
"@typescript/typescript-darwin-x64": "7.0.2",
"@typescript/typescript-freebsd-arm64": "7.0.2",
"@typescript/typescript-freebsd-x64": "7.0.2",
"@typescript/typescript-linux-arm": "7.0.2",
"@typescript/typescript-linux-arm64": "7.0.2",
"@typescript/typescript-linux-loong64": "7.0.2",
"@typescript/typescript-linux-mips64el": "7.0.2",
"@typescript/typescript-linux-ppc64": "7.0.2",
"@typescript/typescript-linux-riscv64": "7.0.2",
"@typescript/typescript-linux-s390x": "7.0.2",
"@typescript/typescript-linux-x64": "7.0.2",
"@typescript/typescript-netbsd-arm64": "7.0.2",
"@typescript/typescript-netbsd-x64": "7.0.2",
"@typescript/typescript-openbsd-arm64": "7.0.2",
"@typescript/typescript-openbsd-x64": "7.0.2",
"@typescript/typescript-sunos-x64": "7.0.2",
"@typescript/typescript-win32-arm64": "7.0.2",
"@typescript/typescript-win32-x64": "7.0.2"
"node": ">=4.2.0"
}
},
"node_modules/undici": {
@@ -2057,13 +1682,6 @@
"node": ">=14.0"
}
},
"node_modules/undici-types": {
"version": "7.18.2",
"resolved": "https://registry.npmjs.org/undici-types/-/undici-types-7.18.2.tgz",
"integrity": "sha512-AsuCzffGHJybSaRrmr5eHr81mwJU3kjw6M+uprWvCXiNeN9SOGwQ3Jn8jb8m3Z6izVgknn1R0FTCEAP2QrLY/w==",
"dev": true,
"license": "MIT"
},
"node_modules/universal-user-agent": {
"version": "7.0.3",
"resolved": "https://registry.npmjs.org/universal-user-agent/-/universal-user-agent-7.0.3.tgz",

View File

@@ -2,7 +2,9 @@
"private": true,
"//": [
"Keep `@actions/core` and `@actions/github` in sync with",
"https://github.com/actions/github-script/blob/main/package.json."
"https://github.com/actions/github-script/blob/main/package.json.",
"Keep `@actions/artifact` and `bottleneck` in sync with",
"`.github/workflows/bot.yml`."
],
"dependencies": {
"@actions/artifact": "6.2.1",
@@ -10,10 +12,5 @@
"@actions/github": "9.1.0",
"bottleneck": "2.19.5",
"commander": "14.0.3"
},
"devDependencies": {
"@tsconfig/node24": "24.0.4",
"@types/node": "24.13.3",
"typescript": "7.0.2"
}
}

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
const { classify } = require('../supportedBranches.js')
const { postReview, dismissReviews } = require('./reviews.js')
const reviewKey = 'prepare'

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
async function handleReviewers({
github,
context,

View File

@@ -1,3 +1,5 @@
// @ts-check
const eventToState = {
COMMENT: 'COMMENTED',
REQUEST_CHANGES: 'CHANGES_REQUESTED',
@@ -14,7 +16,7 @@ const reviewUsers = [
]
/**
* @typedef {InstanceType<typeof import('@actions/github/lib/utils').GitHub>} GitHub
* @typedef {InstanceType<import('@actions/github/lib/utils').GitHub>} GitHub
* @typedef {typeof import('@actions/github').context} Context
*
* @typedef {Awaited<ReturnType<GitHub['rest']['pulls']['listReviews']>>['data'][number]} Review
@@ -25,7 +27,7 @@ const reviewUsers = [
* @param {{
* github: GitHub,
* context: Context,
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* dry: boolean,
* reviewKey?: string,
* }} DismissReviewsProps
@@ -163,10 +165,10 @@ async function dismissReviews({ github, context, core, dry, reviewKey }) {
* @param {{
* github: GitHub,
* context: Context,
* core: typeof import('@actions/core'),
* core: import('@actions/core'),
* dry: boolean,
* body: string,
* event: keyof typeof eventToState,
* event: keyof eventToState,
* reviewKey: string,
* }} PostReviewProps
*/

View File

@@ -112,8 +112,8 @@ program
.argument('<repo>', 'Name of the GitHub repository to run on (Example: nixpkgs)')
.argument('<pr>', 'Number of the Pull Request to run on')
.action(async (owner, repo, pr, options) => {
const checkTargetBranch = (await import('./check-target-branch.ts')).default
await run(checkTargetBranch, owner, repo, pr, options)
const checkCommitMessages = (await import('./check-target-branch.js')).default
await run(checkCommitMessages, owner, repo, pr, options)
})
program

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
module.exports = async ({ github, context, targetSha }) => {
const { content, encoding } = (
await github.rest.repos.getContent({

View File

@@ -1,26 +0,0 @@
{
"compilerOptions": {
"lib": [
"es2024",
"ESNext.Array",
"ESNext.Collection",
"ESNext.Error",
"ESNext.Iterator",
"ESNext.Promise"
],
"module": "nodenext",
"target": "es2024",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"moduleResolution": "node16",
"allowImportingTsExtensions": true,
"allowJs": true,
"checkJs": true,
"erasableSyntaxOnly": true,
"verbatimModuleSyntax": true,
"noEmit": true,
}
}

View File

@@ -1,4 +1,3 @@
// @ts-nocheck
module.exports = async ({ github, core, maxConcurrent = 1 }, callback) => {
const Bottleneck = require('bottleneck')

View File

@@ -9,22 +9,22 @@
},
"branch": "nixpkgs-unstable",
"submodules": false,
"revision": "7525d999cd850b9a488817abc89c75dc733acf17",
"url": "https://github.com/NixOS/nixpkgs/archive/7525d999cd850b9a488817abc89c75dc733acf17.tar.gz",
"hash": "sha256-4IHyyLgLBdKefkljdKod4IMn023pQiDXAWJA187cmdY="
"revision": "cbb5cf358f50aa6acc9efd6113b7bcfbc352cd73",
"url": "https://github.com/NixOS/nixpkgs/archive/cbb5cf358f50aa6acc9efd6113b7bcfbc352cd73.tar.gz",
"hash": "sha256-IX7G1dlKrOqPOImfbo7ADDfV5yU1+j+MRChI3TL4tAA="
},
"nixpkgs-26.05-darwin": {
"treefmt-nix": {
"type": "Git",
"repository": {
"type": "GitHub",
"owner": "NixOS",
"repo": "nixpkgs"
"owner": "numtide",
"repo": "treefmt-nix"
},
"branch": "nixpkgs-26.05-darwin",
"branch": "main",
"submodules": false,
"revision": "51fe96f9107566e6b8eeb7fc4ba696c01e548b04",
"url": "https://github.com/NixOS/nixpkgs/archive/51fe96f9107566e6b8eeb7fc4ba696c01e548b04.tar.gz",
"hash": "sha256-yj0LPLnsmYoLmA3FGANjeTEwej0/DHjZBXWnDQDUuIs="
"revision": "db947814a175b7ca6ded66e21383d938df01c227",
"url": "https://github.com/numtide/treefmt-nix/archive/db947814a175b7ca6ded66e21383d938df01c227.tar.gz",
"hash": "sha256-eynAfOmbmxJnkp7YewvCEbShNnnYJ9gLLqkzsYtBPeM="
}
},
"version": 8

View File

@@ -2,7 +2,6 @@
/*
#!nix-shell -i node -p nodejs
*/
// @ts-nocheck
const typeConfig = {
master: ['development', 'primary'],

View File

@@ -1,175 +0,0 @@
{
lib,
pkgs,
...
}:
{
runtimeInputs = [
# tree-root uses `git rev-parse --show-toplevel`
pkgs.gitMinimal
];
settings = {
# numtide/treefmt-nix defaults
excludes = [
"*.lock"
"*.patch"
"*.diff"
"package-lock.json"
"go.mod"
"go.sum"
".gitattributes"
".gitignore"
".gitmodules"
"COPYING"
"LICENSE"
];
# Be a bit more verbose by default, so we can see progress happening
verbose = 1;
# By default it's info, which is too noisy since we have many unmatched files
on-unmatched = "debug";
formatter = {
# keep-sorted start block=yes newline_separated=yes
actionlint = {
command = lib.getExe pkgs.actionlint;
includes = [
".github/workflows/*.yml"
".github/workflows/*.yaml"
];
};
biome = {
command = lib.getExe pkgs.biome;
excludes = [
"*.min.js"
"pkgs/*"
];
includes = [
"*.js"
"*.ts"
"*.mjs"
"*.mts"
"*.cjs"
"*.cts"
"*.jsx"
"*.tsx"
"*.d.ts"
"*.d.cts"
"*.d.mts"
"*.css"
];
options = [
"check"
"--write"
"--no-errors-on-unmatched"
"--use-editorconfig=true"
"--javascript-formatter-quote-style=single"
"--semicolons=as-needed"
];
};
editorconfig-checker = {
command = lib.getExe pkgs.editorconfig-checker;
options = [
"-disable-indent-size"
# TODO: Remove this once this upstream issue is fixed:
# https://github.com/editorconfig-checker/editorconfig-checker/issues/505
"-disable-charset"
];
includes = [ "*" ];
priority = 1;
};
keep-sorted = {
command = lib.getExe pkgs.keep-sorted;
includes = [ "*" ];
};
markdown-code-runner = {
command = lib.getExe pkgs.markdown-code-runner;
options =
let
config = pkgs.writers.writeTOML "markdown-code-runner-config" {
presets.nixfmt = {
language = "nix";
command = [ (lib.getExe pkgs.nixfmt) ];
};
};
in
[ "--config=${config}" ];
includes = [ "*.md" ];
};
nixf-diagnose = {
command = lib.getExe pkgs.nixf-diagnose;
excludes = [
# Auto-generated; violates sema-extra-with
# Can only sensibly be removed when --auto-fix supports multiple fixes at once:
# https://github.com/inclyc/nixf-diagnose/issues/13
"pkgs/servers/home-assistant/component-packages.nix"
# https://github.com/nix-community/nixd/issues/708
"nixos/maintainers/scripts/azure-new/examples/basic/system.nix"
];
includes = [ "*.nix" ];
options = [
"--auto-fix"
# Rule names can currently be looked up here:
# https://github.com/nix-community/nixd/blob/main/libnixf/src/Basic/diagnostic.py
# TODO: Remove the following and fix things.
"--ignore=sema-unused-def-lambda-noarg-formal"
"--ignore=sema-unused-def-lambda-witharg-arg"
"--ignore=sema-unused-def-lambda-witharg-formal"
"--ignore=sema-unused-def-let"
# TODO: remove after outstanding prelude diagnostics issues are fixed:
# https://github.com/nix-community/nixd/issues/761
# https://github.com/nix-community/nixd/issues/762
"--ignore=sema-primop-removed-prefix"
"--ignore=sema-primop-overridden"
"--ignore=sema-constant-overridden"
"--ignore=sema-primop-unknown"
];
# Ensure nixfmt cleans up after nixf-diagnose.
priority = -1;
};
# This uses nixfmt underneath, the default formatter for Nix code.
# See https://github.com/NixOS/nixfmt
nixfmt = {
command = lib.getExe pkgs.nixfmt;
includes = [ "*.nix" ];
};
yamlfmt = {
command = lib.getExe pkgs.yamlfmt;
excludes = [
# Aligns comments with whitespace
"pkgs/development/haskell-modules/configuration-hackage2nix/main.yaml"
# TODO: Fix formatting for auto-generated file
"pkgs/development/haskell-modules/configuration-hackage2nix/transitive-broken.yaml"
];
includes = [
"*.yaml"
"*.yml"
];
options = [
"-formatter"
"retain_line_breaks=true"
];
};
zizmor = {
command = lib.getExe pkgs.zizmor;
includes = [
".github/workflows/*.yml"
".github/workflows/*.yaml"
".github/actions/**/*.yml"
".github/actions/**/*.yaml"
];
};
# keep-sorted end
};
};
}

View File

@@ -1,5 +1,5 @@
#!/usr/bin/env nix-shell
#!nix-shell -i bash -E 'with import ../. {}; mkShell { packages = [ npins ]; }'
#!nix-shell -i bash -p npins -I nixpkgs=../
set -euo pipefail

View File

@@ -1,27 +1,21 @@
# Contributing to the Nixpkgs manual
# Contributing to the Nixpkgs reference manual
This directory houses the source files for the Nixpkgs manual.
This directory houses the source files for the Nixpkgs reference manual.
> [!NOTE]
> [!IMPORTANT]
> We are actively restructuring our documentation to follow the [Diátaxis framework](https://diataxis.fr/)
>
> We are actively restructuring our documentation to be more beginner friendly.
> Going forward, this directory should **only** contain [reference documentation](https://nix.dev/contributing/documentation/diataxis#reference).
> For tutorials, guides and explanations, contribute to <https://nix.dev/> instead.
>
> We are actively working to generate **all** reference documentation from the [doc-comments](https://github.com/NixOS/rfcs/blob/master/rfcs/0145-doc-strings.md) present in code.
> This also provides the benefit of using `:doc` in the `nix repl` to view reference documentation locally on the fly.
When writing new docs use **Progressive Disclosure**
For documentation only relevant for contributors, use Markdown files next to the source and regular code comments.
Start simple, pick up beginners.
Use **examples** first to show how to get something done. Keep **Explanation** lean.
Use our [styleguide](./styleguide.md) for more in depth guidance on writing good documentation.
Documentation about Nixpkgs belongs here, this includes 'getting-started'-guides and 'onboarding-guides' for *using* Nixpkgs and the language frameworks it ships.
Write **guides** task-first: lead with a working example, then explain in prose.
Write **reference** as the specification of functions and attributes.
We are actively working to generate reference documentation from the [doc-comments](https://github.com/NixOS/rfcs/blob/master/rfcs/0145-doc-strings.md) present in code, which also lets you view it locally with `:doc` in `nix repl`.
See [Document structure](#document-structure) for a structural template.
> [!TIP]
> Feedback for improving support for parsing and rendering doc-comments is highly appreciated.
> [Open an issue](https://github.com/NixOS/nixpkgs/issues/new?labels=6.topic%3A+documentation&title=Doc%3A+) to request bugfixes or new features.
Rendered documentation:
- [Unstable (from master)](https://nixos.org/manual/nixpkgs/unstable/)
@@ -42,7 +36,7 @@ If the build succeeds, the manual will be in `./result/share/doc/nixpkgs/manual.
### Development environment
To reduce repetition, consider using tools from the provided development environment:
In order to reduce repetition, consider using tools from the provided development environment:
Load it from the Nixpkgs documentation directory with
@@ -60,11 +54,9 @@ Make sure that your local files aren't added to Git history by adding the follow
/**/.direnv
```
#### Live preview
#### `devmode`
Run [`devmode`](../pkgs/by-name/de/devmode/README.md) for a live preview while editing the manual: it rebuilds on every change and reloads the page in your browser automatically.
Changes to the renderer 'pkgs/by-name/ni/nixos-render-docs' need a manual restart. Run: `devmode` again.
Use [`devmode`](../pkgs/by-name/de/devmode/README.md) for a live preview when editing the manual.
### Testing redirects
@@ -193,15 +185,15 @@ watermelon
- If creating a commit purely for documentation changes, format the commit message in the following way:
```
doc/component: (documentation summary)
doc: (documentation summary)
(Motivation for change, relevant links, additional information.)
```
Examples:
* doc/stdenv: update the kernel config documentation to use `nix-shell`
* doc/getting-started: add information about `nix-update-script`
* doc: update the kernel config documentation to use `nix-shell`
* doc: add information about `nix-update-script`
Closes #216321.
@@ -217,62 +209,6 @@ You, as the writer of documentation, are still in charge of its content.
**For prose style, see the [documentation styleguide](./styleguide.md).**
### Document structure
Organize each chapter as guide sections first, then a single `## Reference` section.
A well-structured chapter looks like this:
````markdown
# Foo {#foo}
`foo` builds Foo projects from a `foo.toml`.
## Package a Foo application {#foo-packaging}
:::{.example #ex-foo-packaging}
# Package the hello app
```nix
{ foo }:
buildFooPackage {
pname = "hello";
version = "1.0";
}
```
:::
`buildFooPackage` needs `pname` and `version`.
Keep explanation short, and place it after the example.
## Reference {#foo-reference}
### `buildFooPackage` {#foo-buildFooPackage}
Builds a Foo application from source.
#### Inputs {#foo-buildFooPackage-inputs}
`pname` (String)
: The program name.
#### Examples {#foo-buildFooPackage-examples}
See [](#ex-foo-packaging).
````
Examples live in one place: the guide owns them and the reference links to them.
Guides introduce minimal working examples that are goal-oriented (typical usage).
Reference may introduce additional examples that are unit-oriented. (minimal usage, edge-cases).
If the guide example is already sufficient, just link to it from the reference.
Follow this structure strictly; to deviate, ping @NixOS/documentation-team.
### One sentence per line
Put each sentence in its own line.
@@ -348,15 +284,7 @@ Use the [admonition syntax](#admonitions) for callouts and examples.
### `callPackage`-compatible examples
Provide at least one example per function, in its doc-comment.
Keep each example at the level it documents:
- A **reference example** might sometimes live in a doc-comment and show function call shape.
- A **guide example** lives in a guide section and shows a complete task that may compose several functions.
When the task is nothing more than the call itself, the guide example is enough.
The reference example links to the guide example.
Provide at least one example per function.
Example code should be such that it can be passed to `pkgs.callPackage`.
Instead of something like:

View File

@@ -25,5 +25,6 @@ build-helpers/dev-shell-tools.chapter.md
build-helpers/special.md
build-helpers/images.md
hooks/index.md
languages-frameworks/index.md
packages/index.md
```

View File

@@ -2,7 +2,7 @@
The `nix-shell` command has popularized the concept of transient shell environments for development or testing purposes.
<!--
We should try to document the product, not its development process in the Nixpkgs manual,
We should try to document the product, not its development process in the Nixpkgs reference manual,
but *something* needs to be said to provide context for this library.
This is the most future proof sentence I could come up with while Nix itself does not yet make use of this.
Relevant is the current status of the devShell attribute "project": https://github.com/NixOS/nix/issues/7501

View File

@@ -853,7 +853,7 @@ Used with CVS. Expects `cvsRoot`, `tag`, and `hash`.
Used with Mercurial. Expects `url`, `rev`, `hash`, overridable with [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
A number of fetcher functions wrap lower-level fetchers such as `fetchurl`, `fetchzip`, and `fetchgit`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
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`, `fetchFromForgejo` and `fetchFromCodeberg` {#fetchfromgitea}
@@ -876,45 +876,6 @@ However, `fetchFromGitHub` will automatically switch to using `fetchgit` in any
When `fetchgit` is used, refer to the `fetchgit` section for documentation of its available options.
## `fetchFromHuggingFace` {#fetchfromhuggingface}
`fetchFromHuggingFace` fetches repositories from Hugging Face Hub. It expects
`repoId`, exactly one of `rev` or `tag`, and `hash`.
`repoId` must be in the form `repo` or `owner/repo`, so repositories such as
`gpt2` work as well.
::: {.example #ex-fetchfromhuggingface}
# Fetching a model repository from Hugging Face
```nix
fetchFromHuggingFace {
repoId = "hf-internal-testing/tiny-random-gpt2";
rev = "71034c5d8bde858ff824298bdedc65515b97d2b9";
backend = "lfs";
hash = "sha256-8K9B/C62GW5lXC0c8QQpQ9QAE1UMoG+kYqvGhnWIp64=";
}
```
:::
The optional `repoType` argument selects which Hugging Face Hub repository type
to use:
- `"model"` (default) fetches from `https://huggingface.co/<repo-id>`
- `"dataset"` fetches from `https://huggingface.co/datasets/<repo-id>`
- `"space"` fetches from `https://huggingface.co/spaces/<repo-id>`
To use a different Hugging Face Hub instance, use `domain`
(defaults to `"huggingface.co"`).
The optional `backend` argument defaults to `"xet"`. Because the Xet backend is
not implemented yet, callers must currently set `backend = "lfs"`, which uses
`fetchgit` with Git LFS enabled and defaults `fetchSubmodules` to `false`.
`rootDir`, `sparseCheckout`, and low-level `fetchgit` options such as
`deepClone`, `fetchTags`, `leaveDotGit`, and `branchName` are also supported.
## `fetchFromGitLab` {#fetchfromgitlab}
This is used with GitLab repositories. It behaves similarly to `fetchFromGitHub`, and expects `owner`, `repo`, `rev`, and `hash`.
@@ -988,20 +949,6 @@ fetchRadiclePatch {
}
```
## `fetchFromTangled` {#fetchfromtangled}
This is to be used with tangled repositories. `fetchFromTangled` works with
very similar arguments to `fetchFromGithub`. However, instead of a `owner` and
`repo`, a `did` argument is expected.
```nix
fetchFromTangled {
did = "did:plc:jj6ajj6duxnlthwtnob4qyuv"; # tranquil.farm/tranquil-pds
tag = "v6.6.0";
hash = "sha256-cfTsjmK/IMqT5kMKOGpwwWbBlvtrCDOerUJJ8AVI3kY=";
}
```
## `requireFile` {#requirefile}
`requireFile` allows requesting files that cannot be fetched automatically, but whose content is known.

View File

@@ -1,50 +1,48 @@
# Fixed-point arguments of build helpers {#chap-build-helpers-finalAttrs}
`stdenv.mkDerivation` also accepts a [fixed-point function](#function-library-lib.fixedPoints.fix) instead of a plain attribute set:
As mentioned in the beginning of this part, `stdenv.mkDerivation` could alternatively accept a fixed-point function. The input of this function, typically named `finalAttrs`, is expected to be the final state of the attribute set. A build helper like this is said to accept **fixed-point arguments**.
```nix
{
stdenv,
fetchurl,
}:
stdenv.mkDerivation (finalAttrs: {
pname = "hello";
version = "2.12";
Build helpers don't always support fixed-point arguments yet, as support in [`stdenv.mkDerivation`](#mkderivation-recursive-attributes) was first included in Nixpkgs 22.05.
src = fetchurl {
url = "mirror://gnu/hello/hello-${finalAttrs.version}.tar.gz";
hash = "sha256-...";
};
})
```
## Defining a build helper with `lib.extendMkDerivation` {#sec-build-helper-extendMkDerivation}
The function's input, conventionally named `finalAttrs`, is the final state of the attribute set. Here `src` reads `finalAttrs.version` instead of repeating the version string. A build helper like this is said to accept **fixed-point arguments**.
Attributes that reference each other through `finalAttrs` stay correct when changing any of them with [`overrideAttrs`](#sec-pkg-overrideAttrs), because they all access the final values of the fixed-point computation.
`rec` cannot do this: its self-references are fixed when the set is defined and ignore later overrides.
See [recursive-sets](https://nix.dev/manual/nix/stable/language/syntax#recursive-sets) for the underlying mechanism.
## Define a build helper with `lib.extendMkDerivation` {#sec-build-helper-extendMkDerivation}
Use [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper with fixed-point support from an existing one.
Its argument `extendDrvArgs` takes an attribute overlay similar to [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
Developers can use the Nixpkgs library function [`lib.customisation.extendMkDerivation`](#function-library-lib.customisation.extendMkDerivation) to define a build helper supporting fixed-point arguments from an existing one with such support, with an attribute overlay similar to the one taken by [`<pkg>.overrideAttrs`](#sec-pkg-overrideAttrs).
Besides overriding, `lib.extendMkDerivation` also supports `excludeDrvArgNames` to optionally exclude some arguments in the input fixed-point arguments from passing down to the base build helper (specified as `constructDrv`).
:::{.example #ex-build-helpers-extendMkDerivation}
# Example `mkLocalDerivation` - a build helper over `mkDerivation`
# Example definition of `mkLocalDerivation` extended from `stdenv.mkDerivation` with `lib.extendMkDerivation`
Define a build helper named `mkLocalDerivation` that builds locally without using substitutes by default.
We want to define a build helper named `mkLocalDerivation` that builds locally without using substitutes by default.
Use `lib.extendMkDerivation`:
Instead of taking a plain attribute set,
```nix
{
lib,
stdenv,
}:
preferLocalBuild ? true,
allowSubstitute ? false,
specialArg ? (_: false),
...
}@args:
stdenv.mkDerivation (
removeAttrs [
# Don't pass specialArg into mkDerivation.
"specialArg"
] args
// {
# Arguments to pass
inherit preferLocalBuild allowSubstitute;
# Some expressions involving specialArg
greeting = if specialArg "hi" then "hi" else "hello";
}
)
```
we could define with `lib.extendMkDerivation` an attribute overlay to make the result build helper also accept the attribute set's fixed point passing to the underlying `stdenv.mkDerivation`, named `finalAttrs` here:
```nix
lib.extendMkDerivation {
constructDrv = stdenv.mkDerivation;
excludeDrvArgNames = [
@@ -69,78 +67,4 @@ lib.extendMkDerivation {
```
:::
To apply extra changes to the result derivation, pass `transformDrv` to `lib.extendMkDerivation`:
```nix
lib.customisation.extendMkDerivation { transformDrv = drv: /...; }
```
Construct a wrapper derivation around another derivation using `transformDrv`
The wrapper has access to the original arguments
:::{.example #ex-build-helpers-extendMkDerivation-transformDrv-wrapper}
# Define a custom build helper that downloads and builds
```nix
{
lib,
stdenvNoCC,
cacert,
configure-example,
download-example,
}:
lib.extendMkDerivation {
constructDrv = stdenvNoCC.mkDerivation;
excludeDrvArgNames = [
"bar"
];
extendDrvArgs =
finalAttrs:
{
bar,
foo,
hash ? "",
...
}@args:
{
inherit hash;
nativeBuildInputs = args.nativeBuildInputs or [ ] ++ [
cacert
download-example
];
buildPhase = ''
runHook preBuild
download-example --foo="$foo" --out="$out"
runHook postBuild
'';
impureEnvVars = lib.fetchers.proxyImpureEnvVars;
outputHash = if finalAttrs.hash != "" then finalAttrs.hash else lib.fakeHash;
outputHashFormat = "recursive";
passthru = args.passthru or { } // {
inherit bar;
};
};
transformDrv =
unwrapped:
stdenvNoCC.mkDerivation (finalAttrs: {
name = finalAttrs.src.name + "-wrapped";
src = unwrapped;
nativeBuildInputs = [
configure-example
];
inherit (unwrapped) bar;
buildPhase = ''
runHook preBuild
configure-example --bar="$bar"
runHook postBuild
'';
});
}
```
:::
If one needs to apply extra changes to the result derivation, pass the derivation transformation function to `lib.extendMkDerivation` as `lib.customisation.extendMkDerivation { transformDrv = drv: ...; }`.

View File

@@ -28,7 +28,7 @@ However, [those were unified early 2020](https://github.com/NixOS/nixpkgs/pull/8
```nix
{ appimageTools, fetchurl }:
appimageTools.wrapType2 {
let
pname = "nuclear";
version = "0.6.30";
@@ -36,7 +36,8 @@ appimageTools.wrapType2 {
url = "https://github.com/nukeop/nuclear/releases/download/v${version}/nuclear-v${version}.AppImage";
hash = "sha256-he1uGC1M/nFcKpMM9JKY4oeexJcnzV0ZRxhTjtJz6xw=";
};
}
in
appimageTools.wrapType2 { inherit pname version src; }
```
:::
@@ -55,7 +56,7 @@ There are a few ways to learn which dependencies an application needs:
```nix
{ appimageTools, fetchurl }:
appimageTools.wrapType2 {
let
pname = "irccloud";
version = "0.16.0";
@@ -63,7 +64,9 @@ appimageTools.wrapType2 {
url = "https://github.com/irccloud/irccloud-desktop/releases/download/v${version}/IRCCloud-${version}-linux-x86_64.AppImage";
hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
};
in
appimageTools.wrapType2 {
inherit pname version src;
extraPkgs = pkgs: [ pkgs.at-spi2-core ];
}
```
@@ -85,12 +88,12 @@ However, [those were unified early 2020](https://github.com/NixOS/nixpkgs/pull/8
# Extracting an AppImage to install extra files
`wrapType2` automatically extracts the AppImage for you and makes it available via the `contents` attribute.
Note how `finalAttrs.contents` is used in `extraInstallCommands` to install additional files that were extracted from the AppImage.
This example was adapted from a real package in Nixpkgs to show how `extract` is usually used in combination with `wrapType2`.
Note how `appimageContents` is used in `extraInstallCommands` to install additional files that were extracted from the AppImage.
```nix
{ appimageTools, fetchurl }:
appimageTools.wrapType2 (finalAttrs: {
let
pname = "irccloud";
version = "0.16.0";
@@ -99,24 +102,27 @@ appimageTools.wrapType2 (finalAttrs: {
hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
};
appimageContents = appimageTools.extract { inherit pname version src; };
in
appimageTools.wrapType2 {
inherit pname version src;
extraPkgs = pkgs: [ pkgs.at-spi2-core ];
extraInstallCommands = ''
mv $out/bin/irccloud-${version} $out/bin/irccloud
install -m 444 -D ${finalAttrs.contents}/irccloud.desktop $out/share/applications/irccloud.desktop
install -m 444 -D ${finalAttrs.contents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
install -m 444 -D ${appimageContents}/irccloud.desktop $out/share/applications/irccloud.desktop
install -m 444 -D ${appimageContents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
$out/share/icons/hicolor/512x512/apps/irccloud.png
substituteInPlace $out/share/applications/irccloud.desktop \
--replace-fail 'Exec=AppRun' 'Exec=irccloud'
'';
})
}
```
:::
`appimageTools` also exposes the `extract` function should you need to do it manually, requiring `pname`, `version`, and `src` arguments (`src` being the AppImage file to extract).
The arguments passed to `extract` can also contain a `postExtract` attribute, which allows you to execute additional commands after the files are extracted from the AppImage.
The argument passed to `extract` can also contain a `postExtract` attribute, which allows you to execute additional commands after the files are extracted from the AppImage.
`postExtract` must be a string with commands to run.
:::{.warning}
@@ -132,7 +138,7 @@ This is a rewrite of [](#ex-extracting-appimage) to use `postExtract` and `wrapA
```nix
{ appimageTools, fetchurl }:
appimageTools.wrapAppImage (finalAttrs: {
let
pname = "irccloud";
version = "0.16.0";
@@ -141,22 +147,30 @@ appimageTools.wrapAppImage (finalAttrs: {
hash = "sha256-/hMPvYdnVB1XjKgU2v47HnVvW4+uC3rhRjbucqin4iI=";
};
contents = appimageTools.extract {
inherit (finalAttrs) pname version src;
appimageContents = appimageTools.extract {
inherit pname version src;
postExtract = ''
substituteInPlace $out/irccloud.desktop --replace-fail 'Exec=AppRun' 'Exec=irccloud'
'';
};
in
appimageTools.wrapAppImage {
inherit pname version;
src = appimageContents;
extraPkgs = pkgs: [ pkgs.at-spi2-core ];
extraInstallCommands = ''
mv $out/bin/irccloud-${version} $out/bin/irccloud
install -m 444 -D ${finalAttrs.contents}/irccloud.desktop $out/share/applications/irccloud.desktop
install -m 444 -D ${finalAttrs.contents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
install -m 444 -D ${appimageContents}/irccloud.desktop $out/share/applications/irccloud.desktop
install -m 444 -D ${appimageContents}/usr/share/icons/hicolor/512x512/apps/irccloud.png \
$out/share/icons/hicolor/512x512/apps/irccloud.png
'';
})
# specify src archive for nix-update
passthru.src = src;
}
```
:::

View File

@@ -68,7 +68,7 @@ See [](#ex-portableService-hello) to understand how to use the output of `portab
: Allows you to override the package that provides {manpage}`mksquashfs(1)`, which is used internally by `portableService`.
_Default value:_ `pkgs.squashfs-tools`.
_Default value:_ `pkgs.squashfsTools`.
`squash-compression` (String; _optional_)

View File

@@ -737,112 +737,4 @@ Notable attributes:
* `driverInteractive`: a script that launches an interactive Python session in the context of the `testScript`.
## `modularServiceCompliance` {#tester-modularServiceCompliance}
Compliance suite for [modular service](https://nixos.org/manual/nixos/unstable/#modular-services) integrations.
Tests that a service manager integration correctly handles the portable modular services contract: `process.argv`, sub-services, assertions, and warnings.
### Return value {#tester-modularServiceCompliance-return}
An attribute set of derivations which perform the tests during their build.
### Inputs {#tester-modularServiceCompliance-inputs}
`evalConfig` (function)
: `{ services } -> { config; checkDrv; }`.
Function to evaluate the given services in the integration's full context.
This function is called for evaluation checks on configurations that will not be run.
- Input `services` is an attrset of modular service configurations. These should be used verbatim.
- Output attribute `config` is the resulting evaluated services attrset (e.g., the value of the `system.services` option in NixOS).
This attribute must be available even if `checkDrv` would fail.
- Output attribute `checkDrv` is a representative derivation whose existence and buildability prove the eval is sound (e.g., `system.build.toplevel` in NixOS, but could perhaps be more specific in the case of another process manager integration).
- The generic tester only reads `config` and `checkDrv`. An integration may return additional attributes for its own integration-specific eval checks. Such extra attributes are optional.
`mkTest` (function)
: `{ name, services, testExe } -> derivation`.
- Input `name` is a test name, suitable for use as a derivation name.
- Input `services` is an attrset of modular service configurations, matching the structure of the integration's services option.
- Input `testExe` is a store path to an executable that verifies the services.
- Output: a derivation that runs the service manager with the provided configuration inputs and then calls `testExe` after starting the services. That executable must have access to `sharedDir`.
`sharedDir` (string)
: Path to a directory writable by service processes and readable by `testExe`.
The integration must ensure this directory is available when the services and `testExe` run.
`callReload` (function)
: `path -> string`.
Given a service's name `path` (the list of service names from the top-level service down to the target sub-service, e.g. `[ "reload" "inner" ]`), returns a shell command that reloads that service.
The command is embedded in `testExe` and executed with sufficient privilege to reload the service (e.g. as root in the test VM).
There is no manager-agnostic reload command, so every integration must provide this; the integration joins the `path` per its own unit-naming convention (the suite does not assume one).
On NixOS the `path` dash-joins into the systemd unit name with a `.service` suffix, so the command is `systemctl reload ${lib.concatStringsSep "-" path}.service` (a top-level service is a single-element path `[ "svc" ]` -> `svc.service`; a nested sub-service `[ "parent" "child" ]` -> `parent-child.service`).
:::{.example #ex-modularServiceCompliance-nixos}
# NixOS invocation of the compliance suite
```nix
# In nixos/tests/all-tests.nix:
# modularServiceCompliance =
recurseIntoAttrs (
pkgs.testers.modularServiceCompliance {
sharedDir = "/tmp/modular-service-compliance";
evalConfig =
{ services }:
let
machine = evalSystem (
{ ... }:
{
system.services = services;
system.stateVersion = "25.05";
fileSystems."/" = {
device = "/test/dummy";
fsType = "auto";
};
boot.loader.grub.enable = false;
}
);
in
{
config = machine.config.system.services;
checkDrv = machine.config.system.build.toplevel;
};
callReload = path: "systemctl reload ${lib.concatStringsSep "-" path}.service";
mkTest =
{
name,
services,
testExe,
}:
runTest {
_class = "nixosTest";
inherit name;
nodes.machine.system.services = services;
testScript = ''
machine.wait_for_unit("multi-user.target")
machine.succeed("${testExe}")
'';
};
}
)
```
:::
### Manual compliance items {#tester-modularServiceCompliance-manual}
The following compliance items are not yet automated and must be verified manually when implementing a new modular service integration.
- **Failing assertions prevent deployment.**
A service with `assertions = [{ assertion = false; message = "..."; }]` must cause the deployment to fail.
The mechanism is integration-specific (e.g., NixOS checks assertions during `system.build.toplevel` evaluation).
- **Warnings are visible to the user.**
A service with `warnings = [ "..." ]` must surface the warning to the user.
On NixOS these are `builtins.warn` messages emitted during evaluation.
[file system object]: https://nix.dev/manual/nix/latest/store/file-system-object

View File

@@ -165,7 +165,7 @@ They are useful for creating files from Nix expressions, and are all implemented
Each of these functions will cause a derivation to be produced.
When you coerce the result of each of these functions to a string with [string interpolation](https://nixos.org/manual/nix/stable/language/string-interpolation) or [`toString`](https://nixos.org/manual/nix/stable/language/builtins#builtins-toString), it will evaluate to the [store path](https://nixos.org/manual/nix/stable/store/store-path) of this derivation.
::: {.note}
:::: {.note}
Some of these functions will put the resulting files within a directory inside the [derivation output](https://nixos.org/manual/nix/stable/language/derivations#attr-outputs).
If you need to refer to the resulting files somewhere else in a Nix expression, append their path to the derivation's store path.
@@ -190,7 +190,7 @@ writeShellScript "evaluate-my-file.sh" ''
cat ${my-file}/share/my-file
''
```
:::
::::
### `makeDesktopItem` {#trivial-builder-makeDesktopItem}

View File

@@ -1,26 +0,0 @@
# How channels work {#how-channels-work}
nixpkgs uses the [channels feature](https://nixos.org/nix/manual/#sec-channels) of nix.
nixpkgs is distributed for users of Nix on non-NixOS distributions through the channel
`nixpkgs-unstable`. Users of NixOS generally use one of the `nixos-*` channels,
e.g. `nixos-22.11`, which includes all packages and modules for the stable NixOS
22.11. Stable NixOS releases are generally only given
security updates. More up to date packages and modules are available via the
`nixos-unstable` channel.
Both `nixos-unstable` and `nixpkgs-unstable` follow the `master` branch of the
nixpkgs repository, although both do lag the `master` branch by generally
[a couple of days](https://status.nixos.org/). Updates to a channel are
distributed as soon as all tests for that channel pass, e.g.
[this table](https://hydra.nixos.org/job/nixpkgs/trunk/unstable#tabs-constituents)
shows the status of tests for the `nixpkgs-unstable` channel.
The tests are conducted by a cluster called [Hydra](https://nixos.org/hydra/),
which also builds binary packages from the Nix expressions in Nixpkgs for
`x86_64-linux`, `aarch64-linux`, `x86_64-darwin` and `aarch64-darwin`.
The binaries are made available via a [binary cache](https://cache.nixos.org).
The current Nix expressions of the channels are available in the
[nixpkgs repository](https://github.com/NixOS/nixpkgs) in branches
that correspond to the channel names (e.g. `nixos-22.11-small`).

View File

@@ -1,5 +1,5 @@
{
pkgs ? (import ../ci { }).docPkgs,
pkgs ? (import ../ci { }).pkgs,
nixpkgs ? { },
}:

View File

@@ -1,7 +0,0 @@
<div class="manual-header">
<nav class="manual-header--tabs">
<a class="manual-header--tab manual-header--tab-active" href="#">Nixpkgs</a>
<a class="manual-header--tab" href="https://nixos.org/manual/nixos/stable/">NixOS</a>
</nav>
<span class="manual-header--title">Nixpkgs Manual</span>
</div>

View File

@@ -73,7 +73,6 @@ stdenvNoCC.mkDerivation (
../anchor.min.js
../manpage-urls.json
../redirects.json
../nav.json
]
);
};
@@ -117,10 +116,8 @@ stdenvNoCC.mkDerivation (
--script ./highlightjs/loader.js \
--script ./anchor.min.js \
--script ./anchor-use.js \
--sidebar-depth 3 \
--experimental-config ./nav.json \
--header ${./header.html}\
--no-navheader \
--toc-depth 1 \
--section-toc-depth 1 \
manual.md \
out/index.html

View File

@@ -1,49 +0,0 @@
# Dev environments {#dev-environments}
Create a `shell.nix` with the following:
```nix
# shell.nix
let
nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz";
pkgs = import nixpkgs { };
in
pkgs.mkShell {
packages = [ pkgs.python3 ];
shellHook = ''
echo "Welcome in my nix shell"
'';
}
```
run
```sh
nix-shell
```
This activates your `shell.nix` and you should see:
```sh
unpacking 'https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz' into the Git cache...
Welcome in your nix shell
```
python3 is available
```sh
$ python3 --version
```
To leave the shell
```bash
ctrl+D
```
:::{.note}
You should use [pinned nixpkgs](https://nix.dev/guides/recipes/dependency-management.html).
The example used `unstable` here for demonstration purposes only
:::
For further information check out [nix-shell](https://nix.dev/manual/nix/stable/command-ref/nix-shell)

View File

@@ -1,84 +0,0 @@
# Package your first application {#chap-first-package}
Package an application with Nixpkgs by picking the build helper for its language and setting a few attributes.
Each language ecosystem has its own build helper.
See [](#chap-language-support) for the full set.
## Package a Go application {#first-package-go}
`buildGoModule` builds Go programs that use Go modules.
Write the package to `package.nix`:
:::{.example #ex-first-package-go}
# Package `pet` with `buildGoModule`
```nix
# package.nix
{
buildGoModule,
fetchFromGitHub,
lib,
}:
buildGoModule (finalAttrs: {
pname = "pet";
version = "0.3.4";
src = fetchFromGitHub {
owner = "knqyf263";
repo = "pet";
tag = "v${finalAttrs.version}";
hash = "sha256-Gjw1dRrgM8D3G7v6WIM2+50r4HmTXvx0Xxme2fH9TlQ=";
};
vendorHash = "sha256-6hCgv2/8UIRHw1kCe3nLkxF23zE/7t5RDwEjSzX3pBQ=";
meta = {
description = "Simple command-line snippet manager, written in Go";
homepage = "https://github.com/knqyf263/pet";
license = lib.licenses.mit;
maintainers = with lib.maintainers; [ kalbasit ];
};
})
```
:::
`buildGoModule` needs `pname`, `version`, `src`, and `vendorHash`.
Pin Nixpkgs and call the package from `default.nix`:
```nix
# default.nix
let
nixpkgs = fetchTarball "https://github.com/NixOS/nixpkgs/archive/nixos-unstable.tar.gz";
pkgs = import nixpkgs { };
in
pkgs.callPackage ./package.nix { }
```
Build it:
```shell
$ nix-build ./default.nix
# or equivalent
$ nix-build
```
Run it:
```shell
$ ./result/bin/pet --help
pet - Simple command-line snippet manager.
```
`vendorHash` pins the fetched dependencies.
To find its value:
1. Set `vendorHash` to an empty string `""`.
2. Run `nix-build`.
3. Copy the correct value from the error into `vendorHash`.
See the [Go reference](#sec-language-go) for every attribute and advanced usage.

View File

@@ -1,6 +0,0 @@
# Getting started {#getting-started}
```{=include=} chapters
first-package.chapter.md
dev-environments.md
```

View File

@@ -1,24 +0,0 @@
# checkPhaseThreadLimitHook {#setup-hook-check-phase-thread-limit}
This hook defaults a variety of environment variables known
to control thread counts to 1. Many of these otherwise default
to `$(nproc)`, which causes massive overloads on build machines
if nix build jobs and build cores are already tuned to fully utilize
compute capacity of a builder without additional parallelism.
Currently sets the following environment variables:
- [`OMP_NUM_THREADS`](https://www.openmp.org/spec-html/5.0/openmpse50.html)
- [`OPENBLAS_NUM_THREADS`](https://github.com/OpenMathLib/OpenBLAS/blob/e7b45174355edec1f04de1cabcf5ca6a98ea7fbc/USAGE.md#how-can-i-use-openblas-in-multi-threaded-applications)
- [`MKL_NUM_THREADS`](https://www.intel.com/content/www/us/en/docs/onemkl/developer-guide-linux/2023-0/mkl-domain-num-threads.html)
- [`BLIS_NUM_THREADS`](https://github.com/flame/blis/blob/b8b75b4e19459f5d618b57aa814ca38b1d82eb82/docs/Multithreading.md#specifying-multithreading)
- `VECLIB_MAXIMUM_THREADS`: Only affects darwin, see [`man 7 Accelerate`](https://manp.gs/mac/7/Accelerate)
- [`NUMBA_NUM_THREADS`](https://numba.readthedocs.io/en/stable/reference/envvars.html#threading-control)
- [`NUMEXPR_NUM_THREADS`](https://numexpr.readthedocs.io/en/latest/user_guide.html#threadpool-configuration)
The `NIX_CHECK_PHASE_DEFAULT_NUM_THREADS` environment variable
can be used to override the default thread count limit.
`dontLimitCheckPhaseThreads = true;` can be used to disable
thread limiting on an individual package.
This hook will not attempt to override already existing
definitions for thread count environment variables.

3
doc/hooks/ghc.section.md Normal file
View File

@@ -0,0 +1,3 @@
# GHC {#ghc}
Creates a temporary package database and registers every Haskell build input in it (TODO: how?).

View File

@@ -13,10 +13,10 @@ aws-c-common.section.md
bmake.section.md
breakpoint.section.md
cernlib.section.md
check-phase-thread-limit-hook.section.md
cmake.section.md
desktop-file-utils.section.md
gdk-pixbuf.section.md
ghc.section.md
gnome.section.md
haredo.section.md
installShellFiles.section.md

View File

@@ -7,7 +7,7 @@ The `pnpmBuildHook` in Nixpkgs overrides the default build phase for building pa
:::{.example #ex-pnpm-build-hook}
## pnpmBuildHook example code snippet {#pnpm-build-hook-code-snippet}
```nix
```
{
lib,
stdenv,
@@ -38,7 +38,7 @@ stdenv.mkDerivation (finalAttrs: {
pnpmDeps = fetchPnpmDeps {
inherit (finalAttrs) pname version src;
inherit pnpm;
fetcherVersion = 4;
fetcherversion = 4;
hash = lib.fakeHash;
};
@@ -94,7 +94,7 @@ Controls the flags pass only to the pnpm build script invocation.
Disables automatically running `pnpmBuildHook`. The build can still be run manually if needed, for example:
```nix
```
{
lib,
rustPlatform,
@@ -123,9 +123,9 @@ rustPlatform.buildRustPackage (finalAttrs: {
pnpmDeps = fetchPnpmDeps {
inherit (finalAttrs) pname version src;
inherit pnpm;
fetcherVersion = 4;
fetcherversion = 3;
hash = lib.fakeHash;
};
}
dontPnpmBuild = true;
postBuild = ''

View File

@@ -39,7 +39,7 @@ The `nix:narinfo` properties should be accompanied by a `nix:store_path` propert
| `nix:narinfo:system` | The hardware and software platform on which this component is produced. |
| `nix:narinfo:sig` | Signatures claiming that this component is what it claims to be. |
| `nix:narinfo:ca` | Content address of this store object's file system object, used to compute its store path. |
| `nix:narinfo:references` | A whitespace-separated array of store paths that this component references. |
| `nix:narinfo:references` | A whitespace separated array of store paths that this component references. |
### `nix:fod` {#sec-interop.cylonedx-fod}

View File

@@ -116,7 +116,7 @@ options:
For each requested system image we can specify the following options:
* `systemImageTypes` specifies what kind of system images should be included.
Defaults to: `google_apis`, `google_apis_playstore`, `google_apis_ps16k` and `google_apis_playstore_ps16k`.
Defaults to: `default`.
* `abiVersions` specifies what kind of ABI version of each system image should
be included. Defaults to `armeabi-v7a` and `arm64-v8a`.

View File

@@ -34,21 +34,17 @@ Inside each package set are:
- builders: mixRelease, buildRebar3, etc
- hooks: for composing builders and packages
The package set is the only place Erlang and Elixir versions are chosen. Builders such as `mixRelease`, `fetchMixDeps` and `buildMix` take them from the set they are called from, and do not accept `erlang`, `elixir` or `hex` arguments.
To use a non-default Elixir, derive a new set with `overrideScope`. This keeps the rest of the set consistent, so every builder picks up the overridden Elixir:
To use a non-default Elixir it's important to keep the rest of the package set consistent, so it's recommended to use `.extend`. This ensures that builders like `mixRelease`, `fetchMixDeps`, and `buildMix` all pick up the overridden Elixir:
```nix
let
beamPackages = beam27Packages.overrideScope (final: prev: { elixir = final.elixir_1_18; });
beamPackages = beam27Packages.extend (self: super: { elixir = self.elixir_1_18; });
in
beamPackages.mixRelease {
# ...
}
```
`erlang` can be replaced the same way, which is useful for a patched OTP. Every member of the set is built from the set's own `erlang`, so overriding it rebuilds Elixir, Rebar3 and the rest against it.
## Build Tools {#beam-build-tools}
### Rebar3 {#beam-build-tools-rebar3}
@@ -129,7 +125,7 @@ There are 2 ways to package backend dependencies: either per-dependency mix2nix
When writing an elixir project targeting `mixRelease`, you can also consider using [deps_nix](https://github.com/code-supply/deps_nix) with `mixNixDeps`. `deps_nix` supports git dependencies, but is intended to be added to the project's `mix.exs` directly.
##### mix2nix {#mix2nix}
###### mix2nix {#mix2nix}
`mix2nix` is a cli tool available in Nixpkgs. It will generate a Nix expression from a `mix.lock` file. It is quite standard in the 2nix tool series.
@@ -179,7 +175,7 @@ If there are git dependencies.
You will need to run the build process once to fix the hash to correspond to your new git src.
##### FOD {#fixed-output-derivation}
###### FOD {#fixed-output-derivation}
A fixed output derivation will download mix dependencies from the internet. To ensure reproducibility, a hash will be supplied. Note that mix is relatively reproducible. An FOD generating a different hash on each run hasn't been observed (as opposed to npm where the chances are relatively high). See [akkoma](https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/ak/akkoma/package.nix) for a usage example of FOD.
@@ -210,7 +206,7 @@ Here is how your `default.nix` file would look for a Phoenix project.
# beam27Packages or beam29Packages is available if you need a particular version
beamPackages,
}:
beamPackages.mixRelease (finalAttrs: {
let
pname = "your_project";
version = "0.0.1";
@@ -219,6 +215,24 @@ beamPackages.mixRelease (finalAttrs: {
rev = "replace_with_your_commit";
};
# if using mix2nix you can use the mixNixDeps attribute
mixFodDeps = beamPackages.fetchMixDeps {
pname = "mix-deps-${pname}";
inherit src version;
# nix will complain and tell you the right value to replace this with
hash = lib.fakeHash;
mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".
# if you have build time environment variables add them here
MY_ENV_VAR = "my_value";
};
in
beamPackages.mixRelease {
inherit
src
pname
version
mixFodDeps
;
# if you have build time environment variables add them here
MY_ENV_VAR = "my_value";
@@ -228,18 +242,7 @@ beamPackages.mixRelease (finalAttrs: {
mix do deps.loadpaths --no-deps-check, phx.digest
mix phx.digest --no-deps-check
'';
# if using mix2nix you can use the mixNixDeps attribute
mixFodDeps = beamPackages.fetchMixDeps {
pname = "mix-deps-${finalAttrs.pname}";
inherit (finalAttrs) src version;
# nix will complain and tell you the right value to replace this with
hash = lib.fakeHash;
mixEnv = ""; # default is "prod", when empty includes all dependencies, such as "dev", "test".
# if you have build time environment variables add them here
MY_ENV_VAR = "my_value";
};
})
}
```
Setup will require the following steps:
@@ -252,7 +255,7 @@ Setup will require the following steps:
#### Example of creating a service for an Elixir - Phoenix project {#example-of-creating-a-service-for-an-elixir---phoenix-project}
To create a service with your release, you could add a `service.nix`
In order to create a service with your release, you could add a `service.nix`
in your project with the following
```nix
@@ -336,8 +339,8 @@ Usually, we need to create a `shell.nix` file and do our development inside the
with pkgs;
let
# pin OTP via beam27Packages/beam28Packages/... and Elixir via overrideScope
beamPackages = beam27Packages.overrideScope (final: prev: { elixir = final.elixir_1_18; });
# pin OTP via beam27Packages/beam28Packages/... and Elixir via .extend
beamPackages = beam27Packages.extend (self: super: { elixir = self.elixir_1_18; });
in
mkShell { buildInputs = [ beamPackages.elixir ]; }
```
@@ -372,8 +375,8 @@ Here is an example `shell.nix`.
with import <nixpkgs> { };
let
# pin OTP via beam27Packages/beam28Packages/... and Elixir via overrideScope
beamPackages = beam27Packages.overrideScope (final: prev: { elixir = final.elixir_1_18; });
# pin OTP via beam27Packages/beam28Packages/... and Elixir via .extend
beamPackages = beam27Packages.extend (self: super: { elixir = self.elixir_1_18; });
# define packages to install
basePackages = [

View File

@@ -105,7 +105,7 @@ Given the requirements above, the package expression would become messy quickly:
}
```
Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables. If a package has multiple outputs, these hooks will work on `outputBin` by default, or on the outputs listed in `wrapGAppsInOutputs` if set.
Fortunately, we have a [family of hooks]{#ssec-gnome-hooks-wrapgappshook} that automate this. They work in conjunction with other setup hooks that populate environment variables, and will then wrap all executables in `bin` and `libexec` directories using said variables.
- [`wrapGAppsHook3`]{#ssec-gnome-hooks-wrapgappshook3} for GTK 3 apps. For convenience, it also adds `dconf.lib` for a GIO module implementing a GSettings backend using `dconf`, `gtk3` for GSettings schemas, and `librsvg` for GdkPixbuf loader to the closure.
- [`wrapGAppsHook4`]{#ssec-gnome-hooks-wrapgappshook4} for GTK 4 apps. Same as `wrapGAppsHook3` but replaces `gtk3` with `gtk4`.

View File

@@ -679,7 +679,7 @@ Defaults to `false`.
`genericBuilderArgsModifier`
: This argument accepts a function allowing you to modify the arguments passed
to `mkDerivation` to create the development environment. For example,
to `mkDerivation` in order to create the development environment. For example,
`args: { doCheck = false; }` would cause the environment to not include any test
dependencies. Defaults to `lib.id`.

View File

@@ -2,10 +2,6 @@
The [standard build environment](#chap-stdenv) makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accommodated by overriding the appropriate phases of `stdenv`. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
::: {.tip}
New to packaging? Start with [](#chap-first-package), then return here for the ecosystem you need.
:::
Each supported language or software ecosystem has its own package set named `<language or ecosystem>Packages`, which can be explored in various ways:
- Search on [search.nixos.org](https://search.nixos.org/packages)
@@ -60,6 +56,7 @@ android.section.md
astal.section.md
beam.section.md
chicken.section.md
rocq.section.md
cosmic.section.md
crystal.section.md
cuda.section.md
@@ -95,7 +92,6 @@ pkg-config.section.md
python.section.md
qt.section.md
r.section.md
rocq.section.md
ruby.section.md
rust.section.md
scheme.section.md

View File

@@ -1,30 +1,49 @@
# JavaScript {#language-javascript}
# Javascript {#language-javascript}
## Introduction {#javascript-introduction}
Package JavaScript applications with the tools below.
This contains instructions on how to package JavaScript applications.
The various tools available will be listed in the [tools-overview](#javascript-tools-overview).
Some general principles for packaging will follow.
Finally, some tool-specific instructions will be given.
## Getting unstuck / finding code examples {#javascript-finding-examples}
If you find you are lacking inspiration for packaging JavaScript applications, the links below might prove useful.
Searching online for prior art can be helpful if you are running into solved problems.
### Github {#javascript-finding-examples-github}
- Searching Nix files for `yarnConfigHook`: <https://github.com/search?q=yarnConfigHook+language%3ANix&type=code>
- Searching just `flake.nix` files for `yarnConfigHook`: <https://github.com/search?q=yarnConfigHook+path%3A**%2Fflake.nix&type=code>
### Gitlab {#javascript-finding-examples-gitlab}
- Searching Nix files for `yarnConfigHook`: <https://gitlab.com/search?scope=blobs&search=yarnConfigHook+extension%3Anix>
- Searching just `flake.nix` files for `yarnConfigHook`: <https://gitlab.com/search?scope=blobs&search=yarnConfigHook+filename%3Aflake.nix>
## Tools overview {#javascript-tools-overview}
## General principles {#javascript-general-principles}
The principles below are ordered by importance.
The following principles are given in order of importance with potential exceptions.
### Use the project's Node.js version {#javascript-upstream-node-version}
### Try to use the same node version used upstream {#javascript-upstream-node-version}
It is often not documented which Node.js version the project uses, but if it is, use the same version when packaging.
It is often not documented which node version is used upstream, but if it is, try to use the same version when packaging.
This can be a problem if the project uses the latest and greatest and you are trying to use an earlier version of Node.js.
This can be a problem if upstream is using the latest and greatest and you are trying to use an earlier version of node.
Some cryptic errors regarding V8 may appear.
### Use the project's package manager and lock file {#javascript-upstream-package-manager}
### Try to respect the package manager originally used by upstream (and use the upstream lock file) {#javascript-upstream-package-manager}
A lock file (package-lock.json, yarn.lock...) is supposed to make reproducible installations of `node_modules` for each tool.
Package manager guidelines recommend committing those lock files to the repository.
If a particular lock file is present, it is a strong indication of which package manager the project uses.
Guidelines of package managers, recommend to commit those lock files to the repos.
If a particular lock file is present, it is a strong indication of which package manager is used upstream.
Use a Nix tool that understands the lock file.
It's better to try to use a Nix tool that understands the lock file.
Using a different tool might give you a hard-to-understand error because different packages have been installed.
Using a different tool forces you to commit a lock file to the repository.
@@ -32,16 +51,16 @@ These files are fairly large, so when packaging for nixpkgs, this approach does
Exceptions to this rule are:
- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems are detailed. If a tool has a problem, try another. You may have to re-create a lock file and commit it to Nixpkgs.
- Some lock files contain a particular version of a package that has been pulled off npm for some reason. In that case, you can recreate the lock file (by removing the original and running `npm install`, `yarn`, etc.) and commit this to Nixpkgs.
- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to re-create a lock file and commit it to Nixpkgs.
- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.
### Use the project's `package.json` {#javascript-upstream-package-json}
### Try to use upstream package.json {#javascript-upstream-package-json}
Exceptions to this rule are:
- Sometimes the project assumes some dependencies are installed globally. Add them to the `package.json` manually (`yarn add xxx` or `npm install xxx`). Run locally installed CLI tools with `npx`, for example `npx postcss`. That is how you call them in the phases.
- Sometimes the upstream repo assumes some dependencies should be installed globally. In that case, you can add them manually to the upstream `package.json` (`yarn add xxx` or `npm install xxx`, ...). Dependencies that are installed locally can be executed with `npx` for CLI tools (e.g. `npx postcss ...`, this is how you can call those dependencies in the phases).
- Sometimes there is a version conflict between some dependency requirements. In that case you can fix a version by removing the `^`.
- Sometimes a script in `package.json` does not work as is. It might call a CLI tool that is not available, or `cd` into a directory with a different `package.json`, which is common with workspaces. Read what the script does. Reproduce it in the build phases. For example, a `build` script may call `build:ui` and `build:server` in turn. If one fails, split them into separate steps.
- Sometimes the script defined in the package.json does not work as is. Some scripts for example use CLI tools that might not be available, or cd in directory with a different package.json (for workspaces notably). In that case, it's perfectly fine to look at what the particular script is doing and break this down in the phases. In the build script you can see `build:*` calling in turns several other build scripts like `build:ui` or `build:server`. If one of those fails, you can try to separate those into,
```sh
yarn build:ui
@@ -51,7 +70,7 @@ Exceptions to this rule are:
npm run build:server
```
When you need to override `package.json`, it is best to use the one from the project and make explicit overrides. Here is an example:
when you need to override a package.json. It's nice to use the one from the upstream source and do some explicit override. Here is an example:
```nix
{
@@ -63,22 +82,22 @@ Exceptions to this rule are:
}
```
You still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
You will still need to commit the modified version of the lock files, but at least the overrides are explicit for everyone to see.
### Use `node_modules` directly {#javascript-using-node_modules}
### Using node_modules directly {#javascript-using-node_modules}
Each tool has an abstraction to build the node_modules (dependencies) directory.
Each tool has an abstraction to just build the node_modules (dependencies) directory.
You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command).
The `node_modules` abstraction can also be used to build some web framework frontends.
For an example of this, see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/pl/plausible/package.nix) is built.
Then, when building the frontend, you can symlink the `node_modules` directory.
The node_modules abstraction can be also used to build some web framework frontends.
For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/pl/plausible/package.nix) is built.
Then when building the frontend you can just symlink the node_modules directory.
## Tool-specific instructions {#javascript-tool-specific}
### buildNpmPackage {#javascript-buildNpmPackage}
`buildNpmPackage` packages npm-based projects in Nixpkgs without the use of an auto-generated dependencies file.
It uses npm's cache. It builds a reproducible cache of the project's dependencies and points npm at it.
`buildNpmPackage` allows you to package npm-based projects in Nixpkgs without the use of an auto-generated dependencies file.
It works by utilizing npm's cache functionality -- creating a reproducible cache that contains the dependencies of a project, and pointing npm to it.
Here's an example:
@@ -116,9 +135,9 @@ buildNpmPackage (finalAttrs: {
})
```
In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install. They go in `$out/lib/node_modules/$name/`, where `$name` is the `name` string in the package's `package.json`.
In the default `installPhase` set by `buildNpmPackage`, it uses `npm pack --json --dry-run` to decide what files to install in `$out/lib/node_modules/$name/`, where `$name` is the `name` string defined in the package's `package.json`.
Additionally, the `bin` and `man` keys in the source's `package.json` are used to decide what binaries and manpages are supposed to be installed.
If these are not defined, `npm pack` may miss some files, and no binaries are produced.
If these are not defined, `npm pack` may miss some files, and no binaries will be produced.
#### Arguments {#javascript-buildNpmPackage-arguments}
@@ -153,8 +172,8 @@ sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
`fetchNpmDeps` is a Nix function that requires the following mandatory arguments:
- `src`: A directory or tarball with a `package-lock.json` file
- `hash`: The output hash of the dependencies defined in `package-lock.json`.
- `src`: A directory / tarball with `package-lock.json` file
- `hash`: The output hash of the node dependencies defined in `package-lock.json`.
It returns a derivation with all `package-lock.json` dependencies downloaded into `$out/`, usable as an npm cache.
@@ -168,7 +187,7 @@ There is no need to specify a `hash`, since it relies entirely on the integrity
##### Inputs {#javascript-buildNpmPackage-inputs}
- `npmRoot`: Path to the package directory containing the source tree.
- `npmRoot`: Path to package directory containing the source tree.
If this is omitted, the `package` and `packageLock` arguments must be specified instead.
- `package`: Parsed contents of `package.json`
- `packageLock`: Parsed contents of `package-lock.json`
@@ -176,7 +195,7 @@ There is no need to specify a `hash`, since it relies entirely on the integrity
- `version`: Package version
- `fetcherOpts`: An attribute set of arguments forwarded to the underlying fetcher.
It returns a derivation with a patched `package.json` and `package-lock.json` with all dependencies resolved to Nix store paths.
It returns a derivation with a patched `package.json` & `package-lock.json` with all dependencies resolved to Nix store paths.
:::{.note}
`npmHooks.npmConfigHook` cannot be used with `importNpmLock`.
@@ -238,18 +257,18 @@ buildNpmPackage {
`importNpmLock.buildNodeModules` returns a derivation with a pre-built `node_modules` directory, as imported by `importNpmLock`.
This is to be used together with `importNpmLock.hooks.linkNodeModulesHook` to support `nix-shell`/`nix develop` development workflows.
This is to be used together with `importNpmLock.hooks.linkNodeModulesHook` to facilitate `nix-shell`/`nix develop` based development workflows.
It accepts an argument with the following attributes:
`npmRoot` (Path; optional)
: Path to the package directory containing the source tree. If not specified, the `package` and `packageLock` arguments must both be specified.
: Path to package directory containing the source tree. If not specified, the `package` and `packageLock` arguments must both be specified.
`package` (Attrset; optional)
: Parsed contents of `package.json`, as returned by `lib.importJSON ./my-package.json`. If not specified, the `package.json` in `npmRoot` is used.
`packageLock` (Attrset; optional)
: Parsed contents of `package-lock.json`, as returned by `lib.importJSON ./my-package-lock.json`. If not specified, the `package-lock.json` in `npmRoot` is used.
: Parsed contents of `package-lock.json`, as returned `lib.importJSON ./my-package-lock.json`. If not specified, the `package-lock.json` in `npmRoot` is used.
`derivationArgs` (`mkDerivation` attrset; optional)
: Arguments passed to `stdenv.mkDerivation`
@@ -269,26 +288,26 @@ pkgs.mkShell {
};
}
```
creates a development shell where a `node_modules` directory is created and packages are symlinked to the Nix store when activated.
will create a development shell where a `node_modules` directory is created & packages symlinked to the Nix store when activated.
:::{.note}
Commands like `npm install` and `npm add` that write packages and executables need to be used with `--package-lock-only`.
Commands like `npm install` & `npm add` that write packages & executables need to be used with `--package-lock-only`.
This means `npm` installs dependencies by writing into `package-lock.json` without modifying the `node_modules` folder. It installs by reloading the devShell.
This gives the `nix shell` near-exclusive ownership over your `node_modules` folder.
This means `npm` installs dependencies by writing into `package-lock.json` without modifying the `node_modules` folder. Installation happens through reloading the devShell.
This might be best practice since it gives the `nix shell` virtually exclusive ownership over your `node_modules` folder.
Set `package-lock-only = true` in your project-local [`.npmrc`](https://docs.npmjs.com/cli/v11/configuring-npm/npmrc).
It's recommended to set `package-lock-only = true` in your project-local [`.npmrc`](https://docs.npmjs.com/cli/v11/configuring-npm/npmrc).
:::
### corepack {#javascript-corepack}
This package puts the corepack wrappers for pnpm and yarn in your PATH, and they honor the `packageManager` setting in the `package.json`.
This package puts the corepack wrappers for pnpm and yarn in your PATH, and they will honor the `packageManager` setting in the `package.json`.
### pnpm {#javascript-pnpm}
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_9`, `pnpm_10`, `pnpm_10_29_2` and `pnpm_11`, which support different sets of lock file versions.
pnpm is available as the top-level package `pnpm`. Additionally, there are variants pinned to certain major versions, like `pnpm_8`, `pnpm_9`, `pnpm_10`, `pnpm_10_29_2` and `pnpm_11`, which support different sets of lock file versions.
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The function `fetchPnpmDeps` can create this pnpm store derivation. In conjunction, the setup hook `pnpmConfigHook` prepares the build environment to install the pre-fetched dependencies store. The example below uses the fetcher and setup hook for a package that has `package.json` and `pnpm-lock.yaml`:
When packaging an application that includes a `pnpm-lock.yaml`, you need to fetch the pnpm store for that project using a fixed-output-derivation. The function `fetchPnpmDeps` can create this pnpm store derivation. In conjunction, the setup hook `pnpmConfigHook` will prepare the build environment to install the pre-fetched dependencies store. Here is an example for a package that contains `package.json` and a `pnpm-lock.yaml` files using the fetcher and setup hook above:
There is also the [`pnpmBuildHook`](#pnpm-build-hook) for building packages with `pnpm`, as seen in [](#ex-pnpm-build-hook).
@@ -331,7 +350,7 @@ stdenv.mkDerivation (finalAttrs: {
})
```
Use a pinned version of pnpm (for example `pnpm_9` or `pnpm_10`) to increase reproducibility. An older version may be required if the package needs a certain lock file version. To do so, pass the `pnpm` argument to `fetchPnpmDeps`. Then override the `pnpm` arg in `pnpmConfigHook`. Here are the changes in the example above to use a pinned pnpm version:
It is highly recommended to use a pinned version of pnpm (i.e., `pnpm_9` or `pnpm_10`), to increase future reproducibility. It might also be required to use an older version if the package needs support for a certain lock file version. To do so, you can pass the `pnpm` argument to `fetchPnpmDeps` and override the `pnpm` arg in `pnpmConfigHook`. Here are the changes in the example above to use a pinned pnpm version:
<!-- TODO: Does splicing still work when overriding in nativeBuildInputs here? -->
@@ -373,7 +392,7 @@ Use a pinned version of pnpm (for example `pnpm_9` or `pnpm_10`) to increase rep
})
```
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e., `inherit (finalAttrs) patches`).
In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `finalAttrs.patches` to the function as well (i.e., `inherit (finalAttrs) patches`.
`pnpmConfigHook` supports adding additional `pnpm install` flags via `pnpmInstallFlags` which can be set to a Nix string array:
@@ -389,14 +408,12 @@ In case you are patching `package.json` or `pnpm-lock.yaml`, make sure to pass `
}
```
If needed, set `dontPnpmConfigure = true;` to fully disable `pnpmConfigHook` without removing it from inputs manually.
#### Dealing with `sourceRoot` {#javascript-pnpm-sourceRoot}
If the pnpm project is in a subdirectory, you can define `sourceRoot` or `setSourceRoot` for `fetchPnpmDeps`.
If `sourceRoot` is different between the parent derivation and `fetchPnpmDeps`, you have to set `pnpmRoot` to effectively be the same location as it is in `fetchPnpmDeps`.
If the pnpm project is in a subdirectory, you can just define `sourceRoot` or `setSourceRoot` for `fetchPnpmDeps`.
If `sourceRoot` is different between the parent derivation and `fetchPnpmDeps`, you will have to set `pnpmRoot` to effectively be the same location as it is in `fetchPnpmDeps`.
Assuming the directory structure below, you can define `sourceRoot` and `pnpmRoot`:
Assuming the following directory structure, we can define `sourceRoot` and `pnpmRoot` as follows:
```
.
@@ -420,9 +437,10 @@ Assuming the directory structure below, you can define `sourceRoot` and `pnpmRoo
}
```
#### pnpm workspaces {#javascript-pnpm-workspaces}
#### PNPM Workspaces {#javascript-pnpm-workspaces}
For a pnpm workspace, set `pnpmWorkspaces = [ "<workspace project name 1>" "<workspace project name 2>" ]` in your `fetchPnpmDeps` call. pnpm then installs only the dependencies for those workspace packages.
If you need to use a PNPM workspace for your project, then set `pnpmWorkspaces = [ "<workspace project name 1>" "<workspace project name 2>" ]`, etc, in your `fetchPnpmDeps` call,
which will make PNPM only install dependencies for those workspace packages.
For example:
@@ -438,9 +456,9 @@ For example:
```
The above would make `fetchPnpmDeps` call only install dependencies for the `@astrojs/language-server` workspace package.
You do not need to set `sourceRoot` to make this work.
Note that you do not need to set `sourceRoot` to make this work.
For these projects, build with `pnpm --filter=<pnpm workspace name> build`, because `npmHooks.npmBuildHook` may not work. The example below fits most workspace projects:
Usually, in such cases, you'd want to use `pnpm --filter=<pnpm workspace name> build` to build your project, as `npmHooks.npmBuildHook` probably won't work. A `buildPhase` based on the following example will probably fit most workspace projects:
```nix
{
@@ -454,9 +472,9 @@ For these projects, build with `pnpm --filter=<pnpm workspace name> build`, beca
}
```
#### Additional pnpm commands and settings {#javascript-pnpm-extraCommands}
#### Additional PNPM Commands and settings {#javascript-pnpm-extraCommands}
If you require setting an additional pnpm configuration setting (such as `dedupe-peer-dependents` or similar),
If you require setting an additional PNPM configuration setting (such as `dedupe-peer-dependents` or similar),
set `prePnpmInstall` to the right commands to run. For example:
```nix
@@ -471,11 +489,11 @@ set `prePnpmInstall` to the right commands to run. For example:
}
```
In this example, `prePnpmInstall` runs in both `pnpmConfigHook` and the `fetchPnpmDeps` builder.
In this example, `prePnpmInstall` will be run by both `pnpmConfigHook` and by the `fetchPnpmDeps` builder.
#### pnpm `fetcherVersion` {#javascript-pnpm-fetcherVersion}
This is the version of the output of `fetchPnpmDeps`. Use `4` for new packages:
This is the version of the output of `fetchPnpmDeps`. New packages should use `3`:
```nix
{
@@ -491,7 +509,7 @@ This is the version of the output of `fetchPnpmDeps`. Use `4` for new packages:
When upgrading to a newer `fetcherVersion`, you need to regenerate the hash.
This variable ensures that we can make changes to the output of `fetchPnpmDeps` without breaking existing hashes.
Changes can include workarounds or bug fixes to existing pnpm issues.
Changes can include workarounds or bug fixes to existing PNPM issues.
##### Version history {#javascript-pnpm-fetcherVersion-versionHistory}
@@ -504,9 +522,9 @@ Version 3 is the minimum supported value. Versions 1 and 2 were removed in the 2
### Yarn {#javascript-yarn}
Yarn-based projects use a `yarn.lock` file instead of a `package-lock.json` to pin dependencies.
Yarn based projects use a `yarn.lock` file instead of a `package-lock.json` to pin dependencies.
To package Yarn-based applications, you need to distinguish by the version pointers in the `yarn.lock` file. See the following sections.
To package yarn-based applications, you need to distinguish by the version pointers in the `yarn.lock` file. See the following sections.
#### Yarn v1 {#javascript-yarn-v1}
@@ -575,12 +593,12 @@ This script by default runs `yarn --offline build`, and it relies upon the proje
##### `yarnInstallHook` arguments {#javascript-yarninstallhook}
To install the package, `yarnInstallHook` uses both `npm` and `yarn` to clean up project files and dependencies. To disable this phase, you can set `dontYarnInstall = true` or override the `installPhase`. Below is a list of additional `mkDerivation` arguments read by this hook:
To install the package `yarnInstallHook` uses both `npm` and `yarn` to cleanup project files and dependencies. To disable this phase, you can set `dontYarnInstall = true` or override the `installPhase`. Below is a list of additional `mkDerivation` arguments read by this hook:
- `yarnKeepDevDeps`: Disables the removal of devDependencies from `node_modules` before installation.
#### Yarn Berry v3/v4 {#javascript-yarn-v3-v4}
Yarn Berry (v3 / v4) versions have similar formats. They start with blocks like these:
Yarn Berry (v3 / v4) have similar formats, they start with blocks like these:
```yaml
__metadata:
@@ -600,7 +618,7 @@ For these packages, we have some helpers exposed under the respective `yarn-berr
- `fetchYarnBerryDeps`
- `yarnBerryConfigHook`
Explicitly pin the major version. For example, capture the `yarn-berry_Xn` argument and re-define it as a `yarn-berry` `let` binding.
It's recommended to ensure you're explicitly pinning the major version used, for example by capturing the `yarn-berry_Xn` argument and then re-defining it as a `yarn-berry` `let` binding.
```nix
{
@@ -636,26 +654,26 @@ stdenv.mkDerivation (finalAttrs: {
##### `yarn-berry_X.fetchYarnBerryDeps` {#javascript-fetchYarnBerryDeps}
`fetchYarnBerryDeps` runs `yarn-berry-fetcher fetch` in a fixed-output-derivation. It is a custom fetcher designed to reproducibly download all files in the `yarn.lock` file, validating their hashes in the process. For git dependencies, it creates a checkout at `${offlineCache}/checkouts/<40-character-commit-hash>` (relying on the git commit hash to describe the contents of the checkout).
To produce the `hash` argument for the `fetchYarnBerryDeps` call, run `yarn-berry-fetcher prefetch`:
To produce the `hash` argument for `fetchYarnBerryDeps` function call, the `yarn-berry-fetcher prefetch` command can be used:
```console
$ yarn-berry-fetcher prefetch </path/to/yarn.lock> [/path/to/missing-hashes.json]
```
This prints the hash to stdout. Use it in update scripts to recalculate the hash for a new `yarn.lock`.
This prints the hash to stdout and can be used in update scripts to recalculate the hash for a new version of `yarn.lock`.
##### `yarn-berry_X.yarnBerryConfigHook` {#javascript-yarnBerryConfigHook}
`yarnBerryConfigHook` uses the store path `offlineCache` points to, to run a `yarn install` during the build, producing a usable `node_modules` directory from the downloaded dependencies.
Internally, this uses a patched version of Yarn to ensure git dependencies are re-packed and any attempted downloads fail immediately.
##### Patching the project's `package.json` or `yarn.lock` files {#javascript-yarnBerry-patching}
In case patching the project's `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e., `inherit (finalAttrs) patches`).
##### Patching upstream `package.json` or `yarn.lock` files {#javascript-yarnBerry-patching}
In case patching the upstream `package.json` or `yarn.lock` is needed, it's important to pass `finalAttrs.patches` to `fetchYarnBerryDeps` as well, so the patched variants are picked up (i.e., `inherit (finalAttrs) patches`.
##### Missing hashes in the `yarn.lock` file {#javascript-yarnBerry-missing-hashes}
Unfortunately, `yarn.lock` files do not include hashes for optional/platform-specific dependencies. This is [by design](https://github.com/yarnpkg/berry/issues/6759).
To compensate for this, run the `yarn-berry-fetcher missing-hashes` subcommand to produce all missing hashes. These are stored in a `missing-hashes.json` file, which needs to be passed to both the build itself, as well as the `fetchYarnBerryDeps` helper:
To compensate for this, the `yarn-berry-fetcher missing-hashes` subcommand can be used to produce all missing hashes. These are usually stored in a `missing-hashes.json` file, which needs to be passed to both the build itself, as well as the `fetchYarnBerryDeps` helper:
```nix
{
@@ -698,7 +716,7 @@ 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 may 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}
@@ -706,7 +724,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 may 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}

View File

@@ -162,17 +162,6 @@ the package `luarocks-packages-updater`:
nix-shell -p luarocks-packages-updater --run luarocks-packages-updater
```
To add a new package without updating all packages, run
```sh
nix-shell -p luarocks-packages-updater
luarocks-packages-updater add [--maintainers "<maintainer>"] <package-name>
```
The optional `--maintainers` argument accepts a space-separated list of nixpkgs maintainer names.
When omitted, the package is added without maintainers.
[luarocks2nix](https://github.com/nix-community/luarocks) is a tool capable of generating nix derivations from both rockspec and src.rock (and favors the src.rock).
The automation only goes so far though and some packages need to be customized.
These customizations go in [pkgs/development/lua-modules/overrides.nix](https://github.com/NixOS/nixpkgs/tree/master/pkgs/development/lua-modules/overrides.nix).

View File

@@ -174,59 +174,6 @@ To make sure that your package does not add extra manual effort when upgrading M
</plugin>
```
## Maven 4 {#maven-4}
Alongside the default `maven` package (the latest Maven 3 release), nixpkgs ships `maven_4`, which packages the [Maven 4](https://maven.apache.org/whatsnewinmaven4.html) release line.
`maven_4` is a standalone derivation and can be used as a drop-in replacement wherever `maven` is used, for example to build a project with the latest Maven 4:
```nix
{
lib,
fetchFromGitHub,
jre,
makeWrapper,
maven_4,
}:
maven_4.buildMavenPackage (finalAttrs: {
pname = "jd-cli";
version = "1.2.1";
src = fetchFromGitHub {
owner = "intoolswetrust";
repo = "jd-cli";
tag = "jd-cli-${finalAttrs.version}";
hash = "sha256-rRttA5H0A0c44loBzbKH7Waoted3IsOgxGCD2VM0U/Q=";
};
mvnHash = "";
nativeBuildInputs = [ makeWrapper ];
installPhase = ''
runHook preInstall
mkdir -p $out/bin $out/share/jd-cli
install -Dm644 jd-cli/target/jd-cli.jar $out/share/jd-cli
makeWrapper ${jre}/bin/java $out/bin/jd-cli \
--add-flags "-jar $out/share/jd-cli/jd-cli.jar"
runHook postInstall
'';
meta = {
description = "Simple command line wrapper around JD Core Java Decompiler project";
homepage = "https://github.com/intoolswetrust/jd-cli";
license = lib.licenses.gpl3Plus;
maintainers = with lib.maintainers; [ majiir ];
};
})
```
`maven_4` exposes the same `buildMavenPackage` helper as `maven` (see [](#maven-buildmavenpackage)), so all of the patterns documented above apply equally. Note that the Maven dependencies resolved by Maven 4 differ from those resolved by Maven 3, so `mvnHash` must be recomputed when switching between the two.
## Manually using `mvn2nix` {#maven-mvn2nix}
::: {.warning}
This way is no longer recommended; see [](#maven-buildmavenpackage) for the simpler and preferred way.
@@ -341,7 +288,7 @@ The double invocation is a _simple_ way to get around the problem that `nix-buil
It treats the entire Maven repository as a single source to be downloaded, relying on Maven's dependency resolution to satisfy the output hash. This is similar to fetchers like `fetchgit`, except it has to run a Maven build to determine what to download.
The first step will be to build the Maven project as a fixed-output derivation to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
The first step will be to build the Maven project as a fixed-output derivation in order to collect the Maven repository -- below is an [example](https://github.com/fzakaria/nixos-maven-example/blob/main/double-invocation-repository.nix).
::: {.note}
Traditionally the Maven repository is at `~/.m2/repository`. We will override this to be the `$out` directory.
@@ -469,7 +416,7 @@ The previous example builds a `jar` file but that's not a file one can run.
You need to use it with `java -jar $out/share/java/output.jar` and make sure to provide the required dependencies on the classpath.
The following explains how to use `makeWrapper` to make the derivation produce an executable that will run the JAR file you created.
The following explains how to use `makeWrapper` in order to make the derivation produce an executable that will run the JAR file you created.
We will use the same repository we built above (either _double invocation_ or _buildMaven_) to setup a CLASSPATH for our JAR.

View File

@@ -25,7 +25,7 @@ neovim.override {
withRuby = false;
configure = {
customRC = ''
" here your custom viml configuration goes!
# here your custom viml configuration goes!
'';
packages.myVimPackage = with pkgs.vimPlugins; {
# See examples below on how to use custom packages.
@@ -47,7 +47,7 @@ neovim-qt.override {
neovim = neovim.override {
configure = {
customRC = ''
" your custom viml configuration
# your custom viml configuration
'';
};
};
@@ -64,14 +64,11 @@ For instance, `sqlite-lua` needs `g:sqlite_clib_path` to be set to work. Nixpkgs
- `wrapRc`: Nix, not being able to write in your `$HOME`, loads the
generated Neovim configuration via the `$VIMINIT` environment variable, i.e. : `export VIMINIT='lua dofile("/nix/store/…-init.lua")'`. This has side effects like preventing Neovim from sourcing your `init.lua` in `$XDG_CONFIG_HOME/nvim` (see bullet 7 of [`:help startup`](https://neovim.io/doc/user/starting.html#startup) in Neovim). Disable it if you want to generate your own wrapper. You can still reuse the generated vimscript init code via `neovim.passthru.initRc`.
- `plugins`: A list of plugins to add to the wrapper.
- `extraLuaPackages`: A function passed on to `lua.withPackages`.
- `extraPython3Packages`: A function passed on to `python3.withPackages`.
- `withPython3`, `withNodeJs`, `withRuby`, `withPerl` control when to enable neovim
- `extraLuaPackages`: A function passed on to `lua.withPackages`
- `withPython3`, `withNodeJs`, `withRuby` control when to enable neovim
providers (see `:h provider`).
- `vimAlias` and `viAlias` control whether to symlink the `vim` and `vi` binaries to `nvim` respectively.
- `extraName` is a string appended to the package name and derivation name.
```nix
```
wrapNeovimUnstable neovim-unwrapped {
autoconfigure = true;
autowrapRuntimeDeps = true;
@@ -83,8 +80,7 @@ wrapNeovimUnstable neovim-unwrapped {
vim.opt.colorcolumn = { 100 }
vim.opt.termguicolors = true
'';
# plugins accepts a list of either plugins or attribute sets containing:
# { plugin = ...; config = ...; type = "viml"|"lua"; } (type defaults to "viml")
# plugins accepts a list of either plugins or { plugin = ...; config = ..vimscript.. };
plugins = with vimPlugins; [
{
plugin = vim-obsession;
@@ -92,19 +88,7 @@ wrapNeovimUnstable neovim-unwrapped {
map <Leader>$ <Cmd>Obsession<CR>
'';
}
{
plugin = grug-far-nvim;
type = "lua";
config = ''
require('grug-far').setup({
startInInsertMode = false,
})
'';
}
(nvim-treesitter.withPlugins (p: [
p.nix
p.python
]))
(nvim-treesitter.withPlugins (p: [ p.nix p.python ]))
hex-nvim
];
extraLuaPackages = lp: [ lp.mpack ];
@@ -114,12 +98,12 @@ wrapNeovimUnstable neovim-unwrapped {
}
```
You can explore the configuration with `nix repl` to discover these options and
You can explore the configuration with`nix repl` to discover these options and
override them. For instance:
```nix
neovim.override {
neovim.overrideAttrs (oldAttrs: {
autowrapRuntimeDeps = false;
}
})
```
## Specificities for some plugins {#neovim-plugin-specificities}
@@ -152,7 +136,7 @@ For example, if upstream documents that a plugin uses the Vim license but GitHub
## LuaRocks based plugins {#neovim-luarocks-based-plugins}
To automatically handle plugin dependencies, several Neovim plugins
In order to automatically handle plugin dependencies, several Neovim plugins
upload their package to [LuaRocks](https://www.luarocks.org). This means less work for nixpkgs maintainers in the long term as dependencies get updated automatically.
This means several Neovim plugins are first packaged as nixpkgs [lua
packages](#packaging-a-library-on-luarocks), and converted via `buildNeovimPlugin` in
@@ -167,8 +151,6 @@ For instance:
```
To update these packages, you should use the lua updater rather than vim's.
To add a lua package to the `vimPlugins` set, add it to the `luarocksPackageNames` list in [luaPackagePlugins.nix](https://github.com/nixos/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/luaPackagePlugins.nix).
## Treesitter {#neovim-plugin-treesitter}
[Treesitter](https://tree-sitter.github.io/) provides syntax parsing for Neovim, enabling features like:
@@ -264,43 +246,6 @@ You can install the standalone parsers and queries directly without installing `
})
```
### Treesitter setup using WASM parsers and queries {#neovim-plugin-treesitter-wasm}
Neovim can load WASM parsers when it is built with Wasmtime support.
In nixpkgs, WASM parser plugins are available from the `wasm32-wasip1` cross package set:
```nix
(pkgs.wrapNeovim (pkgs.neovim-unwrapped.override { wasmSupport = true; }) {
configure = {
packages.myPlugins =
with pkgs.pkgsCross.wasm32-wasip1.vimPlugins;
let
# Select the grammars you need
treesitter-grammars = with nvim-treesitter-parsers; [
nix
python
];
# Queries are needed for treesitter based syntax highlighting and folds.
treesitter-queries = map (p: p.associatedQuery) treesitter-grammars;
in
{
start = [
# regular plugins
]
++ treesitter-grammars
++ treesitter-queries;
};
};
})
```
Do not install both native and WASM parsers for the same language.
For example, installing both `pkgs.vimPlugins.nvim-treesitter-parsers.nix` and
`pkgs.pkgsCross.wasm32-wasip1.vimPlugins.nvim-treesitter-parsers.nix` is invalid because Neovim
loads the first `parser/nix.*` found on `runtimepath`.
Use `:checkhealth vim.treesitter` to verify Nix-managed WASM parsers.
You can enable treesitter features for installed grammars in a `FileType` autocommand
or in an `ftplugin/<language>.lua` script, e.g.

View File

@@ -59,9 +59,6 @@ Here is a simple package example.
- The library will be installed using the `angstrom.install` file that dune
generates.
- It also accepts an optional `dunePackages` argument, if there is more than one
dune package that needs to be built (see `zipperposition`)
```nix
{
lib,

View File

@@ -204,9 +204,25 @@ following are specific to `buildPythonPackage`:
* `setupPyGlobalFlags ? []`: List of flags passed to `setup.py` command.
* `setupPyBuildFlags ? []`: List of flags passed to `setup.py build_ext` command.
##### Writing override-compatible packages {#buildpythonpackage-fixed-point-arguments}
##### Using fixed-point arguments {#buildpythonpackage-fixed-point-arguments}
Use `finalAttrs` to make a package easy to update and override:
Both `buildPythonPackage` and `buildPythonApplication` support [fixed-point arguments](#chap-build-helpers-finalAttrs), similar to `stdenv.mkDerivation`.
This allows you to reference the final attributes of the derivation.
Instead of using `rec`:
```nix
buildPythonPackage rec {
pname = "pyspread";
version = "2.4";
src = fetchPypi {
inherit pname version;
hash = "sha256-...";
};
}
```
You can use the `finalAttrs` pattern:
```nix
buildPythonPackage (finalAttrs: {
@@ -220,9 +236,7 @@ buildPythonPackage (finalAttrs: {
})
```
When a downstream callsite *overrides* `version` the override becomes visible as `finalAttrs.version`.
Both `buildPythonPackage` and `buildPythonApplication` support [fixed-point arguments](#chap-build-helpers-finalAttrs), similar to `stdenv.mkDerivation`.
See the [general documentation on fixed-point arguments](#chap-build-helpers-finalAttrs) for more details on the benefits of this pattern.
::: {.note}
@@ -1614,7 +1628,7 @@ looked at how you can create environments in which specified packages are
available.
At some point you'll likely have multiple packages which you would
like to be able to use in different projects. To minimise unnecessary
like to be able to use in different projects. In order to minimise unnecessary
duplication we now look at how you can maintain a repository with your
own packages. The important functions here are `import` and `callPackage`.
@@ -1861,7 +1875,7 @@ pkgs.mkShell rec {
pythonPackages.numpy
pythonPackages.requests
# In this particular example, to compile any binary extensions they may
# In this particular example, in order to compile any binary extensions they may
# require, the Python modules listed in the hypothetical requirements.txt need
# the following packages to be installed locally:
taglib
@@ -2092,7 +2106,7 @@ See also [contributing section](#contributing).
### Are Python interpreters built deterministically? {#deterministic-builds}
The Python interpreters are now built deterministically. Minor modifications had
to be made to the interpreters to generate deterministic bytecode. This
to be made to the interpreters in order to generate deterministic bytecode. This
has security implications and is relevant for those using Python in a
`nix-shell`.

View File

@@ -3,12 +3,11 @@
Note that "The Rocq Prover" (Rocq for short) is the new name of the
proof assistant formerly known as Coq. The `coq` and `coqPackages`
derivations currently remain for both older versions of Coq, but also
as compatibility aliases for some versions of Rocq. In both cases, the
`coq` and `rocq-core` attributes exist. In the case of Coq (< 9),
`rocq-core` is just an alias for `coq`, while in the case of Rocq (>= 9),
`rocq-core` is the main Rocq derivation, while `coq` provides
compatibility binaries (`coqc`, `coqtop`, etc.) for packages that still
depend on them.
some versions of Rocq during the renaming transition. In the latter
case, the `coq` derivation encompasses the compatibility binaries
(`coqtop`, `coqc`, etc.) in addition to the `rocq` binary. The packages
only in `coqPackages` are the ones which currently still depend on these
compatibility binaries.
## Rocq derivation: `rocq-core` {#rocq-derivation-rocq}
@@ -18,18 +17,18 @@ The Rocq derivation is overridable through the `rocq-core.override overrides`, w
* `customOCamlPackages` (optional, defaults to `null`, which lets Rocq choose a version automatically), which can be set to any of the ocaml packages attribute of `ocaml-ng` (such as `ocaml-ng.ocamlPackages_4_14` which is the default for Rocq 9.1 for example).
* `rocq-version` (optional, defaults to the short version e.g. "9.1"), is a version number of the form "x.y" that indicates which Rocq's version build behavior to mimic when using a source which is not a release. E.g. `rocq-core.override { version = "40be8435e132aab2231a79091f011ebc3e64a753"; rocq-version = "9.1"; }`.
## Creating custom Coq environments with `rocq-core.withPackages` {#coq-withPackages}
## Creating custom Coq environments with `coq.withPackages` {#coq-withPackages}
The `rocq-core.withPackages` function provides a convenient way to create a Rocq environment that includes additional Rocq packages. This is similar to how `python.withPackages` works for Python environments.
The `coq.withPackages` function provides a convenient way to create a Coq environment that includes additional Coq packages. This is similar to how `python.withPackages` works for Python environments.
The function takes a function that receives the Rocq package set and returns a list of packages. It returns a wrapped Rocq environment where the Rocq binaries (`rocq`, etc.) are configured with the appropriate environment variables to find the packages.
The function takes a function that receives the Coq package set and returns a list of packages. It returns a wrapped Coq environment where all Coq binaries (`coqtop`, `coqc`, `coqdep`, `coqchk`, `coqide`, etc.) are configured with the appropriate environment variables to find the packages.
### Usage {#coq-withPackages-usage}
Here is an example of creating a Rocq environment with specific packages.
Here is an example of creating a Coq environment with specific packages.
```nix
rocq-core.withPackages (
coq.withPackages (
ps: with ps; [
mathcomp
bignums
@@ -37,9 +36,7 @@ rocq-core.withPackages (
)
```
If you install the `vsrocq-language-server` or `rocq-lsp` server, make sure to list them as part of the above `rocq-core.withPackages` expression instead of installing them separately if you want them to find your Rocq packages.
For versions prior to Rocq 9.0, a similar `coq.withPackages` function is available.
If you install the `vsrocq-language-server` or `rocq-lsp` server, make sure to list them as part of the above `coq.withPackages` expression instead of installing them separately if you want them to find your Coq/Rocq packages.
## Rocq packages attribute sets: `rocqPackages` {#rocq-packages-attribute-sets-rocqpackages}
@@ -54,7 +51,7 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
* if it is a string of the form `owner:branch` then it tries to download the `branch` of owner `owner` for a project of the same name using the same vcs, and the `version` attribute of the resulting derivation is set to `"dev"`, additionally if the owner is not provided (i.e. if the `owner:` prefix is missing), it defaults to the original owner of the package (see below),
* 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). Rocq libraries may be compatible with some specific versions of Rocq 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 `rocq-core` 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 `rocqPackages` 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 `hash` attribute (you may put the empty string `""` to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` assuming the default fetcher is used) and optional overrides for the result of the fetcher (i.e. `version` and `src`).
* `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 `hash` attribute (you may put the empty string `""` in order to automatically insert a fake hash, this will trigger an error which will allow you to find the correct hash), each attribute set of the list of releases also takes optional overloading arguments for the fetcher as below (i.e.`domain`, `owner`, `repo`, `rev`, `artifact` 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 `hash` and returns an attribute set with a `version` and `src`.
* `repo` (optional, defaults to the value of `pname`),
* `owner` (optional, defaults to `"rocq-community"`).
@@ -62,7 +59,7 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
* `releaseRev` (optional, defaults to `(v: v)`), provides a default mapping from release names to revision hashes/branch names/tags,
* `releaseArtifact` (optional, defaults to `(v: null)`), provides a default mapping from release names to artifact names (only works for github artifact for now),
* `displayVersion` (optional), provides a way to alter the computation of `name` from `pname`, by explaining how to display version numbers,
* `namePrefix` (optional, defaults to `[ "rocq" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
* `namePrefix` (optional, defaults to `[ "rocq-core" ]`), provides a way to alter the computation of `name` from `pname`, by explaining which dependencies must occur in `name`,
* `nativeBuildInputs` (optional), is a list of executables that are required to build the current derivation, in addition to the default ones (namely `which`, `dune` and `ocaml` depending on whether `useDune`, `useDuneifVersion` and `mlPlugin` are set).
* `extraNativeBuildInputs` (optional, deprecated), an additional list of derivation to add to `nativeBuildInputs`,
* `overrideNativeBuildInputs` (optional) replaces the default list of derivation to which `nativeBuildInputs` and `extraNativeBuildInputs` adds extra elements,
@@ -71,14 +68,12 @@ The recommended way of defining a derivation for a Rocq library, is to use the `
* `overrideBuildInputs` (optional) replaces the default list of derivation to which `buildInputs` and `extraBuildInputs` adds extras elements,
* `propagatedBuildInputs` (optional) is passed as is to `mkDerivation`, we recommend to use this for Rocq libraries and Rocq plugin dependencies, as this makes sure the paths of the compiled libraries and plugins will always be added to the build environments of subsequent derivation, which is necessary for Rocq packages to work correctly,
* `mlPlugin` (optional, defaults to `false`). Some extensions (plugins) might require OCaml and sometimes other OCaml packages. Standard dependencies can be added by setting the current option to `true`. For a finer grain control, the `rocq-core.ocamlPackages` attribute can be used in `nativeBuildInputs`, `buildInputs`, and `propagatedBuildInputs` to depend on the same package set Rocq was built against.
* `useDuneifVersion` (optional, default to `(x: false)`) uses Dune to build the package if the provided predicate evaluates to true on the version, e.g. `useDuneifVersion = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
* `useDuneifVersion` (optional, default to `(x: false)` uses Dune to build the package if the provided predicate evaluates to true on the version, e.g. `useDuneifVersion = versions.isGe "1.1"` will use dune if the version of the package is greater or equal to `"1.1"`,
* `useDune` (optional, defaults to `false`) uses Dune to build the package if set to true, the presence of this attribute overrides the behavior of the previous one.
* `opam-name` (optional, defaults to concatenating with a dash separator the components of `namePrefix` and `pname`), name of the Dune package to build.
* `enableParallelBuilding` (optional, defaults to `true`), since it is activated by default, we provide a way to disable it.
* `extraInstallFlags` (optional), allows to extend `installFlags` which initializes the variables `COQLIBINSTALL` and `COQPLUGININSTALL` so as to install in the proper subdirectory. Indeed Rocq libraries should be installed in `$(out)/lib/coq/${rocq-core.rocq-version}/user-contrib/`. Such directories are automatically added to the `$ROCQPATH` environment variable by the hook defined in the Rocq derivation.
* `setROCQBIN` (optional, defaults to `true`), by default, the environment variable `$ROCQBIN` is set to the current Rocq's binary, but one can disable this behavior by setting it to `false`,
* `useCoq` (optional, defaults to `false`), adds the Coq compatibility binaries to the build environment, which is necessary for some packages that still depend on them and sets `COQBIN` to the path of the `coqc` binary (if `setROCQBIN` is also set to `true`). A wrapper `mkCoqDerivation` is provided that sets this option to `true`.
* `useCoqifVersion` (optional, defaults to `(x: false)`), adds the Coq compatibility binaries to the build environment if the provided predicate evaluates to true on the version. This can be useful for supporting old package versions that need the Coq compatibility binaries, while newer versions do not.
* `useMelquiondRemake` (optional, default to `null`) is an attribute set, which, if given, overloads the `preConfigurePhases`, `configureFlags`, `buildPhase`, and `installPhase` attributes of the derivation for a specific use in libraries using `remake` as set up by Guillaume Melquiond for `flocq`, `gappalib`, `interval`, and `coquelicot` (see the corresponding derivation for concrete examples of use of this option). For backward compatibility, the attribute `useMelquiondRemake.logpath` must be set to the logical root of the library (otherwise, one can pass `useMelquiondRemake = {}` to activate this without backward compatibility).
* `dropAttrs`, `keepAttrs`, `dropDerivationAttrs` are all optional and allow to tune which attribute is added or removed from the final call to `mkDerivation`.
@@ -133,7 +128,7 @@ mkRocqDerivation {
mathcomp.boot
mathcomp.algebra
mathcomp-finmap
mathcomp.finite-group
mathcomp.fingroup
mathcomp-bigenough
];
@@ -158,7 +153,7 @@ For example, assuming you have a special `mathcomp` dependency you want to use,
multinomials.override { mathcomp = my-special-mathcomp; }
```
In Nixpkgs, all Rocq derivations take a `version` argument. This can be overridden to easily use a different version:
In Nixpkgs, all Rocq derivations take a `version` argument. This can be overridden in order to easily use a different version:
```nix
rocqPackages.multinomials.override { version = "1.5.1"; }

View File

@@ -125,7 +125,7 @@ With this file in your directory, you can run `nix-shell` to build and use the g
The `bundlerEnv` is a wrapper over all the gems in your gemset. This means that all the `/lib` and `/bin` directories will be available, and the executables of all gems (even of indirect dependencies) will end up in your `$PATH`. The `wrappedRuby` provides you with all executables that come with Ruby itself, but wrapped so they can easily find the gems in your gemset.
One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So to give the `bundler` from your gemset priority, it would be used like this:
One common issue that you might have is that you have Ruby, but also `bundler` in your gemset. That leads to a conflict for `/bin/bundle` and `/bin/bundler`. You can resolve this by wrapping either your Ruby or your gems in a `lowPrio` call. So in order to give the `bundler` from your gemset priority, it would be used like this:
```nix
# ...
@@ -265,7 +265,7 @@ Now that you know how to get a working Ruby environment with Nix, it's time to g
All gems in the standard set are automatically generated from a single `Gemfile`. The dependency resolution is done with `bundler` and makes it more likely that all gems are compatible with each other.
To add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
In order to add a new gem to nixpkgs, you can put it into the `/pkgs/development/ruby-modules/with-packages/Gemfile` and run `./maintainers/scripts/update-ruby-packages`.
To test that it works, you can then try using the gem with:

View File

@@ -739,7 +739,7 @@ stdenv.mkDerivation (finalAttrs: {
### Compiling `wasm32-wasip1` package {#compiling-wasm32-wasip1-package}
```nix
pkgsCross.wasm32-wasip1.callPackage (
pkgsCross.wasi32.callPackage (
{
fetchFromGitHub,
rustPlatform,
@@ -885,7 +885,8 @@ general. A number of other parameters can be overridden:
empty, or `"forbid"` (no cap) when `lints` is set. Because `rustc`
only honours the first `--cap-lints` it receives, this cannot be
changed via `extraRustcOpts`; use this attribute instead. Useful
with `useClippy`, since clippy lints are also capped by this flag:
when overriding the `rust` attribute to point at `clippy-driver`,
since clippy lints are also capped by this flag:
```nix
(hello { }).override { capLints = "warn"; }
@@ -911,34 +912,6 @@ general. A number of other parameters can be overridden:
}
```
- Whether to compile the crate with `clippy-driver` instead of `rustc`.
Build scripts (`build.rs`) keep plain `rustc`. The default `capLints`
of `"allow"` suppresses all lints including clippy's, so this is
usually paired with `capLints` and lint flags via `extraRustcOpts`:
```nix
(hello { }).override {
useClippy = true;
capLints = "warn";
extraRustcOpts = [
"-Dwarnings"
"-Wclippy::all"
];
}
```
When using a Rust toolchain that bundles its own `clippy-driver`
(rust-overlay, Fenix), pass it via `clippy` so the sysroot matches:
```nix
(hello { }).override {
rust = myToolchain;
clippy = myToolchain;
useClippy = true;
capLints = "warn";
}
```
- 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,

View File

@@ -160,7 +160,7 @@ This essentially runs: `swift test -c release`
In some cases, it may be necessary to patch a SwiftPM dependency. SwiftPM
dependencies are located in `.build/checkouts`, but the `swiftpm2nix` helper
provides these as symlinks to read-only `/nix/store` paths. To patch
provides these as symlinks to read-only `/nix/store` paths. In order to patch
them, we need to make them writable.
A special function `swiftpmMakeMutable` is available to replace the symlink

View File

@@ -32,21 +32,6 @@ There is a TeX Live packaging that lives entirely under attribute `texlive`.
)
```
- Packages can be overriden by passing a new package with the same `pname` to `.withPackages`. For instance, the following replaces Asymptote with the version from Nixpkgs, which is usually more up to date:
```nix
texliveMedium.withPackages (ps: [ asymptote ])
```
- To exclude a package from a collection, use an empty override as below:
```nix
texliveBasic.withPackages (
ps: with ps; [
collection-bibtexextra
{ pname = "bib2gls"; }
]
)
```
- To add the documentation for all packages in the environment, use
```nix
texliveSmall.overrideAttrs { withDocs = true; }

View File

@@ -149,16 +149,11 @@ Note: this is not possible anymore for Neovim.
## Adding new plugins to nixpkgs {#adding-new-plugins-to-nixpkgs}
:::{.note}
Before adding a Neovim Lua plugin, check if a release is available on [luarocks](https://luarocks.org/).
If it is, add it as a [LuaRocks based plugin](#neovim-luarocks-based-plugins).
:::
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 [`nix-shell -p vimPluginsUpdater --run vim-plugins-updater`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/utils/updater.nix). 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).
When the vim updater detects an nvim-treesitter update, it also runs [`nvim-treesitter/update.py $(nix-build -A vimPlugins.nvim-treesitter)`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/vim/plugins/utils/update.py) to update the tree sitter grammars for `nvim-treesitter`.
Some plugins require overrides 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:
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
{

View File

@@ -1,4 +1,4 @@
# Nixpkgs Manual {#nixpkgs-manual}
# Nixpkgs Reference Manual {#nixpkgs-manual}
## Version @MANUAL_VERSION@
```{=include=} chapters
@@ -6,7 +6,6 @@ preface.chapter.md
```
```{=include=} parts
getting-started/getting-started.part.md
using-nixpkgs.md
lib.md
stdenv.md
@@ -18,10 +17,6 @@ contributing.md
interoperability.md
```
```{=include=} chapters
languages-frameworks/index.md
```
```{=include=} appendix html:into-file=//release-notes.html
release-notes/release-notes.md
```

View File

@@ -1,4 +0,0 @@
{
"open": [],
"items": []
}

View File

@@ -10,7 +10,7 @@ The tarball archive needs to be downloaded manually, as the license agreements o
The [self-service](https://support.citrix.com/article/CTX200337) is an application for managing Citrix desktops and applications. Please note that this feature only works with at least `citrix_workspace_20_06_0` and later versions.
To set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
In order to set this up, you first have to [download the `.cr` file from the Netscaler Gateway](https://its.uiowa.edu/support/article/102186). After that, you can configure the `selfservice` like this:
```ShellSession
$ storebrowse -C ~/Downloads/receiverconfig.cr
@@ -19,7 +19,7 @@ $ selfservice
## Custom certificates {#sec-citrix-custom-certs}
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however, this directory is a store path in `nixpkgs`. To work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
The `Citrix Workspace App` in `nixpkgs` trusts several certificates [from the Mozilla database](https://curl.haxx.se/docs/caextract.html) by default. However, several companies using Citrix might require their own corporate certificate. On distros with imperative packaging, these certs can be stored easily in [`$ICAROOT`](https://citrix.github.io/receiver-for-linux-command-reference/), however, this directory is a store path in `nixpkgs`. In order to work around this issue, the package provides a simple mechanism to add custom certificates without rebuilding the entire package using `symlinkJoin`:
```nix
with import <nixpkgs> { config.allowUnfree = true; };

View File

@@ -83,57 +83,6 @@ $ sudo launchctl kickstart -k system/org.nixos.nix-daemon
Note that if the builder is running and you have created the above ssh conf file, you can ssh into the builder with `sudo ssh builder@linux-builder`.
## Using the Virtualization.framework backend {#sec-darwin-builder-vz}
`darwin.linux-builder-vz` is a variant of `darwin.linux-builder` that runs the same
NixOS guest on Apple's Virtualization.framework (via `pkgs.vzvm`) instead of QEMU.
Instead of emulating x86_64, it exposes Rosetta to the guest, so `x86_64-linux`
builds are translated rather than emulated, which is substantially faster. It
requires an Apple silicon host (`aarch64-darwin`) running macOS 13 or newer, with
Rosetta installed:
```ShellSession
$ softwareupdate --install-rosetta --agree-to-license
```
The builder refuses to start when Rosetta is missing, rather than silently dropping
`x86_64-linux` support; set `virtualisation.vz.rosetta.enable = false` to run
without it.
It is a drop-in replacement: it listens on the same host port (31022) and presents
the same host key as the QEMU builder, so the `nix.conf` and SSH configuration
described above apply unchanged; only the transport behind the port changes, from
TCP forwarding to vsock. Since a single builder VM handles both architectures
through Rosetta, list both systems in your `builders` entry
(`aarch64-linux,x86_64-linux`), or with nix-darwin:
```nix
{
nix.linux-builder = {
enable = true;
package = pkgs.darwin.linux-builder-vz;
systems = [
"aarch64-linux"
"x86_64-linux"
];
};
}
```
When switching an existing QEMU builder over, delete its data disk first (e.g.
`sudo rm /var/lib/linux-builder/nixos.qcow2`): the vz builder reuses the file name
but writes a raw image, and refuses to misread a genuine qcow2 left behind.
The guest console goes to the macOS unified log by default; read it with:
```ShellSession
$ /usr/bin/log show --last 5m --predicate 'subsystem == "systems.applicative.vzvm"'
```
The `virtualisation.vz.*` NixOS options configure the backend further, e.g.
`virtualisation.vz.nestedVirtualization` gives the guest a working `/dev/kvm` for
running NixOS integration tests on the builder (macOS 15+, M3 or newer).
## Example flake usage {#sec-darwin-builder-example-flake}
```nix

View File

@@ -24,7 +24,7 @@ The Emacs package comes with some extra helpers to make it easier to configure.
}
```
You can install it like any other package via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts. Similarly, for `early-init.el`, you can create a package that provides an `early-default.el` file in `/share/emacs/site-start/`.
You can install it like any other package via `nix-env -iA myEmacs`. However, this will only install those packages. It will not `configure` them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provides a `default.el` file in `/share/emacs/site-start/`. Emacs knows to load this file automatically when it starts.
```nix
{

View File

@@ -25,7 +25,6 @@ etc-files.section.md
nginx.section.md
nrfutil.section.md
opengl.section.md
packer.section.md
shell-helpers.section.md
python-tree-sitter.section.md
treefmt.section.md

View File

@@ -1,70 +0,0 @@
# Packer {#sec-packer}
[Packer](https://www.packer.io) is a tool for creating identical machine images
for multiple platforms from a single source configuration.
## Using Packer with plugins {#sec-packer-with-plugins}
Packer's functionality is extended through
[plugins](https://developer.hashicorp.com/packer/docs/plugins). Rather than
letting Packer download plugins at runtime, you can build a Packer wrapper that
bundles the plugins you need with `packer.withPlugins`.
`packer.withPlugins` takes a function that receives the set of available plugins
and returns the list of plugins to include:
```nix
packer.withPlugins (ps: [ ps.docker ])
```
This produces a `packer` executable wrapped with the `PACKER_PLUGIN_PATH`
environment variable set, so the selected plugins are available without a
separate `packer plugins install` step.
For example, to get a development shell with Packer and the Docker plugin:
```nix
{
pkgs ? import <nixpkgs> { },
}:
pkgs.mkShell {
packages = [
(pkgs.packer.withPlugins (ps: [ ps.docker ]))
];
}
```
Multiple plugins can be selected at once:
```nix
packer.withPlugins (ps: [
ps.docker
ps.qemu
])
```
## Listing available plugins {#sec-packer-list-plugins}
The packaged plugins are exposed as the `packer.plugins` attribute set. To list
every plugin available in your version of Nixpkgs, query its attribute names:
```ShellSession
$ nix eval nixpkgs#packer.plugins --apply builtins.attrNames
[ "docker" "qemu" ]
```
Without flakes:
```ShellSession
$ nix-env -f '<nixpkgs>' -qaP -A packer.plugins
packer.plugins.docker packer-plugin-docker-1.1.2
packer.plugins.qemu packer-plugin-qemu-1.1.4
```
The attribute name (for example `docker` or `qemu`) is what you pass to
`packer.withPlugins`.
Notes:
- `mkPackerPlugin` currently only supports `fetchFromGitHub` as the fetcher.

View File

@@ -22,7 +22,7 @@ rxvt-unicode.override {
If the `configure` function returns an attrset without the `plugins` attribute, `availablePlugins` will be used automatically.
To add plugins but also keep all default plugins installed, it is possible to use the following method:
In order to add plugins but also keep all default plugins installed, it is possible to use the following method:
```nix
rxvt-unicode.override {

Some files were not shown because too many files have changed in this diff Show More