python3Packages.nbclassic: 1.2.0 -> 1.3.3
This commit was automatically generated using update-python-libraries.
Co-authored-by: Michael Daniels <mdaniels5757@gmail.com>
python3Packages.xstatic-font-awesome: 6.2.1.1 -> 6.2.1.2
This commit was automatically generated using update-python-libraries.
Co-authored-by: Michael Daniels <mdaniels5757@gmail.com>
Use standard zlib instead instead of sortix libz. Python itself depends
on zlib so this dependency added a *different* version of the "z"
library to the closures of all Python packages dependeng on distutils.
2026-06-29 18:19:42 -04:00
6581 changed files with 64718 additions and 113616 deletions
@@ -587,9 +587,9 @@ CI [enforces](./.github/workflows/lint.yml) all Nix files to be formatted using
You can ensure this locally using either of these commands:
```
nix fmt
nix develop --command treefmt
nix-shell --run treefmt
nix develop --command treefmt
nix fmt
```
If you're starting your editor in `nix-shell` or `nix develop`, you can also set it up to automatically run `treefmt` on save.
@@ -957,6 +957,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 that’s the case and point them to this policy as appropriate.
Please assume good faith and remain civil; it’s 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 people’s time with low quality contributions, including but not limited to LLM and bot spam”.
`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}\`).`,
`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}.`,
`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')
awaitpostReview({
github,
context,
core,
dry,
body,
event:'REQUEST_CHANGES',
reviewKey,
})
}
exportasyncfunctioncheckTargetBranch({
asyncfunctioncheckTargetBranch({
github,
context,
core,
@@ -158,7 +69,41 @@ export async function checkTargetBranch({
`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')
if(decision==='mass-rebuild'){
awaitpostMassRebuildReview(reviewFacts)
return
}
awaitpostReview({
github,
context,
core,
dry,
body,
event:'REQUEST_CHANGES',
reviewKey,
})
}elseif(rebuildsAllTests&&!isExemptKernelUpdate){
letbranchText: string
if(base==='master'&&maxRebuildCount>=500){
branchText='(probably either `staging-nixos` or `staging`)'
}elseif(base==='master'){
branchText='(probably `staging-nixos`)'
}elseif(maxRebuildCount>=500){
branchText=`(probably either \`staging-nixos-${split(base).version}\` or \`staging-${split(base).version}\`)`
`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}.`,
`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')
if(decision==='possible-mass-rebuild'){
awaitpostPossibleMassRebuildReview(reviewFacts)
return
}
if(decision==='skip-development-merge'){
core.info(
`Skipping checkTargetBranch: PR merges the development branch ${head} into ${base}`,
)
awaitpostReview({
github,
context,
core,
dry,
body,
event:'REQUEST_CHANGES',
reviewKey,
})
}else{
core.info('checkTargetBranch: this PR is against an appropriate branch.')
@@ -15,3 +15,15 @@ In addition, it offers various options to customize parts of the builds.
There is no uniform interface for build helpers.
[Trivial build helpers](#chap-trivial-builders) and [fetchers](#chap-pkgs-fetchers) have various input types for convenience.
[Language- or framework-specific build helpers](#chap-language-support) usually follow the style of `stdenv.mkDerivation`, which accepts an attribute set or a fixed-point function taking an attribute set.
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:
`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}
@@ -336,8 +332,8 @@ Usually, we need to create a `shell.nix` file and do our development inside the
withpkgs;
let
# pin OTP via beam27Packages/beam28Packages/... and Elixir via overrideScope
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.
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.
`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.
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.
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).
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,14 @@ 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.
If needed, `dontPnpmConfigure = true;` can be used to fully disable `pnpmConfigHook` without manually removing it from inputs.
#### 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 +439,10 @@ Assuming the directory structure below, you can define `sourceRoot` and `pnpmRoo
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 +458,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 +474,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 +491,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.
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:
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 +620,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.
`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:
`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 +718,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 +726,7 @@ There are some [problems with npm v7](https://github.com/tweag/npmlock2nix/issue
[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.
This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org.
- `moon` has been updated to `2.x` and needs manual migration. See the [migration guide](https://moonrepo.dev/docs/migrate/2.0) for instructions.
- `perlPackages.NetOAuth` has been updated from 0.28 to 0.33.
Callers that verify messages must now set `allowed_signature_methods` per message or configure `@Net::OAuth::ALLOWED_SIGNATURE_METHODS`; `verify` otherwise throws an exception.
See the [upstream changelog](https://metacpan.org/dist/Net-OAuth/changes) for details.
- []{#x86_64-darwin-26.11}
Support for `x86_64-darwin` has been dropped, due to Apple’s deprecation of the platform and limited build infrastructure and developer time.
@@ -49,14 +40,10 @@
- `databricks-cli` has been updated from `0.290.2` to `1.x.x`, the first major release. OAuth tokens for interactive logins (`auth_type = databricks-cli`) are now stored in the OS-native secure store by default (Secret Service on Linux) instead of `~/.databricks/token-cache.json`; cached tokens from older versions are not migrated, so run `databricks auth login` once per profile after upgrading. To keep the previous file-backed storage, set `DATABRICKS_AUTH_STORAGE=plaintext` or add `auth_storage = plaintext` under `[__settings__]` in `~/.databrickscfg`. Additionally, the `vector_search_endpoints` DABs resource renamed `min_qps` to `target_qps` (and the `vector-search-endpoints` command renamed `--min-qps` to `--target-qps`). See the [upstream changelog](https://github.com/databricks/cli/blob/main/CHANGELOG.md) for details.
- Gradle 7 has been removed because it is end-of-life. Please [upgrade to a newer version of Gradle](https://docs.gradle.org/current/userguide/upgrading_version_7.html).
- `hurl` has been updated to `8.x.x` which has some breaking changes. See [upstream changelog](https://github.com/Orange-OpenSource/hurl/releases/tag/8.0.0) for details.
- The existing `wasm32-wasi` target has become `wasm32-wasip1` and `pkgsCross.wasi32` has become `pkgsCross.wasm32-wasip1`, aligning with LLVM's nomenclature. Aliases are in place and old forms will continue to be parsed but there might be some breakage if you're relying on the exact form of these (e.g., in sysroot paths).
- `sing-box` has been updated to 1.14.0, which has removed some deprecated options. See [upstream documentation](https://sing-box.sagernet.org/migration/) for details and migration options.
- `gotosocial` has been updated to 0.22.0. This release contains a very long database migration, which should not be cancelled or interrupted under any circumstances.
- Postgres users: Following the migration, if you encounter slowdown on Postgres specifically (ie., timing out while loading timelines) you may need to run some manual database maintenance steps. Please check https://docs.gotosocial.org/en/stable/admin/database_maintenance/#postgres.
@@ -79,16 +66,12 @@
- `services.mysql` now sets `root@localhost` authentication to `auth_socket` when used with `mysql` or `percona-server`.
Existing deployments will also be adjusted if possible. See the [security advisory GHSA-6qxx-6rg8-c4p8](https://github.com/NixOS/nixpkgs/security/advisories/GHSA-6qxx-6rg8-c4p8) for more information.
- `sqlitestudio` has been renamed to `letos` to reflect upstream changes. See [Letos: Name rebranding](https://github.com/pawelsalawa/letos/issues/5441) for more information.
- `zerofs` has been updated from `1.x` to `2.x` which is a breaking change. Volumes created by earlier releases are refused at open with a clear error. There is no migration tool; older volumes remain readable and writable by the release that created them.
- `keycloak.plugins.keycloak-metrics-spi` has been removed. Keycloak exposes Prometheus metrics natively on its management interface; enable them with the `metrics-enabled` setting (and `event-metrics-user-enabled` for login and event counters). See [Gaining insights with metrics](https://www.keycloak.org/observability/configuration-metrics).
- `alps` has been rewritten upstream, see [upstream repository](https://github.com/migadu/alps) for documentation.
- `writers.makeDataWriter` has been removed. It has been deprecated since 2023. Use `pkgs.writeTextFile` instead.
- `bosun` has been removed as it is no longer maintained upstream. the corresponding monitoring options has been removed.
- `uhttpmock` providing 0.0 ABI was removed. `uhttpmock_1_0` providing 1.0 ABI was renamed to `uhttpmock` and `uhttpmock_1_0` was kept as an alias.
@@ -97,10 +80,10 @@
- `tengine` has been removed as it has seen seriously delayed responses to security vulnerabilities.
- `writeTextFile` now uses structured attributes and `passAsFile` is no longer used or supported.
- `nix-serve-ng` (and `haskellPackages.nix-serve-ng`) is now built against Lix instead of CppNix, following upstream which has switched to Lix as its supported Nix implementation.
- `buildPythonPackage` and `buildPythonApplication` now set `__structuredAttrs = true` by default. You can explicitly set `__structuredAttrs = false` in packages broken by this change.
- Linux kernel configuration has been moved out of the `linux-kernel` field of the platform structure into the kernel builders:
- `linux-kernel.name` has been removed.
- `linux-kernel.target` is available as the `target` parameter and passthru attribute on the kernel builders.
@@ -116,12 +99,8 @@
`lib.systems.{examples,platforms}.{sheevaplug,pogoplug4}` have been unified into `lib.systems.examples.armv5tel-multiplatform`.
Note that there is no official support for ARMv5 and it is not possible to build even a simple NixOS configuration out of the box.
- `tcl.mkTclDerivation` now enables `strictDeps` and `__structuredAttrs`.
- `pdns` has been updated from `5.0.x` to `5.1.x`. Please be sure to review the [Upgrade Notes](https://doc.powerdns.com/authoritative/upgrading.html#to-5-1-0) before upgrading. Namely LUA record updates are no longer allowed by default, and the embedded webserver no longer includes a `access-control-allow-origin: *` header by default.
- LibreOffice upstream switched from Fresh/Still stable branches to a single Stable branch; `libreoffice` and `libreoffice-qt` work as before, but more specific aliases like `libreoffice-fresh` should be replaced.
- `davmail` no longer supports building with GTK 2, and the `preferGtk3` override flag has been removed as GTK 3 is always used.
- Support for the legacy U‐Boot image format has been removed from the Linux kernel builders, as it is deprecated upstream and no longer used by any platform in Nixpkgs.
@@ -134,9 +113,6 @@
Users who must continue using ingress-nginx will now need to manually provide the rke2-images-ingress-nginx tarball.
- Future Removal: The ingress-nginx chart will not receive any additional updates and will be completely removed in v1.37 for community users.
- `replaceVarsWith` now enables `strictDeps` and `__structuredAttrs` and passing these attributes to the function is no longer allowed.
By extension, `replaceVars` now also enables `strictDeps` and `__structuredAttrs`.
- `buildFHSEnvChroot` has been removed after deprecation in 23.05.
- `leafnode` has been removed, as it was an unmaintained alpha-release of leafnode 2 and has a dependency on the EOL PRCE-library. Consider using `leafnode1` instead, which is still maintained.
@@ -149,28 +125,14 @@
- `texlive.combine` is deprecated and scheduled for removal in 27.05. Please migrate to `texliveSmall.withPackages` (see [](#sec-language-texlive-user-guide)).
- `katex` has been updated from 0.16 to 0.18 and has introduced breaking changes. See upstream changelog for details: [0.17.0](https://github.com/KaTeX/KaTeX/releases/tag/v0.17.0), [0.18.0](https://github.com/KaTeX/KaTeX/releases/tag/v0.18.0).
- `keycloak` was updated to >= 26.7.0 and includes some breaking internal (API) changes. See the [upstream migration guide](https://www.keycloak.org/docs/latest/upgrading/#migrating-to-26-7-0) for more information.
- `pdfium` is now built from source instead of packaging prebuilt binaries. `pdfium-binaries` has been renamed to `pdfium`, and `pdfium-binaries-v8` has been removed.
- `librest` providing 0.7 ABI was removed. `librest_1_0` providing 1.0 ABI was renamed to `librest` and `librest_1_0` was kept as an alias.
- `luaPackages.lrexlib-pcre` has been removed as part of the process to fully migrate from the end-of-life PRCE library to PCRE2. `luaPackages.lrexlib-pcre2` and multiple other versions of lrexlib can be used instead.
- `pnpm_10` was upgraded to version 10.34.1+, which introduced stricter integrity checks. If you encounter `ERR_PNPM_MISSING_TARBALL_INTEGRITY`, you can fall back to the older `pnpm_10_34_0`.
- `buildMozillaMach` is now using `enable<feature>` and `with<dependency>`
terminology from RFC 169 and the `wrapFirefox` and `wrapThunderbird` functions
check for these new attribute names on the passed package.
The `privacySupport` function argument has been replaced by multiple
granular options corresponding to individual features: `enableDataReporting`,
`enableLocation`, `enableWebRTC`.
The `requireSigning` and `allowAddonSideload` function arguments moved from
the outer to the inner function and were renamed to `enableAddonSigning` and
`enableAddonSideload`, respectively.
- `fetchPnpmDeps`' `fetcherVersion = 1` and `fetcherVersion = 2` have been
removed, as announced in the 26.05 release. Packages still using them now
throw an evaluation error and must migrate to `fetcherVersion = 3` (or later)
@@ -191,8 +153,6 @@
- The deprecated `appimageTools.extractType1`, `appimageTools.extractType2`, and `appimageTools.wrapType1` aliases now emit warnings. Use `appimageTools.extract` and `appimageTools.wrapType2` instead.
- netbox plugins have been moved from the python3Packages to the netboxPlugins package set.
## Other Notable Changes {#sec-nixpkgs-release-26.11-notable-changes}
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
@@ -201,8 +161,6 @@
- `buildFHSEnv`, `appimageTools.wrapAppImage`, and `appimageTools.wrapType2` now support the `finalAttrs` pattern. When using `wrapAppImage`, it is now recommended to pass the extracted AppImage to the `contents` attribute (instead of `src`), to avoid shadowing `src`. Passing the extracted contents to `src` is now deprecated and will be removed in a future release.
- All databases of the MySQL family – `mysql`, `mariadb` and `percona` – now provide a client-only package `client` sub-attribute. Use the `<dbname>.client` package if the server components are not needed. The main package continues to ship the client binaries as well.
- Package-URL (PURL, https://github.com/package-url/purl-spec) metadata identifier has been added for `fetchgit`, `fetchpypi` and `fetchFromGithub` fetchers.
`mkDerivation` has been adjusted to reuse this information.
Package-URLs allow reliably identifying and locating software packages.
@@ -213,8 +171,6 @@
- `homebox` v0.26.0 introduced a new, required value to be set, `HBOX_AUTH_API_KEY_PEPPER`. If one is not provided the module will create one, it is recommended that you back this up as it is part of API Key generation and validation.
- `nextpnr` introduced support for the nexus and gatemate architectures. Building support for each individual architecture can be configured using the package parameters.
- Emacs loads the `early-default` library after `early-init.el`.
Users can add `early-init.el` via `emacs.pkgs.withPackages`
by packaging `early-init.el` into a library named `early-default`.
@@ -225,8 +181,6 @@
They were missing before because Ceph omitted logs when this directory was missing.
Ceph logs can grow large, so you may want to configure rotation of these logs.
- Firefox wrapper now accepts an optional `appDataDir` argument, which sets `MOZ_APP_DATA` to relocate Firefox application data. This is especially useful on macOS 27 and later, where wrapped Firefox applications may be denied access to profiles in traditional application data directory.
<!-- To avoid merge conflicts, consider adding your item at an arbitrary place in the list instead. -->
@@ -235,8 +189,6 @@
- `fittrackee` 1.0.0 now requires postgres with postgis. The [upgrade guide](https://docs.fittrackee.org/en/upgrading-to-1.0.0.html) has steps to prepare for this upgrade.
- `typescript` 7.0.2 now uses the Golang implementation. The [announcement document](https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/) has information on what was changed.
@@ -493,7 +493,7 @@ When using native compilation, `stdenv` is lenient towards incorrect placement o
While convenient for getting to a package quickly, this behavior can break cross-compilation. Adding `strictDeps = true` as a parameter to `mkDerivation` or any of its language specific wrappers disables this behavior.
The specialized `build*` functions for dlang, emacs, go, nim, ocaml, python, rust, and `tcl.mkTclDerivation` enable this option by default.
The specialized `build*` functions for dlang, emacs, go, nim, ocaml, python, and rust enable this option by default.
## Attributes {#ssec-stdenv-attributes}
@@ -508,7 +508,6 @@ A number between 0 and 7 indicating how much information to log. If set to 1 or
@@ -34,13 +34,6 @@ In order to do so, add yourself to the [`maintainer-list.nix`](./maintainer-list
If you're adding yourself as a maintainer as part of another PR (in which you become a maintainer of a package, for example), make your change to
`maintainer-list.nix` in a separate commit titled `maintainers: add <handle>`.
Once the PR is merged you will automatically get invited to join the [NixOS/nixpkgs-maintainers](https://github.com/orgs/NixOS/teams/nixpkgs-maintainers) GitHub team.
By joining, we will be able to ping you for review, and you will get some triaging rights in the nixpkgs repository, like the ability to close and reopen issues made by others and managing labels, as well as invoke the merge bot on eligible PRs.
> [!NOTE]
> The automatic GitHub team invite is usually only sent by email, and is only valid for one week!
> Should it expire, please request a new one by following the instructions [here](https://github.com/NixOS/rfc39-record/blob/main/README.md#requesting-a-new-invitation).
### Losing maintainer status
Maintainers who have become inactive can be removed.
@@ -61,6 +54,11 @@ This process is subject to error however, so we encourage PR authors to notify t
Maintainers can also invoke the [nixpkgs-merge-bot](../ci/README.md#nixpkgs-merge-bot) to merge pull requests targeting packages they are the maintainer of, which satisfy the current security [constraints](../ci/README.md#merge-bot-constraints).
Examples: [#397273](https://github.com/NixOS/nixpkgs/pull/397273#issuecomment-2789382120) and [#377027](https://github.com/NixOS/nixpkgs/pull/377027#issuecomment-2614510869)
New maintainers will automatically get invited to join the [NixOS/nixpkgs-maintainers](https://github.com/orgs/NixOS/teams/nixpkgs-maintainers) GitHub team.
By joining, you will get some triaging rights in the nixpkgs repository, like the ability to close and reopen issues made by others, and managing labels.
However, the GitHub team invite is usually only sent by email, and is only valid for one week!
Should it expire, please ask for a re-invite in the [GitHub org owners help desk Matrix channel](https://matrix.to/#/#org_owners:nixos.org).
### Unofficial maintainer tooling
[zh.fail](https://zh.fail/failed/overview.html) tracks all package build failures on `master` grouped by maintainer.
In-tree tests run with a few changes to defaults, notably
- The `pkgs.*` are read only by default. You can opt out with `node.pkgsReadOnly = false;` at the test level.
-`nix.enable` defaults to `false` to reduce build closure size; in particular the reverse build closure of `nix` and its dependencies.
### Testing outside the NixOS project {#sec-call-nixos-test-outside-nixos}
Outside the `nixpkgs` repository, you can use the `runNixOSTest` function from
@@ -114,8 +110,6 @@ pkgs.testers.runNixOSTest {
`runNixOSTest` returns a derivation that runs the test.
Out-of-tree tests evaluate with a set of defaults that balances the principle of least surprise in the general case, but has a few differences from in-tree NixOS tests. See [Testing within NixOS](#sec-call-nixos-test-in-nixos).
## Test machines {#ssec-nixos-test-machines}
A NixOS test usually consists of one or more test machines. Each machine is either a
- `services.pds` has been renamed to `services.bluesky-pds`.
- `services.pfix-srsd` now automatically integrates with the local Postfix instance, when enabled. This behavior can disabled using the `services.pfix-srsd.configurePostfix` option.
- `services.pfix-srsd` now automatically integrates with the local Postfix instance, when enabled. This behavior can disabled using the [services.pfix-srsd.configurePostfix](#opt-services.pfix-srsd.configurePostfix) option.
- `services.postsrsd` now automatically integrates with the local Postfix instance, when enabled. This behavior can disabled using the [services.postsrsd.configurePostfix](#opt-services.postsrsd.configurePostfix) option.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.