Compare commits

..

1 Commits

Author SHA1 Message Date
Raito Bezarius
fc39343438 nixos/lib/make-disk-image: introduce noNixStore option
Sometimes, we want to use the host nix store for everything because it's
more convenient.

To do so, we need to "not install" the nix store in the target disk
image.

We trick nixos-install by mount binding the host nix store into the
$root/nix folder and letting Nix do the idempotency thing.
2023-04-23 23:48:35 +02:00
6583 changed files with 237989 additions and 353522 deletions

View File

@@ -101,7 +101,3 @@ end_of_line = unset
insert_final_newline = unset
trim_trailing_whitespace = unset
charset = unset
[lib/tests/*.plist]
indent_style = tab
insert_final_newline = unset

2
.gitattributes vendored
View File

@@ -1,6 +1,6 @@
**/deps.nix linguist-generated
**/deps.json linguist-generated
**/deps.toml linguist-generated
**/deps.toml lingust-generated
**/node-packages.nix linguist-generated
pkgs/applications/editors/emacs-modes/*-generated.nix linguist-generated

46
.github/CODEOWNERS vendored
View File

@@ -22,19 +22,19 @@
/.editorconfig @Mic92 @zowoq
# Libraries
/lib @edolstra @infinisil
/lib/systems @alyssais @ericson2314 @matthewbauer
/lib/generators.nix @edolstra @Profpatsch
/lib/cli.nix @edolstra @Profpatsch
/lib/debug.nix @edolstra @Profpatsch
/lib/asserts.nix @edolstra @Profpatsch
/lib @edolstra @nbp @infinisil
/lib/systems @alyssais @nbp @ericson2314 @matthewbauer
/lib/generators.nix @edolstra @nbp @Profpatsch
/lib/cli.nix @edolstra @nbp @Profpatsch
/lib/debug.nix @edolstra @nbp @Profpatsch
/lib/asserts.nix @edolstra @nbp @Profpatsch
/lib/path.* @infinisil @fricklerhandwerk
# Nixpkgs Internals
/default.nix @Ericson2314
/pkgs/top-level/default.nix @Ericson2314
/pkgs/top-level/impure.nix @Ericson2314
/pkgs/top-level/stage.nix @Ericson2314 @matthewbauer
/default.nix @nbp
/pkgs/top-level/default.nix @nbp @Ericson2314
/pkgs/top-level/impure.nix @nbp @Ericson2314
/pkgs/top-level/stage.nix @nbp @Ericson2314 @matthewbauer
/pkgs/top-level/splice.nix @Ericson2314 @matthewbauer
/pkgs/top-level/release-cross.nix @Ericson2314 @matthewbauer
/pkgs/stdenv/generic @Ericson2314 @matthewbauer
@@ -67,9 +67,22 @@
/doc/using @fricklerhandwerk
# NixOS Internals
/nixos/default.nix @infinisil
/nixos/lib/from-env.nix @infinisil
/nixos/lib/eval-config.nix @infinisil
/nixos/default.nix @nbp @infinisil
/nixos/lib/from-env.nix @nbp @infinisil
/nixos/lib/eval-config.nix @nbp @infinisil
/nixos/doc/manual/configuration/abstractions.xml @nbp
/nixos/doc/manual/configuration/config-file.xml @nbp
/nixos/doc/manual/configuration/config-syntax.xml @nbp
/nixos/doc/manual/configuration/modularity.xml @nbp
/nixos/doc/manual/development/assertions.xml @nbp
/nixos/doc/manual/development/meta-attributes.xml @nbp
/nixos/doc/manual/development/option-declarations.xml @nbp
/nixos/doc/manual/development/option-def.xml @nbp
/nixos/doc/manual/development/option-types.xml @nbp
/nixos/doc/manual/development/replace-modules.xml @nbp
/nixos/doc/manual/development/writing-modules.xml @nbp
/nixos/doc/manual/man-nixos-option.xml @nbp
/nixos/modules/installer/tools/nixos-option.sh @nbp
/nixos/modules/system @dasJ
/nixos/modules/system/activation/bootspec.nix @grahamc @cole-h @raitobezarius
/nixos/modules/system/activation/bootspec.cue @grahamc @cole-h @raitobezarius
@@ -305,10 +318,3 @@ pkgs/development/python-modules/buildcatrust/ @ajs124 @lukegb @mweinelt
/pkgs/build-support/ocaml @romildo @ulrikstrid
/pkgs/development/compilers/ocaml @romildo @ulrikstrid
/pkgs/development/ocaml-modules @romildo @ulrikstrid
# ZFS
pkgs/os-specific/linux/zfs @raitobezarius
nixos/lib/make-single-disk-zfs-image.nix @raitobezarius
nixos/lib/make-multi-disk-zfs-image.nix @raitobezarius
nixos/modules/tasks/filesystems/zfs.nix @raitobezarius
nixos/tests/zfs.nix @raitobezarius

View File

@@ -22,7 +22,7 @@ For new packages please briefly describe the package or provide a link to its ho
- made sure NixOS tests are [linked](https://nixos.org/manual/nixpkgs/unstable/#ssec-nixos-tests-linking) to the relevant packages
- [ ] Tested compilation of all packages that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"`. Note: all changes have to be committed, also see [nixpkgs-review usage](https://github.com/Mic92/nixpkgs-review#usage)
- [ ] Tested basic functionality of all binary files (usually in `./result/bin/`)
- [23.11 Release Notes (or backporting 23.05 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
- [23.05 Release Notes (or backporting 22.11 Release notes)](https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#generating-2305-release-notes)
- [ ] (Package updates) Added a release notes entry if the change is major or breaking
- [ ] (Module updates) Added a release notes entry if the change is significant
- [ ] (Module addition) Added a release notes entry if adding a new NixOS module

View File

@@ -19,7 +19,7 @@ jobs:
# we don't limit this action to only NixOS repo since the checks are cheap and useful developer feedback
steps:
- uses: actions/checkout@v3
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
- uses: cachix/cachix-action@v12
with:
# This cache is for the nixpkgs repo checks and should not be trusted or used elsewhere.

View File

@@ -16,7 +16,7 @@ jobs:
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -28,7 +28,7 @@ jobs:
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
# nixpkgs commit is pinned so that it doesn't break
# editorconfig-checker 2.4.0

View File

@@ -18,7 +18,7 @@ jobs:
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -19,7 +19,7 @@ jobs:
with:
# pull_request_target checks out the base branch by default
ref: refs/pull/${{ github.event.pull_request.number }}/merge
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -18,7 +18,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
# explicitly enable sandbox
extra_nix_config: sandbox = true

View File

@@ -38,10 +38,6 @@ jobs:
into: staging-next-22.11
- from: staging-next-22.11
into: staging-22.11
- from: release-23.05
into: staging-next-23.05
- from: staging-next-23.05
into: staging-23.05
name: ${{ matrix.pairs.from }} → ${{ matrix.pairs.into }}
steps:
- uses: actions/checkout@v3

View File

@@ -17,7 +17,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: cachix/install-nix-action@v21
- uses: cachix/install-nix-action@v20
with:
nix_path: nixpkgs=channel:nixpkgs-unstable
- name: setup

View File

@@ -1 +1 @@
23.11
23.05

View File

@@ -43,7 +43,6 @@ Below is a short excerpt of some points in there:
* Not start with the package name.
* More generally, it should not refer to the package name.
* Not end with a period (or any punctuation for that matter).
* Aim to inform while avoiding subjective language.
* `meta.license` must be set and fit the upstream license.
* If there is no upstream license, `meta.license` should default to `lib.licenses.unfree`.
* If in doubt, try to contact the upstream developers for clarification.
@@ -106,17 +105,17 @@ git push origin feature --force-with-lease
Follow these steps to backport a change into a release branch in compliance with the [commit policy](https://nixos.org/nixpkgs/manual/#submitting-changes-stable-release-branches).
You can add a label such as `backport release-23.05` to a PR, so that merging it will
You can add a label such as `backport release-22.11` to a PR, so that merging it will
automatically create a backport (via [a GitHub Action](.github/workflows/backport.yml)).
This also works for pull requests that have already been merged, and might take a couple of minutes to trigger.
This also works for PR's that have already been merged, and might take a couple of minutes to trigger.
You can also create the backport manually:
1. Take note of the commits in which the change was introduced into `master` branch.
2. Check out the target _release branch_, e.g. `release-23.05`. Do not use a _channel branch_ like `nixos-23.05` or `nixpkgs-23.05-darwin`.
2. Check out the target _release branch_, e.g. `release-22.11`. Do not use a _channel branch_ like `nixos-22.11` or `nixpkgs-22.11-darwin`.
3. Create a branch for your change, e.g. `git checkout -b backport`.
4. When the reason to backport is not obvious from the original commit message, use `git cherry-pick -xe <original commit>` and add a reason. Otherwise use `git cherry-pick -x <original commit>`. That's fine for minor version updates that only include security and bug fixes, commits that fixes an otherwise broken package or similar. Please also ensure the commits exists on the master branch; in the case of squashed or rebased merges, the commit hash will change and the new commits can be found in the merge message at the bottom of the master pull request.
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-23.05`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[23.05]`.
5. Push to GitHub and open a backport pull request. Make sure to select the release branch (e.g. `release-22.11`) as the target branch of the pull request, and link to the pull request in which the original change was committed to `master`. The pull request title should be the commit title with the release version as prefix, e.g. `[22.11]`.
6. When the backport pull request is merged and you have the necessary privileges you can also replace the label `9.needs: port to stable` with `8.has: port to stable` on the original pull request. This way maintainers can keep track of missing backports easier.
## Criteria for Backporting changes
@@ -128,7 +127,7 @@ Anything that does not cause user or downstream dependency regressions can be ba
- Services which require a client to be up-to-date regardless. (E.g. `spotify`, `steam`, or `discord`)
- Security critical applications (E.g. `firefox`)
## Generating 23.11 Release Notes
## Generating 23.05 Release Notes
<!--
note: title unchanged even though we don't need regeneration because extant
PRs will link here. definitely change the title for 23.11 though.
@@ -136,10 +135,10 @@ PRs will link here. definitely change the title for 23.11 though.
Documentation in nixpkgs is transitioning to a markdown-centric workflow. In the past release notes required a translation step to convert from markdown to a compatible docbook document, but this is no longer necessary.
Steps for updating 23.11 Release notes:
Steps for updating 23.05 Release notes:
1. Edit `nixos/doc/manual/release-notes/rl-2311.section.md` with the desired changes
2. Commit changes to `rl-2311.section.md`.
1. Edit `nixos/doc/manual/release-notes/rl-2305.section.md` with the desired changes
2. Commit changes to `rl-2305.section.md`.
## Reviewing contributions

View File

@@ -51,9 +51,9 @@ Nixpkgs and NixOS are built and tested by our continuous integration
system, [Hydra](https://hydra.nixos.org/).
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
* [Continuous package builds for the NixOS 23.05 release](https://hydra.nixos.org/jobset/nixos/release-23.05)
* [Continuous package builds for the NixOS 22.11 release](https://hydra.nixos.org/jobset/nixos/release-22.11)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
* [Tests for the NixOS 23.05 release](https://hydra.nixos.org/job/nixos/release-23.05/tested#tabs-constituents)
* [Tests for the NixOS 22.11 release](https://hydra.nixos.org/job/nixos/release-22.11/tested#tabs-constituents)
Artifacts successfully built with Hydra are published to cache at
https://cache.nixos.org/. When successful build and test criteria are

View File

@@ -19,9 +19,6 @@ pandoc_flags = --extract-media=$(pandoc_media_dir) \
.PHONY: all
all: validate format out/html/index.html out/epub/manual.epub
.PHONY: render-md
render-md: ${MD_TARGETS}
.PHONY: debug
debug:
nix-shell --run "xmloscopy --docbook5 ./manual.xml ./manual-full.xml"

View File

@@ -1,7 +1,7 @@
{ pkgs ? import ../../.. {} }:
let
inherit (pkgs) lib;
manpageURLs = lib.importJSON (pkgs.path + "/doc/manpage-urls.json");
manpageURLs = builtins.fromJSON (builtins.readFile (pkgs.path + "/doc/manpage-urls.json"));
in pkgs.writeText "link-manpages.lua" ''
--[[
Adds links to known man pages that aren't already in a link.

View File

@@ -1,12 +1,9 @@
# buildFHSEnv {#sec-fhs-environments}
`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root filesystem with the host's `/nix/store`, so its footprint in terms of disk space is quite small. This allows you to run software which is hard or unfeasible to patch for NixOS; 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries for instance.
It uses Linux' namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without requiring elevated privileges. It works similar to containerisation technology such as Docker or FlatPak but provides no security-relevant separation from the host system.
Accepted arguments are:
`buildFHSEnv` provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound `/nix/store`, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
- `name`
The name of the environment and the wrapper executable.
Environment name.
- `targetPkgs`
Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
- `multiPkgs`
@@ -20,35 +17,33 @@ Accepted arguments are:
- `extraInstallCommands`
Additional commands to be executed for finalizing the derivation with runner script.
- `runScript`
A shell command to be executed inside the sandbox. It defaults to `bash`. Command line arguments passed to the resulting wrapper are appended to this command by default.
This command must be escaped; i.e. `"foo app" --do-stuff --with "some file"`. See `lib.escapeShellArgs`.
A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to `bash`.
- `profile`
Optional script for `/etc/profile` within the sandbox.
You can create a simple environment using a `shell.nix` like this:
One can create a simple environment using a `shell.nix` like that:
```nix
{ pkgs ? import <nixpkgs> {} }:
(pkgs.buildFHSEnv {
name = "simple-x11-env";
targetPkgs = pkgs: (with pkgs; [
udev
alsa-lib
]) ++ (with pkgs.xorg; [
libX11
libXcursor
libXrandr
]);
multiPkgs = pkgs: (with pkgs; [
udev
alsa-lib
]);
targetPkgs = pkgs: (with pkgs;
[ udev
alsa-lib
]) ++ (with pkgs.xorg;
[ libX11
libXcursor
libXrandr
]);
multiPkgs = pkgs: (with pkgs;
[ udev
alsa-lib
]);
runScript = "bash";
}).env
```
Running `nix-shell` on it would drop you into a shell inside an FHS env where those libraries and binaries are available in FHS-compliant paths. Applications that expect an FHS structure (i.e. proprietary binaries) can run inside this environment without modification.
You can build a wrapper by running your binary in `runScript`, e.g. `./bin/start.sh`. Relative paths work as expected.
Running `nix-shell` would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change `runScript` to the application path, e.g. `./bin/start.sh` -- relative paths are supported.
Additionally, the FHS builder links all relocated gsettings-schemas (the glib setup-hook moves them to `share/gsettings-schemas/${name}/glib-2.0/schemas`) to their standard FHS location. This means you don't need to wrap binaries with `wrapGAppsHook`.

View File

@@ -164,26 +164,6 @@ tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
};
```
## `runNixOSTest` {#tester-runNixOSTest}
A helper function that behaves exactly like the NixOS `runTest`, except it also assigns this Nixpkgs package set as the `pkgs` of the test and makes the `nixpkgs.*` options read-only.
If your test is part of the Nixpkgs repository, or if you need a more general entrypoint, see ["Calling a test" in the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-calling-nixos-tests).
Example:
```nix
pkgs.testers.runNixOSTest ({ lib, ... }: {
name = "hello";
nodes.machine = { pkgs, ... }: {
environment.systemPackages = [ pkgs.hello ];
};
testScript = ''
machine.succeed("hello")
'';
})
```
## `nixosTest` {#tester-nixosTest}
Run a NixOS VM network test using this evaluation of Nixpkgs.

View File

@@ -20,10 +20,6 @@ in pkgs.stdenv.mkDerivation {
ln -s ${doc-support} ./doc-support/result
'';
preBuild = ''
make -j$NIX_BUILD_CORES render-md
'';
installPhase = ''
dest="$out/share/doc/nixpkgs"
mkdir -p "$(dirname "$dest")"

View File

@@ -45,10 +45,7 @@ let
# NB: This file describes the Nixpkgs manual, which happens to use module
# docs infra originally developed for NixOS.
optionsDoc = pkgs.nixosOptionsDoc {
inherit (pkgs.lib.evalModules {
modules = [ ../../pkgs/top-level/config.nix ];
class = "nixpkgsConfig";
}) options;
inherit (pkgs.lib.evalModules { modules = [ ../../pkgs/top-level/config.nix ]; }) options;
documentType = "none";
transformOptions = opt:
opt // {

View File

@@ -8,7 +8,7 @@ A package set is available for each CUDA version, so for example
`cudaPackages_11_6`. Within each set is a matching version of the above listed
packages. Additionally, other versions of the packages that are packaged and
compatible are available as well. For example, there can be a
`cudaPackages.cudnn_8_3` package.
`cudaPackages.cudnn_8_3_2` package.
To use one or more CUDA packages in an expression, give the expression a `cudaPackages` parameter, and in case CUDA is optional
```nix
@@ -27,8 +27,8 @@ package set to make it the default. This guarantees you get a consistent package
set.
```nix
mypkg = let
cudaPackages = cudaPackages_11_5.overrideScope' (final: prev: {
cudnn = prev.cudnn_8_3;
cudaPackages = cudaPackages_11_5.overrideScope' (final: prev {
cudnn = prev.cudnn_8_3_2;
}});
in callPackage { inherit cudaPackages; };
```

View File

@@ -1,65 +0,0 @@
# Dart {#sec-language-dart}
## Dart applications {#ssec-dart-applications}
The function `buildDartApplication` builds Dart applications managed with pub.
It fetches its Dart dependencies automatically through `fetchDartDeps`, and (through a series of hooks) builds and installs the executables specified in the pubspec file. The hooks can be used in other derivations, if needed. The phases can also be overridden to do something different from installing binaries.
If you are packaging a Flutter desktop application, use [`buildFlutterApplication`](#ssec-dart-flutter) instead.
`vendorHash`: is the hash of the output of the dependency fetcher derivation. To obtain it, simply set it to `lib.fakeHash` (or omit it) and run the build ([more details here](#sec-source-hashes)).
If the upstream source is missing a `pubspec.lock` file, you'll have to vendor one and specify it using `pubspecLockFile`. If it is needed, one will be generated for you and printed when attempting to build the derivation.
The `dart` commands run can be overridden through `pubGetScript` and `dartCompileCommand`, you can also add flags using `dartCompileFlags` or `dartJitFlags`.
Dart supports multiple [outputs types](https://dart.dev/tools/dart-compile#types-of-output), you can choose between them using `dartOutputType` (defaults to `exe`). If you want to override the binaries path or the source path they come from, you can use `dartEntryPoints`. Outputs that require a runtime will automatically be wrapped with the relevant runtime (`dartaotruntime` for `aot-snapshot`, `dart run` for `jit-snapshot` and `kernel`, `node` for `js`), this can be overridden through `dartRuntimeCommand`.
```nix
{ buildDartApplication, fetchFromGitHub }:
buildDartApplication rec {
pname = "dart-sass";
version = "1.62.1";
src = fetchFromGitHub {
owner = "sass";
repo = pname;
rev = version;
hash = "sha256-U6enz8yJcc4Wf8m54eYIAnVg/jsGi247Wy8lp1r1wg4=";
};
pubspecLockFile = ./pubspec.lock;
vendorHash = "sha256-Atm7zfnDambN/BmmUf4BG0yUz/y6xWzf0reDw3Ad41s=";
}
```
## Flutter applications {#ssec-dart-flutter}
The function `buildFlutterApplication` builds Flutter applications.
The deps.json file must always be provided when packaging in Nixpkgs. It will be generated and printed if the derivation is attempted to be built without one. Alternatively, `autoDepsList` may be set to `true` when outside of Nixpkgs, as it relies on import-from-derivation.
A `pubspec.lock` file must be available. See the [Dart documentation](#ssec-dart-applications) for more details.
```nix
{ flutter, fetchFromGitHub }:
flutter.buildFlutterApplication {
pname = "firmware-updater";
version = "unstable-2023-04-30";
src = fetchFromGitHub {
owner = "canonical";
repo = "firmware-updater";
rev = "6e7dbdb64e344633ea62874b54ff3990bd3b8440";
sha256 = "sha256-s5mwtr5MSPqLMN+k851+pFIFFPa0N1hqz97ys050tFA=";
fetchSubmodules = true;
};
pubspecLockFile = ./pubspec.lock;
depsListFile = ./deps.json;
vendorHash = "sha256-cdMO+tr6kYiN5xKXa+uTMAcFf2C75F3wVPrn21G4QPQ=";
}
```

View File

@@ -307,12 +307,12 @@ $ nix-env --install --attr haskellPackages.dhall-nixpkgs
$ nix-env --install --attr nix-prefetch-git # Used by dhall-to-nixpkgs
$ dhall-to-nixpkgs github https://github.com/Gabriella439/dhall-semver.git
$ dhall-to-nixpkgs github https://github.com/Gabriel439/dhall-semver.git
{ buildDhallGitHubPackage, Prelude }:
buildDhallGitHubPackage {
name = "dhall-semver";
githubBase = "github.com";
owner = "Gabriella439";
owner = "Gabriel439";
repo = "dhall-semver";
rev = "2d44ae605302ce5dc6c657a1216887fbb96392a4";
fetchSubmodules = false;

View File

@@ -19,7 +19,7 @@ In the following is an example expression using `buildGoModule`, the following a
To avoid updating this field when dependencies change, run `go mod vendor` in your source repo and set `vendorHash = null;`
To obtain the actual hash, set `vendorHash = lib.fakeSha256;` and run the build ([more details here](#sec-source-hashes)).
- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform-dependent `vendorHash` checksums.
- `proxyVendor`: Fetches (go mod download) and proxies the vendor directory. This is useful if your code depends on c code and go mod tidy does not include the needed sources to build or if any dependency has case-insensitive conflicts which will produce platform dependant `vendorHash` checksums.
- `modPostBuild`: Shell commands to run after the build of the go-modules executes `go mod vendor`, and before calculating fixed output derivation's `vendorHash` (or `vendorSha256`). Note that if you change this attribute, you need to update `vendorHash` (or `vendorSha256`) attribute.
```nix

View File

@@ -276,15 +276,6 @@ Defaults to `true`.
: Whether to generate an index for interactive navigation of the HTML documentation.
Defaults to `true` if supported.
`doInstallIntermediates`
: Whether to install intermediate build products (files written to `dist/build`
by GHC during the build process). With `enableSeparateIntermediatesOutput`,
these files are instead installed to [a separate `intermediates`
output.][multiple-outputs] The output can then be passed into a future build of
the same package with the `previousIntermediates` argument to support
incremental builds. See [“Incremental builds”](#haskell-incremental-builds) for
more information. Defaults to `false`.
`enableLibraryProfiling`
: Whether to enable [profiling][profiling] for libraries contained in the
package. Enabled by default if supported.
@@ -380,12 +371,6 @@ Defaults to `false`.
: Whether to install documentation to a separate `doc` output.
Is automatically enabled if `doHaddock` is `true`.
`enableSeparateIntermediatesOutput`
: When `doInstallIntermediates` is true, whether to install intermediate build
products to a separate `intermediates` output. See [“Incremental
builds”](#haskell-incremental-builds) for more information. Defaults to
`false`.
`allowInconsistentDependencies`
: If enabled, allow multiple versions of the same Haskell package in the
dependency tree at configure time. Often in such a situation compilation would
@@ -396,11 +381,6 @@ later fail because of type mismatches. Defaults to `false`.
when loading the library in the REPL, but requires extra build time and
disk space. Defaults to `false`.
`previousIntermediates`
: If non-null, intermediate build artifacts are copied from this input to
`dist/build` before performing compiling. See [“Incremental
builds”](#haskell-incremental-builds) for more information. Defaults to `null`.
`buildTarget`
: Name of the executable or library to build and install.
If unset, all available targets are built and installed.
@@ -516,54 +496,6 @@ the [Meta-attributes section](#chap-meta) for their documentation.
* `broken`
* `hydraPlatforms`
### Incremental builds {#haskell-incremental-builds}
`haskellPackages.mkDerivation` supports incremental builds for GHC 9.4 and
newer with the `doInstallIntermediates`, `enableSeparateIntermediatesOutput`,
and `previousIntermediates` arguments.
The basic idea is to first perform a full build of the package in question,
save its intermediate build products for later, and then copy those build
products into the build directory of an incremental build performed later.
Then, GHC will use those build artifacts to avoid recompiling unchanged
modules.
For more detail on how to store and use incremental build products, see
[Gabriella Gonzalez blog post “Nixpkgs support for incremental Haskell
builds”.][incremental-builds] motivation behind this feature.
An incremental build for [the `turtle` package][turtle] can be performed like
so:
```nix
let
pkgs = import <nixpkgs> {};
inherit (pkgs) haskell;
inherit (haskell.lib.compose) overrideCabal;
# Incremental builds work with GHC >=9.4.
turtle = haskell.packages.ghc944.turtle;
# This will do a full build of `turtle`, while writing the intermediate build products
# (compiled modules, etc.) to the `intermediates` output.
turtle-full-build-with-incremental-output = overrideCabal (drv: {
doInstallIntermediates = true;
enableSeparateIntermediatesOutput = true;
}) turtle;
# This will do an incremental build of `turtle` by copying the previously
# compiled modules and intermediate build products into the source tree
# before running the build.
#
# GHC will then naturally pick up and reuse these products, making this build
# complete much more quickly than the previous one.
turtle-incremental-build = overrideCabal (drv: {
previousIntermediates = turtle-full-build-with-incremental-output.intermediates;
}) turtle;
in
turtle-incremental-build
```
## Development environments {#haskell-development-environments}
In addition to building and installing Haskell software, nixpkgs can also
@@ -1151,11 +1083,8 @@ on the issue linked above.
[haskell.nix]: https://input-output-hk.github.io/haskell.nix/index.html
[HLS user guide]: https://haskell-language-server.readthedocs.io/en/latest/configuration.html#configuring-your-editor
[hoogle]: https://wiki.haskell.org/Hoogle
[incremental-builds]: https://www.haskellforall.com/2022/12/nixpkgs-support-for-incremental-haskell.html
[jailbreak-cabal]: https://github.com/NixOS/jailbreak-cabal/
[multiple-outputs]: https://nixos.org/manual/nixpkgs/stable/#chap-multiple-output
[optparse-applicative-completions]: https://github.com/pcapriotti/optparse-applicative/blob/7726b63796aa5d0df82e926d467f039b78ca09e2/README.md#bash-zsh-and-fish-completions
[profiling-detail]: https://cabal.readthedocs.io/en/latest/cabal-project.html#cfg-field-profiling-detail
[profiling]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html
[search.nixos.org]: https://search.nixos.org
[turtle]: https://hackage.haskell.org/package/turtle

View File

@@ -14,7 +14,6 @@
<xi:include href="crystal.section.xml" />
<xi:include href="cuda.section.xml" />
<xi:include href="cuelang.section.xml" />
<xi:include href="dart.section.xml" />
<xi:include href="dhall.section.xml" />
<xi:include href="dotnet.section.xml" />
<xi:include href="emscripten.section.xml" />

View File

@@ -229,7 +229,7 @@ See `node2nix` [docs](https://github.com/svanderburg/node2nix) for more info.
#### Pitfalls {#javascript-node2nix-pitfalls}
- If upstream package.json does not have a "version" attribute, `node2nix` will crash. You will need to add it like shown in [the package.json section](#javascript-upstream-package-json).
- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs_16`.
- `node2nix` has some [bugs](https://github.com/svanderburg/node2nix/issues/238) related to working with lock files from NPM distributed with `nodejs-16_x`.
- `node2nix` does not like missing packages from NPM. If you see something like `Cannot resolve version: vue-loader-v16@undefined` then you might want to try another tool. The package might have been pulled off of NPM.
### yarn2nix {#javascript-yarn2nix}

View File

@@ -38,12 +38,12 @@ Here is a simple package example.
- It uses the `fetchFromGitHub` fetcher to get its source.
- It also accept `duneVersion` parameter (valid value are `"1"`, `"2"`, and
`"3"`). The recommended practice it to set only if you don't want the default
value and/or it depends on something else like package version. You might see
a not-supported argument `useDune2`. The behavior was `useDune2 = true;` =>
`duneVersion = "2";` and `useDune2 = false;` => `duneVersion = "1";`. It was
used at the time when dune3 didn't existed.
- `duneVersion = "2"` ensures that Dune version 2 is used for the
build (this is the default; valid values are `"1"`, `"2"`, and `"3"`);
note that there is also a legacy `useDune2` boolean attribute:
set to `false` it corresponds to `duneVersion = "1"`; set to `true` it
corresponds to `duneVersion = "2"`. If both arguments (`duneVersion` and
`useDune2`) are given, the second one (`useDune2`) is silently ignored.
- It sets the optional `doCheck` attribute such that tests will be run with
`dune runtest -p angstrom` after the build (`dune build -p angstrom`) is
@@ -71,6 +71,7 @@ Here is a simple package example.
buildDunePackage rec {
pname = "angstrom";
version = "0.15.0";
duneVersion = "2";
minimalOCamlVersion = "4.04";
@@ -103,6 +104,8 @@ buildDunePackage rec {
pname = "wtf8";
version = "1.0.2";
useDune2 = true;
minimalOCamlVersion = "4.02";
src = fetchurl {

View File

@@ -118,7 +118,7 @@ ImageExifTool = buildPerlPackage {
hash = "sha256-vOhB/FwQMC8PPvdnjDvxRpU6jAZcC6GMQfc0AH4uwKg=";
};
nativeBuildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
buildInputs = lib.optional stdenv.isDarwin shortenPerlShebang;
postInstall = lib.optionalString stdenv.isDarwin ''
shortenPerlShebang $out/bin/exiftool
'';

View File

@@ -10,7 +10,7 @@ Several versions of the Python interpreter are available on Nix, as well as a
high amount of packages. The attribute `python3` refers to the default
interpreter, which is currently CPython 3.10. The attribute `python` refers to
CPython 2.7 for backwards-compatibility. It is also possible to refer to
specific versions, e.g. `python311` refers to CPython 3.11, and `pypy` refers to
specific versions, e.g. `python39` refers to CPython 3.9, and `pypy` refers to
the default PyPy interpreter.
Python is used a lot, and in different ways. This affects also how it is
@@ -26,10 +26,10 @@ however, are in separate sets, with one set per interpreter version.
The interpreters have several common attributes. One of these attributes is
`pkgs`, which is a package set of Python libraries for this specific
interpreter. E.g., the `toolz` package corresponding to the default interpreter
is `python.pkgs.toolz`, and the CPython 3.11 version is `python311.pkgs.toolz`.
is `python.pkgs.toolz`, and the CPython 3.9 version is `python39.pkgs.toolz`.
The main package set contains aliases to these package sets, e.g.
`pythonPackages` refers to `python.pkgs` and `python311Packages` to
`python311.pkgs`.
`pythonPackages` refers to `python.pkgs` and `python39Packages` to
`python39.pkgs`.
#### Installing Python and packages {#installing-python-and-packages}
@@ -54,7 +54,7 @@ with `python.buildEnv` or `python.withPackages` where the interpreter and other
executables are wrapped to be able to find each other and all of the modules.
In the following examples we will start by creating a simple, ad-hoc environment
with a nix-shell that has `numpy` and `toolz` in Python 3.11; then we will create
with a nix-shell that has `numpy` and `toolz` in Python 3.9; then we will create
a re-usable environment in a single-file Python script; then we will create a
full Python environment for development with this same environment.
@@ -70,10 +70,10 @@ temporary shell session with a Python and a *precise* list of packages (plus
their runtime dependencies), with no other Python packages in the Python
interpreter's scope.
To create a Python 3.11 session with `numpy` and `toolz` available, run:
To create a Python 3.9 session with `numpy` and `toolz` available, run:
```sh
$ nix-shell -p 'python311.withPackages(ps: with ps; [ numpy toolz ])'
$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy toolz ])'
```
By default `nix-shell` will start a `bash` session with this interpreter in our
@@ -81,7 +81,8 @@ By default `nix-shell` will start a `bash` session with this interpreter in our
```Python console
[nix-shell:~/src/nixpkgs]$ python3
Python 3.11.3 (main, Apr 4 2023, 22:36:41) [GCC 12.2.0] on linux
Python 3.9.12 (main, Mar 23 2022, 21:36:19)
[GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy; import toolz
```
@@ -101,12 +102,16 @@ will still get 1 wrapped Python interpreter. We can start the interpreter
directly like so:
```sh
$ nix-shell -p "python311.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
$ nix-shell -p "python39.withPackages (ps: with ps; [ numpy toolz requests ])" --run python3
this derivation will be built:
/nix/store/r19yf5qgfiakqlhkgjahbg3zg79549n4-python3-3.11.2-env.drv
building '/nix/store/r19yf5qgfiakqlhkgjahbg3zg79549n4-python3-3.11.2-env.drv'...
created 273 symlinks in user environment
Python 3.11.2 (main, Feb 7 2023, 13:52:42) [GCC 12.2.0] on linux
/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv
this path will be fetched (0.09 MiB download, 0.41 MiB unpacked):
/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2
copying path '/nix/store/5gaiacnzi096b6prc6aa1pwrhncmhc8b-python3.9-toolz-0.11.2' from 'https://cache.nixos.org'...
building '/nix/store/mpn7k6bkjl41fm51342rafaqfsl10qs4-python3-3.9.12-env.drv'...
created 279 symlinks in user environment
Python 3.9.12 (main, Mar 23 2022, 21:36:19)
[GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import requests
>>>
@@ -145,7 +150,7 @@ Executing this script requires a `python3` that has `numpy`. Using what we learn
in the previous section, we could startup a shell and just run it like so:
```ShellSession
$ nix-shell -p 'python311.withPackages (ps: with ps; [ numpy ])' --run 'python3 foo.py'
$ nix-shell -p 'python39.withPackages(ps: with ps; [ numpy ])' --run 'python3 foo.py'
The dot product of [1 2] and [3 4] is: 11
```
@@ -185,17 +190,17 @@ can make it fully reproducible by pinning the `nixpkgs` import:
```python
#!/usr/bin/env nix-shell
#!nix-shell -i python3 -p "python3.withPackages (ps: [ ps.numpy ])"
#!nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/e51209796c4262bfb8908e3d6d72302fe4e96f5f.tar.gz
#!nix-shell -i python3 -p "python3.withPackages(ps: [ ps.numpy ])"
#!nix-shell -I nixpkgs=https://github.com/NixOS/nixpkgs/archive/d373d80b1207d52621961b16aa4a3438e4f98167.tar.gz
import numpy as np
a = np.array([1,2])
b = np.array([3,4])
print(f"The dot product of {a} and {b} is: {np.dot(a, b)}")
```
This will execute with the exact same versions of Python 3.10, numpy, and system
This will execute with the exact same versions of Python 3.8, numpy, and system
dependencies a year from now as it does today, because it will always use
exactly git commit `e51209796c4262bfb8908e3d6d72302fe4e96f5f` of Nixpkgs for all
exactly git commit `d373d80b1207d52621961b16aa4a3438e4f98167` of Nixpkgs for all
of the package versions.
This is also a great way to ensure the script executes identically on different
@@ -208,15 +213,12 @@ create a single script with Python dependencies, but in the course of normal
development we're usually working in an entire package repository.
As explained in the Nix manual, `nix-shell` can also load an expression from a
`.nix` file. Say we want to have Python 3.11, `numpy` and `toolz`, like before,
`.nix` file. Say we want to have Python 3.9, `numpy` and `toolz`, like before,
in an environment. We can add a `shell.nix` file describing our dependencies:
```nix
with import <nixpkgs> {};
(python311.withPackages (ps: with ps; [
numpy
toolz
])).env
(python39.withPackages (ps: [ps.numpy ps.toolz])).env
```
And then at the command line, just typing `nix-shell` produces the same
@@ -230,7 +232,7 @@ What's happening here?
imports the `<nixpkgs>` function, `{}` calls it and the `with` statement
brings all attributes of `nixpkgs` in the local scope. These attributes form
the main package set.
2. Then we create a Python 3.11 environment with the `withPackages` function, as before.
2. Then we create a Python 3.9 environment with the `withPackages` function, as before.
3. The `withPackages` function expects us to provide a function as an argument
that takes the set of all Python packages and returns a list of packages to
include in the environment. Here, we select the packages `numpy` and `toolz`
@@ -241,7 +243,7 @@ To combine this with `mkShell` you can:
```nix
with import <nixpkgs> {};
let
pythonEnv = python311.withPackages (ps: [
pythonEnv = python39.withPackages (ps: [
ps.numpy
ps.toolz
]);
@@ -325,7 +327,7 @@ on NixOS.
{ # ...
environment.systemPackages = with pkgs; [
(python310.withPackages(ps: with ps; [ numpy toolz ]))
(python38.withPackages(ps: with ps; [ numpy toolz ]))
];
}
```
@@ -346,32 +348,20 @@ building Python libraries is `buildPythonPackage`. Let's see how we can build th
`toolz` package.
```nix
{ lib
, buildPythonPackage
, fetchPypi
}:
{ lib, buildPythonPackage, fetchPypi }:
buildPythonPackage rec {
pname = "toolz";
version = "0.10.0";
format = "setuptools";
src = fetchPypi {
inherit pname version;
hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
};
# has no tests
doCheck = false;
pythonImportsCheck = [
"toolz.itertoolz"
"toolz.functoolz"
"toolz.dicttoolz"
];
meta = with lib; {
changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
homepage = "https://github.com/pytoolz/toolz";
description = "List processing tools and functional utilities";
license = licenses.bsd3;
@@ -386,14 +376,13 @@ arguments is the name of the package, which consists of a basename (generally
following the name on PyPi) and a version. Another argument, `src` specifies the
source, which in this case is fetched from PyPI using the helper function
`fetchPypi`. The argument `doCheck` is used to set whether tests should be run
when building the package. Since there are no tests, we rely on `pythonImportsCheck`
to test whether the package can be imported. Furthermore, we specify some meta
when building the package. Furthermore, we specify some (optional) meta
information. The output of the function is a derivation.
An expression for `toolz` can be found in the Nixpkgs repository. As explained
in the introduction of this Python section, a derivation of `toolz` is available
for each interpreter version, e.g. `python311.pkgs.toolz` refers to the `toolz`
derivation corresponding to the CPython 3.11 interpreter.
for each interpreter version, e.g. `python39.pkgs.toolz` refers to the `toolz`
derivation corresponding to the CPython 3.9 interpreter.
The above example works when you're directly working on
`pkgs/top-level/python-packages.nix` in the Nixpkgs repository. Often though,
@@ -406,35 +395,29 @@ and adds it along with a `numpy` package to a Python environment.
with import <nixpkgs> {};
( let
my_toolz = python311.pkgs.buildPythonPackage rec {
my_toolz = python39.pkgs.buildPythonPackage rec {
pname = "toolz";
version = "0.10.0";
format = "setuptools";
src = fetchPypi {
src = python39.pkgs.fetchPypi {
inherit pname version;
hash = "sha256-CP3V73yWSArRHBLUct4hrNMjWZlvaaUlkpm1QP66RWA=";
};
# has no tests
doCheck = false;
meta = {
homepage = "https://github.com/pytoolz/toolz/";
description = "List processing tools and functional utilities";
# [...]
};
};
in python311.withPackages (ps: with ps; [
numpy
my_toolz
])
in python38.withPackages (ps: [ps.numpy my_toolz])
).env
```
Executing `nix-shell` will result in an environment in which you can use
Python 3.11 and the `toolz` package. As you can see we had to explicitly mention
Python 3.9 and the `toolz` package. As you can see we had to explicitly mention
for which Python version we want to build a package.
So, what did we do here? Well, we took the Nix expression that we used earlier
@@ -459,39 +442,21 @@ The following example shows which arguments are given to `buildPythonPackage` in
order to build [`datashape`](https://github.com/blaze/datashape).
```nix
{ lib
, buildPythonPackage
, fetchPypi
# dependencies
, numpy, multipledispatch, python-dateutil
# tests
, pytest
}:
{ lib, buildPythonPackage, fetchPypi, numpy, multipledispatch, python-dateutil, pytest }:
buildPythonPackage rec {
pname = "datashape";
version = "0.4.7";
format = "setuptools";
src = fetchPypi {
inherit pname version;
hash = "sha256-FLLvdm1MllKrgTGC6Gb0k0deZeVYvtCCLji/B7uhong=";
};
propagatedBuildInputs = [
multipledispatch
numpy
python-dateutil
];
nativeCheckInputs = [
pytest
];
nativeCheckInputs = [ pytest ];
propagatedBuildInputs = [ numpy multipledispatch python-dateutil ];
meta = with lib; {
changelog = "https://github.com/blaze/datashape/releases/tag/${version}";
homepage = "https://github.com/ContinuumIO/datashape";
description = "A data description language";
license = licenses.bsd2;
@@ -501,9 +466,9 @@ buildPythonPackage rec {
```
We can see several runtime dependencies, `numpy`, `multipledispatch`, and
`python-dateutil`. Furthermore, we have `nativeCheckInputs` with `pytest`.
`pytest` is a test runner and is only used during the `checkPhase` and is
therefore not added to `propagatedBuildInputs`.
`python-dateutil`. Furthermore, we have one `nativeCheckInputs`, i.e. `pytest`. `pytest` is a
test runner and is only used during the `checkPhase` and is therefore not added
to `propagatedBuildInputs`.
In the previous case we had only dependencies on other Python packages to consider.
Occasionally you have also system libraries to consider. E.g., `lxml` provides
@@ -511,29 +476,20 @@ Python bindings to `libxml2` and `libxslt`. These libraries are only required
when building the bindings and are therefore added as `buildInputs`.
```nix
{ lib
, pkgs
, buildPythonPackage
, fetchPypi
}:
{ lib, pkgs, buildPythonPackage, fetchPypi }:
buildPythonPackage rec {
pname = "lxml";
version = "3.4.4";
format = "setuptools";
src = fetchPypi {
inherit pname version;
hash = "sha256-s9NiusRxFydHzaNRMjjxFcvWxfi45jGb9ql6eJJyQJk=";
};
buildInputs = [
pkgs.libxml2
pkgs.libxslt
];
buildInputs = [ pkgs.libxml2 pkgs.libxslt ];
meta = with lib; {
changelog = "https://github.com/lxml/lxml/releases/tag/lxml-${version}";
description = "Pythonic binding for the libxml2 and libxslt libraries";
homepage = "https://lxml.de";
license = licenses.bsd3;
@@ -553,47 +509,30 @@ The bindings don't expect to find each of them in a different folder, and
therefore we have to set `LDFLAGS` and `CFLAGS`.
```nix
{ lib
, pkgs
, buildPythonPackage
, fetchPypi
# dependencies
, numpy
, scipy
}:
{ lib, pkgs, buildPythonPackage, fetchPypi, numpy, scipy }:
buildPythonPackage rec {
pname = "pyFFTW";
version = "0.9.2";
format = "setuptools";
src = fetchPypi {
inherit pname version;
hash = "sha256-9ru2r6kwhUCaskiFoaPNuJCfCVoUL01J40byvRt4kHQ=";
};
buildInputs = [
pkgs.fftw
pkgs.fftwFloat
pkgs.fftwLongDouble
];
buildInputs = [ pkgs.fftw pkgs.fftwFloat pkgs.fftwLongDouble];
propagatedBuildInputs = [
numpy
scipy
];
propagatedBuildInputs = [ numpy scipy ];
# Tests cannot import pyfftw. pyfftw works fine though.
doCheck = false;
preConfigure = ''
export LDFLAGS="-L${pkgs.fftw.dev}/lib -L${pkgs.fftwFloat.out}/lib -L${pkgs.fftwLongDouble.out}/lib"
export CFLAGS="-I${pkgs.fftw.dev}/include -I${pkgs.fftwFloat.dev}/include -I${pkgs.fftwLongDouble.dev}/include"
'';
# Tests cannot import pyfftw. pyfftw works fine though.
doCheck = false;
meta = with lib; {
changelog = "https://github.com/pyFFTW/pyFFTW/releases/tag/v${version}";
description = "A pythonic wrapper around FFTW, the FFT library, presenting a unified interface for all the supported transforms";
homepage = "http://hgomersall.github.com/pyFFTW";
license = with licenses; [ bsd2 bsd3 ];
@@ -651,7 +590,7 @@ To filter tests using pytest, one can do the following:
checkPhase = ''
runHook preCheck
pytest tests/ --ignore=tests/integration -k 'not download and not update' --ignore=tests/test_failing.py
pytest tests/ --ignore=tests/integration -k 'not download and not update'
runHook postCheck
'';
@@ -679,15 +618,10 @@ when a package may need many items disabled to run the test suite.
Using the example above, the analogous `pytestCheckHook` usage would be:
```
nativeCheckInputs = [
pytestCheckHook
];
nativeCheckInputs = [ pytestCheckHook ];
# requires additional data
pytestFlagsArray = [
"tests/"
"--ignore=tests/integration"
];
pytestFlagsArray = [ "tests/" "--ignore=tests/integration" ];
disabledTests = [
# touches network
@@ -729,10 +663,7 @@ To help ensure the package still works, `pythonImportsCheck` can attempt to impo
the listed modules.
```
pythonImportsCheck = [
"requests"
"urllib"
];
pythonImportsCheck = [ "requests" "urllib" ];
```
roughly translates to:
@@ -773,16 +704,9 @@ pkg3>=1.0,<=2.0
we can do:
```
nativeBuildInputs = [
pythonRelaxDepsHook
];
pythonRelaxDeps = [
"pkg1"
"pkg3"
];
pythonRemoveDeps = [
"pkg2"
];
nativeBuildInputs = [ pythonRelaxDepsHook ];
pythonRelaxDeps = [ "pkg1" "pkg3" ];
pythonRemoveDeps = [ "pkg2" ];
```
which would result in the following `requirements.txt` file:
@@ -825,13 +749,9 @@ with the exception of `other` (see `format` in
`unittestCheckHook` is a hook which will substitute the setuptools `test` command for a `checkPhase` which runs `python -m unittest discover`:
```
nativeCheckInputs = [
unittestCheckHook
];
nativeCheckInputs = [ unittestCheckHook ];
unittestFlagsArray = [
"-s" "tests" "-v"
];
unittestFlagsArray = [ "-s" "tests" "-v" ];
```
#### Using sphinxHook {#using-sphinxhook}
@@ -896,7 +816,7 @@ If we create a `shell.nix` file which calls `buildPythonPackage`, and if `src`
is a local source, and if the local source has a `setup.py`, then development
mode is activated.
In the following example, we create a simple environment that has a Python 3.11
In the following example, we create a simple environment that has a Python 3.9
version of our package in it, as well as its dependencies and other packages we
like to have in the environment, all specified with `propagatedBuildInputs`.
Indeed, we can just add any package we like to have in our environment to
@@ -904,16 +824,12 @@ Indeed, we can just add any package we like to have in our environment to
```nix
with import <nixpkgs> {};
with python311Packages;
with python39Packages;
buildPythonPackage rec {
name = "mypackage";
src = ./path/to/package/source;
propagatedBuildInputs = [
pytest
numpy
pkgs.libsndfile
];
propagatedBuildInputs = [ pytest numpy pkgs.libsndfile ];
}
```
@@ -941,14 +857,11 @@ Let's split the package definition from the environment definition.
We first create a function that builds `toolz` in `~/path/to/toolz/release.nix`
```nix
{ lib
, buildPythonPackage
}:
{ lib, buildPythonPackage }:
buildPythonPackage rec {
pname = "toolz";
version = "0.10.0";
format = "setuptools";
src = fetchPypi {
inherit pname version;
@@ -956,7 +869,6 @@ buildPythonPackage rec {
};
meta = with lib; {
changelog = "https://github.com/pytoolz/toolz/releases/tag/${version}";
homepage = "https://github.com/pytoolz/toolz/";
description = "List processing tools and functional utilities";
license = licenses.bsd3;
@@ -973,13 +885,9 @@ with import <nixpkgs> {};
( let
toolz = callPackage /path/to/toolz/release.nix {
buildPythonPackage = python310
Packages.buildPythonPackage;
buildPythonPackage = python38Packages.buildPythonPackage;
};
in python310.withPackages (ps: [
ps.numpy
toolz
])
in python38.withPackages (ps: [ ps.numpy toolz ])
).env
```
@@ -987,17 +895,17 @@ Important to remember is that the Python version for which the package is made
depends on the `python` derivation that is passed to `buildPythonPackage`. Nix
tries to automatically pass arguments when possible, which is why generally you
don't explicitly define which `python` derivation should be used. In the above
example we use `buildPythonPackage` that is part of the set `python3Packages`,
and in this case the `python3` interpreter is automatically used.
example we use `buildPythonPackage` that is part of the set `python38Packages`,
and in this case the `python38` interpreter is automatically used.
## Reference {#reference}
### Interpreters {#interpreters}
Versions 2.7, 3.8, 3.9, 3.10 and 3.11 of the CPython interpreter are available
as respectively `python27`, python38`, `python39`, `python310` and `python311`.
Versions 2.7, 3.7, 3.8, 3.9 and 3.10 of the CPython interpreter are available
as respectively `python27`, `python37`, `python38`, `python39` and `python310`.
The aliases `python2` and `python3` correspond to respectively `python27` and
`python310`. The attribute `python` maps to `python2`. The PyPy interpreters
`python39`. The attribute `python` maps to `python2`. The PyPy interpreters
compatible with Python 2.7 and 3 are available as `pypy27` and `pypy3`, with
aliases `pypy2` mapping to `pypy27` and `pypy` mapping to `pypy2`. The Nix
expressions for the interpreters can be found in
@@ -1020,7 +928,7 @@ Each interpreter has the following attributes:
- `buildEnv`. Function to build python interpreter environments with extra packages bundled together. See section *python.buildEnv function* for usage and documentation.
- `withPackages`. Simpler interface to `buildEnv`. See section *python.withPackages function* for usage and documentation.
- `sitePackages`. Alias for `lib/${libPrefix}/site-packages`.
- `executable`. Name of the interpreter executable, e.g. `python3.10`.
- `executable`. Name of the interpreter executable, e.g. `python3.8`.
- `pkgs`. Set of Python packages for that specific interpreter. The package set can be modified by overriding the interpreter and passing `packageOverrides`.
### Optimizations {#optimizations}
@@ -1060,7 +968,7 @@ attribute set is created for each available Python interpreter. The available
sets are
* `pkgs.python27Packages`
* `pkgs.python3Packages`
* `pkgs.python37Packages`
* `pkgs.python38Packages`
* `pkgs.python39Packages`
* `pkgs.python310Packages`
@@ -1070,7 +978,7 @@ sets are
and the aliases
* `pkgs.python2Packages` pointing to `pkgs.python27Packages`
* `pkgs.python3Packages` pointing to `pkgs.python310Packages`
* `pkgs.python3Packages` pointing to `pkgs.python39Packages`
* `pkgs.pythonPackages` pointing to `pkgs.python2Packages`
#### `buildPythonPackage` function {#buildpythonpackage-function}
@@ -1082,28 +990,11 @@ using setup hooks.
The following is an example:
```nix
{ lib
, buildPythonPackage
, fetchPypi
# build-system
, setuptools-scm
# dependencies
, attrs
, pluggy
, py
, setuptools
, six
# tests
, hypothesis
}:
{ lib, buildPythonPackage, fetchPypi, hypothesis, setuptools-scm, attrs, py, setuptools, six, pluggy }:
buildPythonPackage rec {
pname = "pytest";
version = "3.3.1";
format = "setuptools";
src = fetchPypi {
inherit pname version;
@@ -1115,28 +1006,13 @@ buildPythonPackage rec {
rm testing/test_argcomplete.py
'';
nativeBuildInputs = [
setuptools-scm
];
propagatedBuildInputs = [
attrs
py
setuptools
six
pluggy
];
nativeCheckInputs = [
hypothesis
];
nativeCheckInputs = [ hypothesis ];
nativeBuildInputs = [ setuptools-scm ];
propagatedBuildInputs = [ attrs py setuptools six pluggy ];
meta = with lib; {
changelog = "https://github.com/pytest-dev/pytest/releases/tag/${version}";
description = "Framework for writing tests";
homepage = "https://github.com/pytest-dev/pytest";
license = licenses.mit;
maintainers = with maintainers; [ domenkozar lovek323 madjar lsix ];
description = "Framework for writing tests";
};
}
```
@@ -1229,7 +1105,7 @@ with import <nixpkgs> {};
packageOverrides = self: super: {
pandas = super.pandas.overridePythonAttrs(old: rec {
version = "0.19.1";
src = fetchPypi {
src = super.fetchPypi {
pname = "pandas";
inherit version;
hash = "sha256-JQn+rtpy/OA2deLszSKEuxyttqBzcAil50H+JDHUdCE=";
@@ -1238,7 +1114,7 @@ with import <nixpkgs> {};
};
in pkgs.python3.override {inherit packageOverrides; self = python;};
in python.withPackages(ps: [ ps.blaze ])).env
in python.withPackages(ps: [ps.blaze])).env
```
#### Optional extra dependencies {#python-optional-dependencies}
@@ -1284,25 +1160,18 @@ called with `callPackage` and passed `python` or `pythonPackages` (possibly
specifying an interpreter version), like this:
```nix
{ lib
, python3
, fetchPypi
}:
{ lib, python3 }:
python3.pkgs.buildPythonApplication rec {
pname = "luigi";
version = "2.7.9";
format = "setuptools";
src = fetchPypi {
src = python3.pkgs.fetchPypi {
inherit pname version;
hash = "sha256-Pe229rT0aHwA98s+nTHQMEFKZPo/yw6sot8MivFDvAw=";
};
propagatedBuildInputs = with python3.pkgs; [
tornado
python-daemon
];
propagatedBuildInputs = with python3.pkgs; [ tornado python-daemon ];
meta = with lib; {
...
@@ -1384,10 +1253,7 @@ running `nix-shell` with the following `shell.nix`
with import <nixpkgs> {};
(python3.buildEnv.override {
extraLibs = with python3Packages; [
numpy
requests
];
extraLibs = with python3Packages; [ numpy requests ];
}).env
```
@@ -1413,7 +1279,7 @@ example for the Pyramid Web Framework environment can be written like this:
```nix
with import <nixpkgs> {};
python.withPackages (ps: [ ps.pyramid ])
python.withPackages (ps: [ps.pyramid])
```
`withPackages` passes the correct package set for the specific interpreter
@@ -1423,7 +1289,7 @@ version as an argument to the function. In the above example, `ps` equals
```nix
with import <nixpkgs> {};
python3.withPackages (ps: [ ps.pyramid ])
python3.withPackages (ps: [ps.pyramid])
```
Now, `ps` is set to `python3Packages`, matching the version of the interpreter.
@@ -1435,10 +1301,7 @@ thus be also written like this:
```nix
with import <nixpkgs> {};
(python3.withPackages (ps: with ps; [
numpy
requests
])).env
(python38.withPackages (ps: [ps.numpy ps.requests])).env
```
In contrast to `python.buildEnv`, `python.withPackages` does not support the
@@ -1514,6 +1377,10 @@ Note: There is a boolean value `lib.inNixShell` set to `true` if nix-shell is in
Packages inside nixpkgs are written by hand. However many tools exist in
community to help save time. No tool is preferred at the moment.
- [pypi2nix](https://github.com/nix-community/pypi2nix): Generate Nix
expressions for your Python project. Note that [sharing derivations from
pypi2nix with nixpkgs is possible but not
encouraged](https://github.com/nix-community/pypi2nix/issues/222#issuecomment-443497376).
- [nixpkgs-pytools](https://github.com/nix-community/nixpkgs-pytools)
- [poetry2nix](https://github.com/nix-community/poetry2nix)
@@ -1526,7 +1393,7 @@ has security implications and is relevant for those using Python in a
When the environment variable `DETERMINISTIC_BUILD` is set, all bytecode will
have timestamp 1. The `buildPythonPackage` function sets `DETERMINISTIC_BUILD=1`
and [PYTHONHASHSEED=0](https://docs.python.org/3.11/using/cmdline.html#envvar-PYTHONHASHSEED).
and [PYTHONHASHSEED=0](https://docs.python.org/3.8/using/cmdline.html#envvar-PYTHONHASHSEED).
Both are also exported in `nix-shell`.
### Automatic tests {#automatic-tests}
@@ -1541,27 +1408,22 @@ example of such a situation is when `py.test` is used.
#### Common issues {#common-issues}
* Non-working tests can often be deselected. By default `buildPythonPackage`
runs `python setup.py test`. which is deprecated. Most Python modules however
do follow the standard test protocol where the pytest runner can be used
instead. `pytest` supports the `-k` and `--ignore` parameters to ignore test
methods or classes as well as whole files. For `pytestCheckHook` these are
conveniently exposed as `disabledTests` and `disabledTestPaths` respectively.
runs `python setup.py test`. Most Python modules follows the standard test
protocol where the pytest runner can be used instead. `py.test` supports a
`-k` parameter to ignore test methods or classes:
```nix
buildPythonPackage {
# ...
nativeCheckInputs = [
pytestCheckHook
];
# assumes the tests are located in tests
nativeCheckInputs = [ pytest ];
checkPhase = ''
runHook preCheck
disabledTests = [
"function_name"
"other_function"
];
py.test -k 'not function_name and not other_function' tests
disabledTestPaths = [
"this/file.py"
];
runHook postCheck
'';
}
```
@@ -1589,13 +1451,9 @@ with import <nixpkgs> {};
packageOverrides = self: super: {
pandas = super.pandas.overridePythonAttrs(old: {name="foo";});
};
in pkgs.python310.override {
inherit packageOverrides;
};
in pkgs.python38.override {inherit packageOverrides;};
in python.withPackages (ps: [
ps.pandas
])).env
in python.withPackages(ps: [ps.pandas])).env
```
Using `nix-build` on this expression will build an environment that contains the
@@ -1615,11 +1473,7 @@ with import <nixpkgs> {};
packageOverrides = self: super: {
scipy = super.scipy_0_17;
};
in (pkgs.python310.override {
inherit packageOverrides;
}).withPackages (ps: [
ps.blaze
])
in (pkgs.python38.override {inherit packageOverrides;}).withPackages (ps: [ps.blaze])
).env
```
@@ -1633,11 +1487,11 @@ If you want the whole of Nixpkgs to use your modifications, then you can use
let
pkgs = import <nixpkgs> {};
newpkgs = import pkgs.path { overlays = [ (self: super: {
python310 = let
python38 = let
packageOverrides = python-self: python-super: {
numpy = python-super.numpy_1_18;
};
in super.python310.override {inherit packageOverrides;};
in super.python38.override {inherit packageOverrides;};
} ) ]; };
in newpkgs.inkscape
```

View File

@@ -535,9 +535,7 @@ directory of the `tokenizers` project's source archive, we use
```nix
{ fetchFromGitHub
, buildPythonPackage
, cargo
, rustPlatform
, rustc
, setuptools-rust
}:
@@ -560,12 +558,11 @@ buildPythonPackage rec {
sourceRoot = "source/bindings/python";
nativeBuildInputs = [
cargo
rustPlatform.cargoSetupHook
rustc
setuptools-rust
];
nativeBuildInputs = [ setuptools-rust ] ++ (with rustPlatform; [
cargoSetupHook
rust.cargo
rust.rustc
]);
# ...
}

View File

@@ -12,11 +12,7 @@
<xi:include href="using/configuration.chapter.xml" />
<xi:include href="using/overlays.chapter.xml" />
<xi:include href="using/overrides.chapter.xml" />
</part>
<part>
<title>Nixpkgs <code>lib</code></title>
<xi:include href="functions.xml" />
<xi:include href="module-system/module-system.chapter.xml" />
</part>
<part xml:id="part-stdenv">
<title>Standard environment</title>

View File

@@ -1,105 +0,0 @@
# Module System {#module-system}
## Introduction {#module-system-introduction}
The module system is a language for handling configuration, implemented as a Nix library.
Compared to plain Nix, it adds documentation, type checking and composition or extensibility.
::: {.note}
This chapter is new and not complete yet. For a gentle introduction to the module system, in the context of NixOS, see [Writing NixOS Modules](https://nixos.org/manual/nixos/unstable/index.html#sec-writing-modules) in the NixOS manual.
:::
## `lib.evalModules` {#module-system-lib-evalModules}
Evaluate a set of modules. This function is typically only used once per application (e.g. once in NixOS, once in Home Manager, ...).
### Parameters {#module-system-lib-evalModules-parameters}
#### `modules` {#module-system-lib-evalModules-param-modules}
A list of modules. These are merged together to form the final configuration.
<!-- TODO link to section about merging, TBD -->
#### `specialArgs` {#module-system-lib-evalModules-param-specialArgs}
An attribute set of module arguments that can be used in `imports`.
This is in contrast to `config._module.args`, which is only available after all `imports` have been resolved.
#### `class` {#module-system-lib-evalModules-param-class}
If the `class` attribute is set and non-`null`, the module system will reject `imports` with a different `_class` declaration.
The `class` value should be a string in lower [camel case](https://en.wikipedia.org/wiki/Camel_case).
If applicable, the `class` should match the "prefix" of the attributes used in (experimental) [flakes](https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-flake.html#description). Some examples are:
- `nixos` as in `flake.nixosModules`
- `nixosTest`: modules that constitute a [NixOS VM test](https://nixos.org/manual/nixos/stable/index.html#sec-nixos-tests)
<!-- We've only just started with `class`. You're invited to add a few more. -->
#### `prefix` {#module-system-lib-evalModules-param-prefix}
A list of strings representing the location at or below which all options are evaluated. This is used by `types.submodule` to improve error reporting and find the implicit `name` module argument.
### Return value {#module-system-lib-evalModules-return-value}
The result is an attribute set with the following attributes:
#### `options` {#module-system-lib-evalModules-return-value-options}
The nested attribute set of all option declarations.
#### `config` {#module-system-lib-evalModules-return-value-config}
The nested attribute set of all option values.
#### `type` {#module-system-lib-evalModules-return-value-type}
A module system type. This type is an instance of `types.submoduleWith` containing the current [`modules`](#module-system-lib-evalModules-param-modules).
The option definitions that are typed with this type will extend the current set of modules, like [`extendModules`](#module-system-lib-evalModules-return-value-extendModules).
However, the value returned from the type is just the [`config`](#module-system-lib-evalModules-return-value-config), like any submodule.
If you're familiar with prototype inheritance, you can think of this `evalModules` invocation as the prototype, and usages of this type as the instances.
This type is also available to the [`modules`](#module-system-lib-evalModules-param-modules) as the module argument `moduleType`.
<!-- TODO: document the module arguments. Using moduleType is like saying: suppose this configuration was extended. -->
#### `extendModules` {#module-system-lib-evalModules-return-value-extendModules}
A function similar to `evalModules` but building on top of the already passed [`modules`](#module-system-lib-evalModules-param-modules). Its arguments, `modules` and `specialArgs` are added to the existing values.
If you're familiar with prototype inheritance, you can think of the current, actual `evalModules` invocation as the prototype, and the return value of `extendModules` as the instance.
This functionality is also available to modules as the `extendModules` module argument.
::: {.note}
**Evaluation Performance**
`extendModules` returns a configuration that shares very little with the original `evalModules` invocation, because the module arguments may be different.
So if you have a configuration that has been (or will be) largely evaluated, almost none of the computation is shared with the configuration returned by `extendModules`.
The real work of module evaluation happens while computing the values in `config` and `options`, so multiple invocations of `extendModules` have a particularly small cost, as long as only the final `config` and `options` are evaluated.
If you do reference multiple `config` (or `options`) from before and after `extendModules`, evaluation performance is the same as with multiple `evalModules` invocations, because the new modules' ability to override existing configuration fundamentally requires constructing a new `config` and `options` fixpoint.
:::
#### `_module` {#module-system-lib-evalModules-return-value-_module}
A portion of the configuration tree which is elided from `config`.
<!-- TODO: when markdown migration is complete, make _module docs visible again and reference _module docs. Maybe move those docs into this chapter? -->
#### `_type` {#module-system-lib-evalModules-return-value-_type}
A nominal type marker, always `"configuration"`.
#### `class` {#module-system-lib-evalModules-return-value-_configurationClass}
The [`class` argument](#module-system-lib-evalModules-param-class).

View File

@@ -86,23 +86,6 @@ meta.platforms = lib.platforms.linux;
Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
### `badPlatforms` {#var-meta-badPlatforms}
The list of Nix [platform types](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L75-L81) on which the package is known not to be buildable.
Hydra will never create prebuilt binaries for these platform types, even if they are in [`meta.platforms`](#var-meta-platforms).
In general it is preferable to set `meta.platforms = lib.platforms.all` and then exclude any platforms on which the package is known not to build.
For example, a package which requires dynamic linking and cannot be linked statically could use this:
```nix
meta.platforms = lib.platforms.all;
meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
```
The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
Some packages use this to automatically detect the maximum set of features with which they can be built.
For example, `systemd` [requires dynamic linking](https://github.com/systemd/systemd/issues/20600#issuecomment-912338965), and [has a `meta.badPlatforms` setting](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/pkgs/os-specific/linux/systemd/default.nix#L752) similar to the one above.
Packages which can be built with or without `systemd` support will use `lib.meta.availableOn` to detect whether or not `systemd` is available on the [`hostPlatform`](#ssec-cross-platform-parameters) for which they are being built; if it is not available (e.g. due to a statically-linked host platform like `pkgsStatic`) this support will be disabled by default.
### `tests` {#var-meta-tests}
::: {.warning}
@@ -182,7 +165,7 @@ runCommand "my-package-test" {
### `timeout` {#var-meta-timeout}
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, Hydra will fail it due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in `nixpkgs`.
`meta` attributes are not stored in the instantiated derivation.
Therefore, this setting may be lost when the package is used as a dependency.
@@ -190,7 +173,7 @@ To be effective, it must be presented directly to an evaluation process that han
### `hydraPlatforms` {#var-meta-hydraPlatforms}
The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
The list of Nix platform types for which the Hydra instance at `hydra.nixos.org` will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
```nix
meta.platforms = lib.platforms.linux;
@@ -199,26 +182,7 @@ meta.hydraPlatforms = [];
### `broken` {#var-meta-broken}
If set to `true`, the package is marked as "broken", meaning that it wont show up in [search.nixos.org](https://search.nixos.org/packages), and cannot be built or installed unless the environment variable [`NIXPKGS_ALLOW_BROKEN`](#opt-allowBroken) is set.
Such unconditionally-broken packages should be removed from Nixpkgs eventually unless they are fixed.
The value of this attribute can depend on a package's arguments, including `stdenv`.
This means that `broken` can be used to express constraints, for example:
- Does not cross compile
```nix
meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform)
```
- Broken if all of a certain set of its dependencies are broken
```nix
meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ])
```
This makes `broken` strictly more powerful than `meta.badPlatforms`.
However `meta.availableOn` currently examines only `meta.platforms` and `meta.badPlatforms`, so `meta.broken` does not influence the default values for optional dependencies.
If set to `true`, the package is marked as "broken", meaning that it wont show up in `nix-env -qa`, and cannot be built or installed. Such packages should be removed from Nixpkgs eventually unless they are fixed.
## Licenses {#sec-meta-license}

View File

@@ -257,7 +257,7 @@ propagated-dep(mapOffset(h0, t0, h1),
```
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
dep(h0, t0, A, B)
dep(h0, _, A, B)
propagated-dep(h1, t1, B, C)
h0 + h1 in {-1, 0, 1}
h0 + t1 in {-1, 0, -1}
@@ -1204,7 +1204,7 @@ Nix itself considers a build-time dependency as merely something that should pre
In order to alleviate this burden, the setup hook mechanism was written, where any package can include a shell script that \[by convention rather than enforcement by Nix\], any downstream reverse-dependency will source as part of its build process. That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves. No boilerplate mirroring the list of dependencies is needed.
The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isnt without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the latter isnt. For example, if a derivation path is mentioned more than once, Nix itself doesnt care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
The setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect. The combination of its power and implicit use may be expedient, but isnt without costs. Nix itself is unchanged, but the spirit of added dependencies being effect-free is violated even if the letter isnt. For example, if a derivation path is mentioned more than once, Nix itself doesnt care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent. However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable). More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency. For example, the C compiler wrappers setup hook feeds itself flags for each dependency that contains relevant libraries and headers. This is done by defining a bash function, and appending its name to one of `envBuildBuildHooks`, `envBuildHostHooks`, `envBuildTargetHooks`, `envHostHostHooks`, `envHostTargetHooks`, or `envTargetTargetHooks`. These 6 bash variables correspond to the 6 sorts of dependencies by platform (theres 12 total but we ignore the propagated/non-propagated axis).

View File

@@ -57,19 +57,6 @@
nixosModules = {
notDetected = ./nixos/modules/installer/scan/not-detected.nix;
/*
Make the `nixpkgs.*` configuration read-only. Guarantees that `pkgs`
is the way you initialize it.
Example:
{
imports = [ nixpkgs.nixosModules.readOnlyPkgs ];
nixpkgs.pkgs = nixpkgs.legacyPackages.x86_64-linux;
}
*/
readOnlyPkgs = ./nixos/modules/misc/nixpkgs/read-only.nix;
};
};
}

View File

@@ -123,11 +123,7 @@ rec {
{ x = "a"; y = "b"; }
=> { x = "a"; xa = "a"; y = "b"; yb = "b"; }
*/
concatMapAttrs = f: v:
foldl' mergeAttrs { }
(attrValues
(mapAttrs f v)
);
concatMapAttrs = f: flip pipe [ (mapAttrs f) attrValues (foldl' mergeAttrs { }) ];
/* Update or set specific paths of an attribute set.

View File

@@ -117,11 +117,10 @@ let
inherit (self.meta) addMetaAttrs dontDistribute setName updateName
appendToName mapDerivationAttrset setPrio lowPrio lowPrioSet hiPrio
hiPrioSet getLicenseFromSpdxId getExe;
inherit (self.filesystem) pathType pathIsDirectory pathIsRegularFile;
inherit (self.sources) cleanSourceFilter
inherit (self.sources) pathType pathIsDirectory cleanSourceFilter
cleanSource sourceByRegex sourceFilesBySuffices
commitIdFromGitRepo cleanSourceWith pathHasContext
canCleanSource pathIsGitRepo;
canCleanSource pathIsRegularFile pathIsGitRepo;
inherit (self.modules) evalModules setDefaultModuleLocation
unifyModuleSyntax applyModuleArgsIfFunction mergeModules
mergeModules' mergeOptionDecls evalOptionValue mergeDefinitions

View File

@@ -31,7 +31,7 @@ in
(lazyDerivation { inherit derivation; meta.foo = true; }).meta
In these expressions, `derivation` _will_ be evaluated:
In these expressions, it `derivation` _will_ be evaluated:
"${lazyDerivation { inherit derivation }}"

View File

@@ -1,93 +1,13 @@
# Functions for querying information about the filesystem
# without copying any files to the Nix store.
# Functions for copying sources to the Nix store.
{ lib }:
# Tested in lib/tests/filesystem.sh
let
inherit (builtins)
readDir
pathExists
;
inherit (lib.strings)
hasPrefix
;
inherit (lib.filesystem)
pathType
;
in
{
/*
The type of a path. The path needs to exist and be accessible.
The result is either "directory" for a directory, "regular" for a regular file, "symlink" for a symlink, or "unknown" for anything else.
Type:
pathType :: Path -> String
Example:
pathType /.
=> "directory"
pathType /some/file.nix
=> "regular"
*/
pathType =
builtins.readFileType or
# Nix <2.14 compatibility shim
(path:
if ! pathExists path
# Fail irrecoverably to mimic the historic behavior of this function and
# the new builtins.readFileType
then abort "lib.filesystem.pathType: Path ${toString path} does not exist."
# The filesystem root is the only path where `dirOf / == /` and
# `baseNameOf /` is not valid. We can detect this and directly return
# "directory", since we know the filesystem root can't be anything else.
else if dirOf path == path
then "directory"
else (readDir (dirOf path)).${baseNameOf path}
);
/*
Whether a path exists and is a directory.
Type:
pathIsDirectory :: Path -> Bool
Example:
pathIsDirectory /.
=> true
pathIsDirectory /this/does/not/exist
=> false
pathIsDirectory /some/file.nix
=> false
*/
pathIsDirectory = path:
pathExists path && pathType path == "directory";
/*
Whether a path exists and is a regular file, meaning not a symlink or any other special file type.
Type:
pathIsRegularFile :: Path -> Bool
Example:
pathIsRegularFile /.
=> false
pathIsRegularFile /this/does/not/exist
=> false
pathIsRegularFile /some/file.nix
=> true
*/
pathIsRegularFile = path:
pathExists path && pathType path == "regular";
/*
A map of all haskell packages defined in the given path,
identified by having a cabal file with the same name as the

View File

@@ -355,7 +355,6 @@ rec {
# PLIST handling
toPlist = {}: v: let
isFloat = builtins.isFloat or (x: false);
isPath = x: builtins.typeOf x == "path";
expr = ind: x: with builtins;
if x == null then "" else
if isBool x then bool ind x else
@@ -363,7 +362,6 @@ rec {
if isString x then str ind x else
if isList x then list ind x else
if isAttrs x then attrs ind x else
if isPath x then str ind (toString x) else
if isFloat x then float ind x else
abort "generators.toPlist: should never happen (v = ${v})";
@@ -431,12 +429,11 @@ ${expr "" v}
/*
Translate a simple Nix expression to Lua representation with occasional
Lua-inlines that can be constructed by mkLuaInline function.
Lua-inlines that can be construted by mkLuaInline function.
Configuration:
* multiline - by default is true which results in indented block-like view.
* indent - initial indent.
* asBindings - by default generate single value, but with this use attrset to set global vars.
Attention:
Regardless of multiline parameter there is no trailing newline.
@@ -467,35 +464,18 @@ ${expr "" v}
/* If this option is true, the output is indented with newlines for attribute sets and lists */
multiline ? true,
/* Initial indentation level */
indent ? "",
/* Interpret as variable bindings */
asBindings ? false,
indent ? ""
}@args: v:
with builtins;
let
innerIndent = "${indent} ";
introSpace = if multiline then "\n${innerIndent}" else " ";
outroSpace = if multiline then "\n${indent}" else " ";
innerArgs = args // {
indent = if asBindings then indent else innerIndent;
asBindings = false;
};
innerArgs = args // { indent = innerIndent; };
concatItems = concatStringsSep ",${introSpace}";
isLuaInline = { _type ? null, ... }: _type == "lua-inline";
generatedBindings =
assert lib.assertMsg (badVarNames == []) "Bad Lua var names: ${toPretty {} badVarNames}";
libStr.concatStrings (
lib.attrsets.mapAttrsToList (key: value: "${indent}${key} = ${toLua innerArgs value}\n") v
);
# https://en.wikibooks.org/wiki/Lua_Programming/variable#Variable_names
matchVarName = match "[[:alpha:]_][[:alnum:]_]*(\\.[[:alpha:]_][[:alnum:]_]*)*";
badVarNames = filter (name: matchVarName name == null) (attrNames v);
in
if asBindings then
generatedBindings
else if v == null then
if v == null then
"nil"
else if isInt v || isFloat v || isString v || isBool v then
builtins.toJSON v

View File

@@ -8,10 +8,9 @@ with lib;
option = x:
x // { optional = true; };
yes = { tristate = "y"; optional = false; };
no = { tristate = "n"; optional = false; };
module = { tristate = "m"; optional = false; };
unset = { tristate = null; optional = false; };
yes = { tristate = "y"; optional = false; };
no = { tristate = "n"; optional = false; };
module = { tristate = "m"; optional = false; };
freeform = x: { freeform = x; optional = false; };
/*

View File

@@ -202,12 +202,6 @@ in mkLicense lset) ({
fullName = "Business Source License 1.1";
url = "https://mariadb.com/bsl11";
free = false;
redistributable = true;
};
caossl = {
fullName = "Computer Associates Open Source Licence Version 1.0";
url = "http://jxplorer.org/licence.html";
};
cal10 = {
@@ -236,12 +230,6 @@ in mkLicense lset) ({
free = false;
};
cc-by-nc-nd-40 = {
spdxId = "CC-BY-NC-ND-4.0";
fullName = "Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International";
free = false;
};
cc-by-nc-sa-20 = {
spdxId = "CC-BY-NC-SA-2.0";
fullName = "Creative Commons Attribution Non Commercial Share Alike 2.0";
@@ -619,12 +607,6 @@ in mkLicense lset) ({
fullName = "Licence Art Libre 1.3";
};
lens = {
fullName = "Lens Terms of Service Agreement";
url = "https://k8slens.dev/licenses/tos";
free = false;
};
lgpl2Only = {
spdxId = "LGPL-2.0-only";
fullName = "GNU Library General Public License v2 only";

View File

@@ -63,8 +63,39 @@ let
decls
));
/* See https://nixos.org/manual/nixpkgs/unstable/#module-system-lib-evalModules
or file://./../doc/module-system/module-system.chapter.md
in
rec {
/*
Evaluate a set of modules. The result is a set with the attributes:
options: The nested set of all option declarations,
config: The nested set of all option values.
type: A module system type representing the module set as a submodule,
to be extended by configuration from the containing module set.
This is also available as the module argument moduleType.
extendModules: A function similar to evalModules but building on top
of the module set. Its arguments, modules and specialArgs are
added to the existing values.
Using extendModules a few times has no performance impact as long
as you only reference the final options and config.
If you do reference multiple config (or options) from before and
after extendModules, performance is the same as with multiple
evalModules invocations, because the new modules' ability to
override existing configuration fundamentally requires a new
fixpoint to be constructed.
This is also available as a module argument.
_module: A portion of the configuration tree which is elided from
config. It contains some values that are mostly internal to the
module system implementation.
!!! Please think twice before adding to this argument list! The more
that is specified here instead of in the modules themselves the harder
@@ -79,12 +110,8 @@ let
# there's _module.args. If specialArgs.modulesPath is defined it will be
# used as the base path for disabledModules.
specialArgs ? {}
, # `class`:
# A nominal type for modules. When set and non-null, this adds a check to
# make sure that only compatible modules are imported.
# This would be remove in the future, Prefer _module.args option instead.
class ? null
, args ? {}
, # This would be remove in the future, Prefer _module.args option instead.
args ? {}
, # This would be remove in the future, Prefer _module.check option instead.
check ? true
}:
@@ -233,7 +260,6 @@ let
merged =
let collected = collectModules
class
(specialArgs.modulesPath or "")
(regularModules ++ [ internalModule ])
({ inherit lib options config specialArgs; } // specialArgs);
@@ -310,64 +336,38 @@ let
prefix ? [],
}:
evalModules (evalModulesArgs // {
inherit class;
modules = regularModules ++ modules;
specialArgs = evalModulesArgs.specialArgs or {} // specialArgs;
prefix = extendArgs.prefix or evalModulesArgs.prefix or [];
});
type = lib.types.submoduleWith {
inherit modules specialArgs class;
inherit modules specialArgs;
};
result = withWarnings {
_type = "configuration";
options = checked options;
config = checked (removeAttrs config [ "_module" ]);
_module = checked (config._module);
inherit extendModules type;
class = class;
};
in result;
# collectModules :: (class: String) -> (modulesPath: String) -> (modules: [ Module ]) -> (args: Attrs) -> [ Module ]
# collectModules :: (modulesPath: String) -> (modules: [ Module ]) -> (args: Attrs) -> [ Module ]
#
# Collects all modules recursively through `import` statements, filtering out
# all modules in disabledModules.
collectModules = class: let
collectModules = let
# Like unifyModuleSyntax, but also imports paths and calls functions if necessary
loadModule = args: fallbackFile: fallbackKey: m:
if isFunction m then
unifyModuleSyntax fallbackFile fallbackKey (applyModuleArgs fallbackKey m args)
else if isAttrs m then
if m._type or "module" == "module" then
unifyModuleSyntax fallbackFile fallbackKey m
else if m._type == "if" || m._type == "override" then
loadModule args fallbackFile fallbackKey { config = m; }
else
throw (
"Could not load a value as a module, because it is of type ${lib.strings.escapeNixString m._type}"
+ lib.optionalString (fallbackFile != unknownModule) ", in file ${toString fallbackFile}."
+ lib.optionalString (m._type == "configuration") " If you do intend to import this configuration, please only import the modules that make up the configuration. You may have to create a `let` binding, file or attribute to give yourself access to the relevant modules.\nWhile loading a configuration into the module system is a very sensible idea, it can not be done cleanly in practice."
# Extended explanation: That's because a finalized configuration is more than just a set of modules. For instance, it has its own `specialArgs` that, by the nature of `specialArgs` can't be loaded through `imports` or the the `modules` argument. So instead, we have to ask you to extract the relevant modules and use those instead. This way, we keep the module system comparatively simple, and hopefully avoid a bad surprise down the line.
)
if isFunction m || isAttrs m then
unifyModuleSyntax fallbackFile fallbackKey (applyModuleArgsIfFunction fallbackKey m args)
else if isList m then
let defs = [{ file = fallbackFile; value = m; }]; in
throw "Module imports can't be nested lists. Perhaps you meant to remove one level of lists? Definitions: ${showDefs defs}"
else unifyModuleSyntax (toString m) (toString m) (applyModuleArgsIfFunction (toString m) (import m) args);
checkModule =
if class != null
then
m:
if m._class != null -> m._class == class
then m
else
throw "The module ${m._file or m.key} was imported into ${class} instead of ${m._class}."
else
m: m;
/*
Collects all modules recursively into the form
@@ -401,7 +401,7 @@ let
};
in parentFile: parentKey: initialModules: args: collectResults (imap1 (n: x:
let
module = checkModule (loadModule args parentFile "${parentKey}:anon-${toString n}" x);
module = loadModule args parentFile "${parentKey}:anon-${toString n}" x;
collectedImports = collectStructuredModules module._file module.key module.imports args;
in {
key = module.key;
@@ -465,12 +465,11 @@ let
else config;
in
if m ? config || m ? options then
let badAttrs = removeAttrs m ["_class" "_file" "key" "disabledModules" "imports" "options" "config" "meta" "freeformType"]; in
let badAttrs = removeAttrs m ["_file" "key" "disabledModules" "imports" "options" "config" "meta" "freeformType"]; in
if badAttrs != {} then
throw "Module `${key}' has an unsupported attribute `${head (attrNames badAttrs)}'. This is caused by introducing a top-level `config' or `options' attribute. Add configuration attributes immediately on the top level instead, or move all of them (namely: ${toString (attrNames badAttrs)}) into the explicit `config' attribute."
else
{ _file = toString m._file or file;
_class = m._class or null;
key = toString m.key or key;
disabledModules = m.disabledModules or [];
imports = m.imports or [];
@@ -481,18 +480,14 @@ let
# shorthand syntax
lib.throwIfNot (isAttrs m) "module ${file} (${key}) does not look like a module."
{ _file = toString m._file or file;
_class = m._class or null;
key = toString m.key or key;
disabledModules = m.disabledModules or [];
imports = m.require or [] ++ m.imports or [];
options = {};
config = addFreeformType (removeAttrs m ["_class" "_file" "key" "disabledModules" "require" "imports" "freeformType"]);
config = addFreeformType (removeAttrs m ["_file" "key" "disabledModules" "require" "imports" "freeformType"]);
};
applyModuleArgsIfFunction = key: f: args@{ config, options, lib, ... }:
if isFunction f then applyModuleArgs key f args else f;
applyModuleArgs = key: f: args@{ config, options, lib, ... }:
applyModuleArgsIfFunction = key: f: args@{ config, options, lib, ... }: if isFunction f then
let
# Module arguments are resolved in a strict manner when attribute set
# deconstruction is used. As the arguments are now defined with the
@@ -516,7 +511,9 @@ let
# context on the explicit arguments of "args" too. This update
# operator is used to make the "args@{ ... }: with args.lib;" notation
# works.
in f (args // extraArgs);
in f (args // extraArgs)
else
f;
/* Merge a list of modules. This will recurse over the option
declarations in all modules, combining them into a single set.
@@ -1221,67 +1218,4 @@ let
_file = file;
config = lib.importTOML file;
};
private = lib.mapAttrs
(k: lib.warn "External use of `lib.modules.${k}` is deprecated. If your use case isn't covered by non-deprecated functions, we'd like to know more and perhaps support your use case well, instead of providing access to these low level functions. In this case please open an issue in https://github.com/nixos/nixpkgs/issues/.")
{
inherit
applyModuleArgsIfFunction
dischargeProperties
evalOptionValue
mergeModules
mergeModules'
pushDownProperties
unifyModuleSyntax
;
collectModules = collectModules null;
};
in
private //
{
# NOTE: not all of these functions are necessarily public interfaces; some
# are just needed by types.nix, but are not meant to be consumed
# externally.
inherit
defaultOrderPriority
defaultOverridePriority
defaultPriority
doRename
evalModules
filterOverrides
filterOverrides'
fixMergeModules
fixupOptionType # should be private?
importJSON
importTOML
mergeDefinitions
mergeOptionDecls # should be private?
mkAfter
mkAliasAndWrapDefinitions
mkAliasAndWrapDefsWithPriority
mkAliasDefinitions
mkAliasIfDef
mkAliasOptionModule
mkAliasOptionModuleMD
mkAssert
mkBefore
mkChangedOptionModule
mkDefault
mkDerivedConfig
mkFixStrictness
mkForce
mkIf
mkImageMediaOverride
mkMerge
mkMergedOptionModule
mkOptionDefault
mkOrder
mkOverride
mkRemovedOptionModule
mkRenamedOptionModule
mkRenamedOptionModuleWith
mkVMOverride
setDefaultModuleLocation
sortProperties;
}

View File

@@ -155,8 +155,6 @@ rec {
# Name for the package, shown in option description
name:
{
# Whether the package can be null, for example to disable installing a package altogether.
nullable ? false,
# The attribute path where the default package is located (may be omitted)
default ? name,
# A string or an attribute path to use as an example (may be omitted)
@@ -166,24 +164,19 @@ rec {
}:
let
name' = if isList name then last name else name;
in mkOption ({
type = with lib.types; (if nullable then nullOr else lib.id) package;
description = "The ${name'} package to use."
+ (if extraDescription == "" then "" else " ") + extraDescription;
} // (if default != null then let
default' = if isList default then default else [ default ];
defaultPath = concatStringsSep "." default';
defaultValue = attrByPath default'
(throw "${defaultPath} cannot be found in pkgs") pkgs;
in {
default = defaultValue;
in mkOption {
defaultText = literalExpression ("pkgs." + defaultPath);
} else if nullable then {
default = null;
} else { }) // lib.optionalAttrs (example != null) {
example = literalExpression
type = lib.types.package;
description = "The ${name'} package to use."
+ (if extraDescription == "" then "" else " ") + extraDescription;
${if default != null then "default" else null} = defaultValue;
${if example != null then "example" else null} = literalExpression
(if isList example then "pkgs." + concatStringsSep "." example else example);
});
};
/* Like mkPackageOption, but emit an mdDoc description instead of DocBook. */
mkPackageOptionMD = pkgs: name: extra:
@@ -268,7 +261,7 @@ rec {
concatMap (opt:
let
name = showOption opt.loc;
docOption = {
docOption = rec {
loc = opt.loc;
inherit name;
description = opt.description or null;
@@ -287,9 +280,9 @@ rec {
renderOptionValue opt.example
);
}
// optionalAttrs (opt ? defaultText || opt ? default) {
// optionalAttrs (opt ? default) {
default =
builtins.addErrorContext "while evaluating the ${if opt?defaultText then "defaultText" else "default value"} of option `${name}`" (
builtins.addErrorContext "while evaluating the default value of option `${name}`" (
renderOptionValue (opt.defaultText or opt.default)
);
}

View File

@@ -18,11 +18,21 @@ let
pathExists
readFile
;
inherit (lib.filesystem)
pathType
pathIsDirectory
pathIsRegularFile
;
/*
Returns the type of a path: regular (for file), symlink, or directory.
*/
pathType = path: getAttr (baseNameOf path) (readDir (dirOf path));
/*
Returns true if the path exists and is a directory, false otherwise.
*/
pathIsDirectory = path: if pathExists path then (pathType path) == "directory" else false;
/*
Returns true if the path exists and is a regular file, false otherwise.
*/
pathIsRegularFile = path: if pathExists path then (pathType path) == "regular" else false;
/*
A basic filter for `cleanSourceWith` that removes
@@ -261,20 +271,11 @@ let
};
in {
pathType = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathType has been moved to lib.filesystem.pathType."
lib.filesystem.pathType;
pathIsDirectory = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathIsDirectory has been moved to lib.filesystem.pathIsDirectory."
lib.filesystem.pathIsDirectory;
pathIsRegularFile = lib.warnIf (lib.isInOldestRelease 2305)
"lib.sources.pathIsRegularFile has been moved to lib.filesystem.pathIsRegularFile."
lib.filesystem.pathIsRegularFile;
inherit
pathType
pathIsDirectory
pathIsRegularFile
pathIsGitRepo
commitIdFromGitRepo

View File

@@ -50,7 +50,6 @@ rec {
else if final.isFreeBSD then "fblibc"
else if final.isNetBSD then "nblibc"
else if final.isAvr then "avrlibc"
else if final.isGhcjs then null
else if final.isNone then "newlib"
# TODO(@Ericson2314) think more about other operating systems
else "native/impure";
@@ -121,7 +120,7 @@ rec {
({
linux-kernel = args.linux-kernel or {};
gcc = args.gcc or {};
rustc = args.rustc or {};
rustc = args.rust or {};
} // platforms.select final)
linux-kernel gcc rustc;
@@ -137,7 +136,6 @@ rec {
else if final.isPower then "powerpc"
else if final.isRiscV then "riscv"
else if final.isS390 then "s390"
else if final.isLoongArch64 then "loongarch"
else final.parsed.cpu.name;
qemuArch =
@@ -145,7 +143,6 @@ rec {
else if final.isS390 && !final.isS390x then null
else if final.isx86_64 then "x86_64"
else if final.isx86 then "i386"
else if final.isMips64 then "mips64${lib.optionalString final.isLittleEndian "el"}"
else final.uname.processor;
# Name used by UEFI for architectures.

View File

@@ -26,10 +26,10 @@ let
# Linux
"aarch64-linux" "armv5tel-linux" "armv6l-linux" "armv7a-linux"
"armv7l-linux" "i686-linux" "loongarch64-linux" "m68k-linux" "microblaze-linux"
"microblazeel-linux" "mips-linux" "mips64-linux" "mips64el-linux"
"mipsel-linux" "powerpc64-linux" "powerpc64le-linux" "riscv32-linux"
"riscv64-linux" "s390-linux" "s390x-linux" "x86_64-linux"
"armv7l-linux" "i686-linux" "m68k-linux" "microblaze-linux"
"microblazeel-linux" "mipsel-linux" "mips64el-linux" "powerpc64-linux"
"powerpc64le-linux" "riscv32-linux" "riscv64-linux" "s390-linux"
"s390x-linux" "x86_64-linux"
# MMIXware
"mmix-mmixware"
@@ -86,7 +86,6 @@ in {
m68k = filterDoubles predicates.isM68k;
s390 = filterDoubles predicates.isS390;
s390x = filterDoubles predicates.isS390x;
loongarch64 = filterDoubles predicates.isLoongArch64;
js = filterDoubles predicates.isJavaScript;
bigEndian = filterDoubles predicates.isBigEndian;

View File

@@ -91,16 +91,22 @@ rec {
} // platforms.fuloong2f_n32;
# can execute on 32bit chip
mips-linux-gnu = { config = "mips-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsel-linux-gnu = { config = "mipsel-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mips-linux-gnu = { config = "mips-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsel-linux-gnu = { config = "mipsel-unknown-linux-gnu"; } // platforms.gcc_mips32r2_o32;
mipsisa32r6-linux-gnu = { config = "mipsisa32r6-unknown-linux-gnu"; } // platforms.gcc_mips32r6_o32;
mipsisa32r6el-linux-gnu = { config = "mipsisa32r6el-unknown-linux-gnu"; } // platforms.gcc_mips32r6_o32;
# require 64bit chip (for more registers, 64-bit floating point, 64-bit "long long") but use 32bit pointers
mips64-linux-gnuabin32 = { config = "mips64-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mips64el-linux-gnuabin32 = { config = "mips64el-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mips64-linux-gnuabin32 = { config = "mips64-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mips64el-linux-gnuabin32 = { config = "mips64el-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r2_n32;
mipsisa64r6-linux-gnuabin32 = { config = "mipsisa64r6-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
mipsisa64r6el-linux-gnuabin32 = { config = "mipsisa64r6el-unknown-linux-gnuabin32"; } // platforms.gcc_mips64r6_n32;
# 64bit pointers
mips64-linux-gnuabi64 = { config = "mips64-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mips64el-linux-gnuabi64 = { config = "mips64el-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mips64-linux-gnuabi64 = { config = "mips64-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mips64el-linux-gnuabi64 = { config = "mips64el-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r2_64;
mipsisa64r6-linux-gnuabi64 = { config = "mipsisa64r6-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
mipsisa64r6el-linux-gnuabi64 = { config = "mipsisa64r6el-unknown-linux-gnuabi64"; } // platforms.gcc_mips64r6_64;
muslpi = raspberryPi // {
config = "armv6l-unknown-linux-musleabihf";
@@ -129,10 +135,6 @@ rec {
libc = "newlib";
};
loongarch64-linux = {
config = "loongarch64-unknown-linux-gnu";
};
mmix = {
config = "mmix-unknown-mmixware";
libc = "newlib";

View File

@@ -9,14 +9,6 @@ let abis = lib.mapAttrs (_: abi: builtins.removeAttrs abi [ "assertions" ]) abis
rec {
# these patterns are to be matched against {host,build,target}Platform.parsed
patterns = rec {
# The patterns below are lists in sum-of-products form.
#
# Each attribute is list of product conditions; non-list values are treated
# as a singleton list. If *any* product condition in the list matches then
# the predicate matches. Each product condition is tested by
# `lib.attrsets.matchAttrs`, which requires a match on *all* attributes of
# the product.
isi686 = { cpu = cpuTypes.i686; };
isx86_32 = { cpu = { family = "x86"; bits = 32; }; };
isx86_64 = { cpu = { family = "x86"; bits = 64; }; };
@@ -57,7 +49,6 @@ rec {
isM68k = { cpu = { family = "m68k"; }; };
isS390 = { cpu = { family = "s390"; }; };
isS390x = { cpu = { family = "s390"; bits = 64; }; };
isLoongArch64 = { cpu = { family = "loongarch"; bits = 64; }; };
isJavaScript = { cpu = cpuTypes.javascript; };
is32bit = { cpu = { bits = 32; }; };

View File

@@ -91,10 +91,14 @@ rec {
microblaze = { bits = 32; significantByte = bigEndian; family = "microblaze"; };
microblazeel = { bits = 32; significantByte = littleEndian; family = "microblaze"; };
mips = { bits = 32; significantByte = bigEndian; family = "mips"; };
mipsel = { bits = 32; significantByte = littleEndian; family = "mips"; };
mips64 = { bits = 64; significantByte = bigEndian; family = "mips"; };
mips64el = { bits = 64; significantByte = littleEndian; family = "mips"; };
mips = { bits = 32; significantByte = bigEndian; family = "mips"; };
mipsel = { bits = 32; significantByte = littleEndian; family = "mips"; };
mipsisa32r6 = { bits = 32; significantByte = bigEndian; family = "mips"; };
mipsisa32r6el = { bits = 32; significantByte = littleEndian; family = "mips"; };
mips64 = { bits = 64; significantByte = bigEndian; family = "mips"; };
mips64el = { bits = 64; significantByte = littleEndian; family = "mips"; };
mipsisa64r6 = { bits = 64; significantByte = bigEndian; family = "mips"; };
mipsisa64r6el = { bits = 64; significantByte = littleEndian; family = "mips"; };
mmix = { bits = 64; significantByte = bigEndian; family = "mmix"; };
@@ -127,8 +131,6 @@ rec {
or1k = { bits = 32; significantByte = bigEndian; family = "or1k"; };
loongarch64 = { bits = 64; significantByte = littleEndian; family = "loongarch"; };
javascript = { bits = 32; significantByte = littleEndian; family = "javascript"; };
};

View File

@@ -1,84 +0,0 @@
#!/usr/bin/env bash
# Tests lib/filesystem.nix
# Run:
# [nixpkgs]$ lib/tests/filesystem.sh
# or:
# [nixpkgs]$ nix-build lib/tests/release.nix
set -euo pipefail
shopt -s inherit_errexit
# Use
# || die
die() {
echo >&2 "test case failed: " "$@"
exit 1
}
if test -n "${TEST_LIB:-}"; then
NIX_PATH=nixpkgs="$(dirname "$TEST_LIB")"
else
NIX_PATH=nixpkgs="$(cd "$(dirname "${BASH_SOURCE[0]}")/../.."; pwd)"
fi
export NIX_PATH
work="$(mktemp -d)"
clean_up() {
rm -rf "$work"
}
trap clean_up EXIT
cd "$work"
mkdir directory
touch regular
ln -s target symlink
mkfifo fifo
expectSuccess() {
local expr=$1
local expectedResultRegex=$2
if ! result=$(nix-instantiate --eval --strict --json \
--expr "with (import <nixpkgs/lib>).filesystem; $expr"); then
die "$expr failed to evaluate, but it was expected to succeed"
fi
if [[ ! "$result" =~ $expectedResultRegex ]]; then
die "$expr == $result, but $expectedResultRegex was expected"
fi
}
expectFailure() {
local expr=$1
local expectedErrorRegex=$2
if result=$(nix-instantiate --eval --strict --json 2>"$work/stderr" \
--expr "with (import <nixpkgs/lib>).filesystem; $expr"); then
die "$expr evaluated successfully to $result, but it was expected to fail"
fi
if [[ ! "$(<"$work/stderr")" =~ $expectedErrorRegex ]]; then
die "Error was $(<"$work/stderr"), but $expectedErrorRegex was expected"
fi
}
expectSuccess "pathType /." '"directory"'
expectSuccess "pathType $PWD/directory" '"directory"'
expectSuccess "pathType $PWD/regular" '"regular"'
expectSuccess "pathType $PWD/symlink" '"symlink"'
expectSuccess "pathType $PWD/fifo" '"unknown"'
# Different errors depending on whether the builtins.readFilePath primop is available or not
expectFailure "pathType $PWD/non-existent" "error: (evaluation aborted with the following error message: 'lib.filesystem.pathType: Path $PWD/non-existent does not exist.'|getting status of '$PWD/non-existent': No such file or directory)"
expectSuccess "pathIsDirectory /." "true"
expectSuccess "pathIsDirectory $PWD/directory" "true"
expectSuccess "pathIsDirectory $PWD/regular" "false"
expectSuccess "pathIsDirectory $PWD/symlink" "false"
expectSuccess "pathIsDirectory $PWD/fifo" "false"
expectSuccess "pathIsDirectory $PWD/non-existent" "false"
expectSuccess "pathIsRegularFile /." "false"
expectSuccess "pathIsRegularFile $PWD/directory" "false"
expectSuccess "pathIsRegularFile $PWD/regular" "true"
expectSuccess "pathIsRegularFile $PWD/symlink" "false"
expectSuccess "pathIsRegularFile $PWD/fifo" "false"
expectSuccess "pathIsRegularFile $PWD/non-existent" "false"
echo >&2 tests ok

View File

@@ -4,11 +4,6 @@
with import ../default.nix;
let
testingThrow = expr: {
expr = (builtins.tryEval (builtins.seq expr "didn't throw"));
expected = { success = false; value = false; };
};
testingDeepThrow = expr: testingThrow (builtins.deepSeq expr expr);
testSanitizeDerivationName = { name, expected }:
let
@@ -919,30 +914,6 @@ runTests {
expected = "«foo»";
};
testToPlist =
let
deriv = derivation { name = "test"; builder = "/bin/sh"; system = "aarch64-linux"; };
in {
expr = mapAttrs (const (generators.toPlist { })) {
value = {
nested.values = rec {
int = 42;
float = 0.1337;
bool = true;
emptystring = "";
string = "fn\${o}\"r\\d";
newlinestring = "\n";
path = /. + "/foo";
null_ = null;
list = [ 3 4 "test" ];
emptylist = [];
attrs = { foo = null; "foo b/ar" = "baz"; };
emptyattrs = {};
};
};
};
expected = { value = builtins.readFile ./test-to-plist-expected.plist; };
};
testToLuaEmptyAttrSet = {
expr = generators.toLua {} {};
@@ -991,41 +962,6 @@ runTests {
expected = ''{ 41, 43 }'';
};
testToLuaEmptyBindings = {
expr = generators.toLua { asBindings = true; } {};
expected = "";
};
testToLuaBindings = {
expr = generators.toLua { asBindings = true; } { x1 = 41; _y = { a = 43; }; };
expected = ''
_y = {
["a"] = 43
}
x1 = 41
'';
};
testToLuaPartialTableBindings = {
expr = generators.toLua { asBindings = true; } { "x.y" = 42; };
expected = ''
x.y = 42
'';
};
testToLuaIndentedBindings = {
expr = generators.toLua { asBindings = true; indent = " "; } { x = { y = 42; }; };
expected = " x = {\n [\"y\"] = 42\n }\n";
};
testToLuaBindingsWithSpace = testingThrow (
generators.toLua { asBindings = true; } { "with space" = 42; }
);
testToLuaBindingsWithLeadingDigit = testingThrow (
generators.toLua { asBindings = true; } { "11eleven" = 42; }
);
testToLuaBasicExample = {
expr = generators.toLua {} {
cmd = [ "typescript-language-server" "--stdio" ];

View File

@@ -166,7 +166,6 @@ checkConfigError 'The option .* does not exist. Definition values:\n\s*- In .*'
checkConfigOutput '^true$' "$@" ./define-module-check.nix
# Check coerced value.
set --
checkConfigOutput '^"42"$' config.value ./declare-coerced-value.nix
checkConfigOutput '^"24"$' config.value ./declare-coerced-value.nix ./define-value-string.nix
checkConfigError 'A definition for option .* is not.*string or signed integer convertible to it.*. Definition values:\n\s*- In .*: \[ \]' config.value ./declare-coerced-value.nix ./define-value-list.nix
@@ -182,11 +181,6 @@ checkConfigOutput '^true$' config.enableAlias ./alias-with-priority.nix
checkConfigOutput '^false$' config.enable ./alias-with-priority-can-override.nix
checkConfigOutput '^false$' config.enableAlias ./alias-with-priority-can-override.nix
# Check mkPackageOption
checkConfigOutput '^"hello"$' config.package.pname ./declare-mkPackageOption.nix
checkConfigError 'The option .undefinedPackage. is used but not defined' config.undefinedPackage ./declare-mkPackageOption.nix
checkConfigOutput '^null$' config.nullablePackage ./declare-mkPackageOption.nix
# submoduleWith
## specialArgs should work
@@ -260,8 +254,6 @@ checkConfigError 'A definition for option .* is not of type .*' \
## Freeform modules
# Assigning without a declared option should work
checkConfigOutput '^"24"$' config.value ./freeform-attrsOf.nix ./define-value-string.nix
# Shorthand modules interpret `meta` and `class` as config items
checkConfigOutput '^true$' options._module.args.value.result ./freeform-attrsOf.nix ./define-freeform-keywords-shorthand.nix
# No freeform assignments shouldn't make it error
checkConfigOutput '^{ }$' config ./freeform-attrsOf.nix
# but only if the type matches
@@ -367,24 +359,6 @@ checkConfigOutput 'ok' config.freeformItems.foo.bar ./adhoc-freeformType-survive
# because of an `extendModules` bug, issue 168767.
checkConfigOutput '^1$' config.sub.specialisation.value ./extendModules-168767-imports.nix
# Class checks, evalModules
checkConfigOutput '^{ }$' config.ok.config ./class-check.nix
checkConfigOutput '"nixos"' config.ok.class ./class-check.nix
checkConfigError 'The module .*/module-class-is-darwin.nix was imported into nixos instead of darwin.' config.fail.config ./class-check.nix
checkConfigError 'The module foo.nix#darwinModules.default was imported into nixos instead of darwin.' config.fail-anon.config ./class-check.nix
# Class checks, submoduleWith
checkConfigOutput '^{ }$' config.sub.nixosOk ./class-check.nix
checkConfigError 'The module .*/module-class-is-darwin.nix was imported into nixos instead of darwin.' config.sub.nixosFail.config ./class-check.nix
# submoduleWith type merge with different class
checkConfigError 'A submoduleWith option is declared multiple times with conflicting class values "darwin" and "nixos".' config.sub.mergeFail.config ./class-check.nix
# _type check
checkConfigError 'Could not load a value as a module, because it is of type "flake", in file .*/module-imports-_type-check.nix' config.ok.config ./module-imports-_type-check.nix
checkConfigOutput '^true$' "$@" config.enable ./declare-enable.nix ./define-enable-with-top-level-mkIf.nix
checkConfigError 'Could not load a value as a module, because it is of type "configuration", in file .*/import-configuration.nix.*please only import the modules that make up the configuration.*' config ./import-configuration.nix
# doRename works when `warnings` does not exist.
checkConfigOutput '^1234$' config.c.d.e ./doRename-basic.nix
# doRename adds a warning.

View File

@@ -1,76 +0,0 @@
{ lib, ... }: {
options = {
sub = {
nixosOk = lib.mkOption {
type = lib.types.submoduleWith {
class = "nixos";
modules = [ ];
};
};
# Same but will have bad definition
nixosFail = lib.mkOption {
type = lib.types.submoduleWith {
class = "nixos";
modules = [ ];
};
};
mergeFail = lib.mkOption {
type = lib.types.submoduleWith {
class = "nixos";
modules = [ ];
};
default = { };
};
};
};
imports = [
{
options = {
sub = {
mergeFail = lib.mkOption {
type = lib.types.submoduleWith {
class = "darwin";
modules = [ ];
};
};
};
};
}
];
config = {
_module.freeformType = lib.types.anything;
ok =
lib.evalModules {
class = "nixos";
modules = [
./module-class-is-nixos.nix
];
};
fail =
lib.evalModules {
class = "nixos";
modules = [
./module-class-is-nixos.nix
./module-class-is-darwin.nix
];
};
fail-anon =
lib.evalModules {
class = "nixos";
modules = [
./module-class-is-nixos.nix
{ _file = "foo.nix#darwinModules.default";
_class = "darwin";
config = {};
imports = [];
}
];
};
sub.nixosOk = { _class = "nixos"; };
sub.nixosFail = { imports = [ ./module-class-is-darwin.nix ]; };
};
}

View File

@@ -1,19 +0,0 @@
{ lib, ... }: let
pkgs.hello = {
type = "derivation";
pname = "hello";
};
in {
options = {
package = lib.mkPackageOption pkgs "hello" { };
undefinedPackage = lib.mkPackageOption pkgs "hello" {
default = null;
};
nullablePackage = lib.mkPackageOption pkgs "hello" {
nullable = true;
default = null;
};
};
}

View File

@@ -1,5 +0,0 @@
{ lib, ... }:
# I think this might occur more realistically in a submodule
{
imports = [ (lib.mkIf true { enable = true; }) ];
}

View File

@@ -1,15 +0,0 @@
{ config, ... }: {
class = { "just" = "data"; };
a = "one";
b = "two";
meta = "meta";
_module.args.result =
let r = builtins.removeAttrs config [ "_module" ];
in builtins.trace (builtins.deepSeq r r) (r == {
a = "one";
b = "two";
class = { "just" = "data"; };
meta = "meta";
});
}

View File

@@ -1,12 +0,0 @@
{ lib, ... }:
let
myconf = lib.evalModules { modules = [ { } ]; };
in
{
imports = [
# We can't do this. A configuration is not equal to its set of a modules.
# Equating those would lead to a mess, as specialArgs, anonymous modules
# that can't be deduplicated, and possibly more come into play.
myconf
];
}

View File

@@ -1,4 +0,0 @@
{
_class = "darwin";
config = {};
}

View File

@@ -1,4 +0,0 @@
{
_class = "nixos";
config = {};
}

View File

@@ -1,3 +0,0 @@
{
imports = [ { _type = "flake"; } ];
}

View File

@@ -2,63 +2,50 @@
# Don't test properties of pkgs.lib, but rather the lib in the parent directory
pkgs ? import ../.. {} // { lib = throw "pkgs.lib accessed, but the lib tests should use nixpkgs' lib path directly!"; },
nix ? pkgs.nix,
nixVersions ? [ pkgs.nixVersions.minimum nix pkgs.nixVersions.unstable ],
}:
let
testWithNix = nix:
pkgs.runCommand "nixpkgs-lib-tests-nix-${nix.version}" {
buildInputs = [
(import ./check-eval.nix)
(import ./maintainers.nix {
inherit pkgs;
lib = import ../.;
})
(import ./teams.nix {
inherit pkgs;
lib = import ../.;
})
(import ../path/tests {
inherit pkgs;
})
];
nativeBuildInputs = [
nix
];
strictDeps = true;
} ''
datadir="${nix}/share"
export TEST_ROOT=$(pwd)/test-tmp
export NIX_BUILD_HOOK=
export NIX_CONF_DIR=$TEST_ROOT/etc
export NIX_LOCALSTATE_DIR=$TEST_ROOT/var
export NIX_LOG_DIR=$TEST_ROOT/var/log/nix
export NIX_STATE_DIR=$TEST_ROOT/var/nix
export NIX_STORE_DIR=$TEST_ROOT/store
export PAGER=cat
cacheDir=$TEST_ROOT/binary-cache
pkgs.runCommand "nixpkgs-lib-tests" {
buildInputs = [
(import ./check-eval.nix)
(import ./maintainers.nix {
inherit pkgs;
lib = import ../.;
})
(import ./teams.nix {
inherit pkgs;
lib = import ../.;
})
(import ../path/tests {
inherit pkgs;
})
];
nativeBuildInputs = [
nix
];
strictDeps = true;
} ''
datadir="${nix}/share"
export TEST_ROOT=$(pwd)/test-tmp
export NIX_BUILD_HOOK=
export NIX_CONF_DIR=$TEST_ROOT/etc
export NIX_LOCALSTATE_DIR=$TEST_ROOT/var
export NIX_LOG_DIR=$TEST_ROOT/var/log/nix
export NIX_STATE_DIR=$TEST_ROOT/var/nix
export NIX_STORE_DIR=$TEST_ROOT/store
export PAGER=cat
cacheDir=$TEST_ROOT/binary-cache
mkdir -p $NIX_CONF_DIR
echo "experimental-features = nix-command" >> $NIX_CONF_DIR/nix.conf
mkdir -p $NIX_CONF_DIR
echo "experimental-features = nix-command" >> $NIX_CONF_DIR/nix.conf
nix-store --init
nix-store --init
cp -r ${../.} lib
echo "Running lib/tests/modules.sh"
bash lib/tests/modules.sh
cp -r ${../.} lib
echo "Running lib/tests/modules.sh"
bash lib/tests/modules.sh
echo "Running lib/tests/filesystem.sh"
TEST_LIB=$PWD/lib bash lib/tests/filesystem.sh
echo "Running lib/tests/sources.sh"
TEST_LIB=$PWD/lib bash lib/tests/sources.sh
echo "Running lib/tests/sources.sh"
TEST_LIB=$PWD/lib bash lib/tests/sources.sh
mkdir $out
echo success > $out/${nix.version}
'';
in
pkgs.symlinkJoin {
name = "nixpkgs-lib-tests";
paths = map testWithNix nixVersions;
}
touch $out
''

View File

@@ -23,19 +23,14 @@ clean_up() {
trap clean_up EXIT
cd "$work"
# Crudely unquotes a JSON string by just taking everything between the first and the second quote.
# We're only using this for resulting /nix/store paths, which can't contain " anyways,
# nor can they contain any other characters that would need to be escaped specially in JSON
# This way we don't need to add a dependency on e.g. jq
crudeUnquoteJSON() {
cut -d \" -f2
}
touch {README.md,module.o,foo.bar}
dir="$(nix-instantiate --eval --strict --read-write-mode --json --expr '(with import <nixpkgs/lib>; "${
# nix-instantiate doesn't write out the source, only computing the hash, so
# this uses the experimental nix command instead.
dir="$(nix eval --impure --raw --expr '(with import <nixpkgs/lib>; "${
cleanSource ./.
}")' | crudeUnquoteJSON)"
}")')"
(cd "$dir"; find) | sort -f | diff -U10 - <(cat <<EOF
.
./foo.bar
@@ -44,9 +39,9 @@ EOF
) || die "cleanSource 1"
dir="$(nix-instantiate --eval --strict --read-write-mode --json --expr '(with import <nixpkgs/lib>; "${
dir="$(nix eval --impure --raw --expr '(with import <nixpkgs/lib>; "${
cleanSourceWith { src = '"$work"'; filter = path: type: ! hasSuffix ".bar" path; }
}")' | crudeUnquoteJSON)"
}")')"
(cd "$dir"; find) | sort -f | diff -U10 - <(cat <<EOF
.
./module.o
@@ -54,9 +49,9 @@ dir="$(nix-instantiate --eval --strict --read-write-mode --json --expr '(with im
EOF
) || die "cleanSourceWith 1"
dir="$(nix-instantiate --eval --strict --read-write-mode --json --expr '(with import <nixpkgs/lib>; "${
dir="$(nix eval --impure --raw --expr '(with import <nixpkgs/lib>; "${
cleanSourceWith { src = cleanSource '"$work"'; filter = path: type: ! hasSuffix ".bar" path; }
}")' | crudeUnquoteJSON)"
}")')"
(cd "$dir"; find) | sort -f | diff -U10 - <(cat <<EOF
.
./README.md

View File

@@ -18,7 +18,7 @@ with lib.systems.doubles; lib.runTests {
testarm = mseteq arm [ "armv5tel-linux" "armv6l-linux" "armv6l-netbsd" "armv6l-none" "armv7a-linux" "armv7a-netbsd" "armv7l-linux" "armv7l-netbsd" "arm-none" "armv7a-darwin" ];
testarmv7 = mseteq armv7 [ "armv7a-darwin" "armv7a-linux" "armv7l-linux" "armv7a-netbsd" "armv7l-netbsd" ];
testi686 = mseteq i686 [ "i686-linux" "i686-freebsd13" "i686-genode" "i686-netbsd" "i686-openbsd" "i686-cygwin" "i686-windows" "i686-none" "i686-darwin" ];
testmips = mseteq mips [ "mips-linux" "mips64-linux" "mips64el-linux" "mipsel-linux" "mipsel-netbsd" ];
testmips = mseteq mips [ "mips64el-linux" "mipsel-linux" "mipsel-netbsd" ];
testmmix = mseteq mmix [ "mmix-mmixware" ];
testpower = mseteq power [ "powerpc-netbsd" "powerpc-none" "powerpc64-linux" "powerpc64le-linux" "powerpcle-none" ];
testriscv = mseteq riscv [ "riscv32-linux" "riscv64-linux" "riscv32-netbsd" "riscv64-netbsd" "riscv32-none" "riscv64-none" ];
@@ -34,7 +34,7 @@ with lib.systems.doubles; lib.runTests {
testredox = mseteq redox [ "x86_64-redox" ];
testgnu = mseteq gnu (linux /* ++ kfreebsd ++ ... */);
testillumos = mseteq illumos [ "x86_64-solaris" ];
testlinux = mseteq linux [ "aarch64-linux" "armv5tel-linux" "armv6l-linux" "armv7a-linux" "armv7l-linux" "i686-linux" "loongarch64-linux" "m68k-linux" "microblaze-linux" "microblazeel-linux" "mips-linux" "mips64-linux" "mips64el-linux" "mipsel-linux" "powerpc64-linux" "powerpc64le-linux" "riscv32-linux" "riscv64-linux" "s390-linux" "s390x-linux" "x86_64-linux" ];
testlinux = mseteq linux [ "aarch64-linux" "armv5tel-linux" "armv6l-linux" "armv7a-linux" "armv7l-linux" "i686-linux" "mips64el-linux" "mipsel-linux" "riscv32-linux" "riscv64-linux" "x86_64-linux" "powerpc64-linux" "powerpc64le-linux" "m68k-linux" "s390-linux" "s390x-linux" "microblaze-linux" "microblazeel-linux" ];
testnetbsd = mseteq netbsd [ "aarch64-netbsd" "armv6l-netbsd" "armv7a-netbsd" "armv7l-netbsd" "i686-netbsd" "m68k-netbsd" "mipsel-netbsd" "powerpc-netbsd" "riscv32-netbsd" "riscv64-netbsd" "x86_64-netbsd" ];
testopenbsd = mseteq openbsd [ "i686-openbsd" "x86_64-openbsd" ];
testwindows = mseteq windows [ "i686-cygwin" "x86_64-cygwin" "i686-windows" "x86_64-windows" ];

View File

@@ -1,46 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>nested</key>
<dict>
<key>values</key>
<dict>
<key>attrs</key>
<dict>
<key>foo b/ar</key>
<string>baz</string>
</dict>
<key>bool</key>
<true/>
<key>emptyattrs</key>
<dict>
</dict>
<key>emptylist</key>
<array>
</array>
<key>emptystring</key>
<string></string>
<key>float</key>
<real>0.133700</real>
<key>int</key>
<integer>42</integer>
<key>list</key>
<array>
<integer>3</integer>
<integer>4</integer>
<string>test</string>
</array>
<key>newlinestring</key>
<string>
</string>
<key>path</key>
<string>/foo</string>
<key>string</key>
<string>fn${o}"r\d</string>
</dict>
</dict>
</dict>
</plist>

View File

@@ -195,7 +195,7 @@ rec {
On each release the first letter is bumped and a new animal is chosen
starting with that new letter.
*/
codeName = "Tapir";
codeName = "Stoat";
/* Returns the current nixpkgs version suffix as string. */
versionSuffix =

View File

@@ -476,14 +476,6 @@ rec {
check = x: isDerivation x && hasAttr "shellPath" x;
};
pkgs = addCheck
(unique { message = "A Nixpkgs pkgs set can not be merged with another pkgs set."; } attrs // {
name = "pkgs";
descriptionClass = "noun";
description = "Nixpkgs package set";
})
(x: (x._type or null) == "pkgs");
path = mkOptionType {
name = "path";
descriptionClass = "noun";
@@ -704,7 +696,6 @@ rec {
, specialArgs ? {}
, shorthandOnlyDefinesConfig ? false
, description ? null
, class ? null
}@attrs:
let
inherit (lib.modules) evalModules;
@@ -716,7 +707,7 @@ rec {
) defs;
base = evalModules {
inherit class specialArgs;
inherit specialArgs;
modules = [{
# This is a work-around for the fact that some sub-modules,
# such as the one included in an attribute set, expects an "args"
@@ -771,16 +762,9 @@ rec {
functor = defaultFunctor name // {
type = types.submoduleWith;
payload = {
inherit modules class specialArgs shorthandOnlyDefinesConfig description;
inherit modules specialArgs shorthandOnlyDefinesConfig description;
};
binOp = lhs: rhs: {
class =
# `or null` was added for backwards compatibility only. `class` is
# always set in the current version of the module system.
if lhs.class or null == null then rhs.class or null
else if rhs.class or null == null then lhs.class or null
else if lhs.class or null == rhs.class then lhs.class or null
else throw "A submoduleWith option is declared multiple times with conflicting class values \"${toString lhs.class}\" and \"${toString rhs.class}\".";
modules = lhs.modules ++ rhs.modules;
specialArgs =
let intersecting = builtins.intersectAttrs lhs.specialArgs rhs.specialArgs;

File diff suppressed because it is too large Load Diff

View File

@@ -50,22 +50,19 @@ while (@ARGV) {
}
}
my $bucket;
if (not defined $ENV{DEBUG}) {
# S3 setup.
my $aws_access_key_id = $ENV{'AWS_ACCESS_KEY_ID'} or die "AWS_ACCESS_KEY_ID not set\n";
my $aws_secret_access_key = $ENV{'AWS_SECRET_ACCESS_KEY'} or die "AWS_SECRET_ACCESS_KEY not set\n";
# S3 setup.
my $aws_access_key_id = $ENV{'AWS_ACCESS_KEY_ID'} or die "AWS_ACCESS_KEY_ID not set\n";
my $aws_secret_access_key = $ENV{'AWS_SECRET_ACCESS_KEY'} or die "AWS_SECRET_ACCESS_KEY not set\n";
my $s3 = Net::Amazon::S3->new(
{ aws_access_key_id => $aws_access_key_id,
aws_secret_access_key => $aws_secret_access_key,
retry => 1,
host => "s3-eu-west-1.amazonaws.com",
});
my $s3 = Net::Amazon::S3->new(
{ aws_access_key_id => $aws_access_key_id,
aws_secret_access_key => $aws_secret_access_key,
retry => 1,
host => "s3-eu-west-1.amazonaws.com",
});
$bucket = $s3->bucket("nixpkgs-tarballs") or die;
}
my $bucket = $s3->bucket("nixpkgs-tarballs") or die;
my $doWrite = 0;
my $cacheFile = ($ENV{"HOME"} or die "\$HOME is not set") . "/.cache/nix/copy-tarballs";
@@ -162,18 +159,13 @@ elsif (defined $expr) {
# Check every fetchurl call discovered by find-tarballs.nix.
my $mirrored = 0;
my $have = 0;
foreach my $fetch (sort { $a->{urls}->[0] cmp $b->{urls}->[0] } @{$fetches}) {
my $urls = $fetch->{urls};
foreach my $fetch (sort { $a->{url} cmp $b->{url} } @{$fetches}) {
my $url = $fetch->{url};
my $algo = $fetch->{type};
my $hash = $fetch->{hash};
my $name = $fetch->{name};
my $isPatch = $fetch->{isPatch};
if ($isPatch) {
print STDERR "skipping $urls->[0] (support for patches is missing)\n";
next;
}
if ($hash =~ /^([a-z0-9]+)-([A-Za-z0-9+\/=]+)$/) {
$algo = $1;
$hash = `nix hash to-base16 $hash` or die;
@@ -188,60 +180,62 @@ elsif (defined $expr) {
chomp $hash;
}
if (defined $ENV{DEBUG}) {
print "$url $algo $hash\n";
next;
}
if ($url !~ /^http:/ && $url !~ /^https:/ && $url !~ /^ftp:/ && $url !~ /^mirror:/) {
print STDERR "skipping $url (unsupported scheme)\n";
next;
}
if ($isPatch) {
print STDERR "skipping $url (support for patches is missing)\n";
next;
}
next if defined $exclude && $url =~ /$exclude/;
if (alreadyMirrored($algo, $hash)) {
$have++;
next;
}
my $storePath = makeFixedOutputPath(0, $algo, $hash, $name);
for my $url (@$urls) {
if (defined $ENV{DEBUG}) {
print "$url $algo $hash\n";
next;
}
print STDERR "mirroring $url ($storePath, $algo, $hash)...\n";
if ($url !~ /^http:/ && $url !~ /^https:/ && $url !~ /^ftp:/ && $url !~ /^mirror:/) {
print STDERR "skipping $url (unsupported scheme)\n";
next;
}
next if defined $exclude && $url =~ /$exclude/;
if (alreadyMirrored($algo, $hash)) {
$have++;
last;
}
print STDERR "mirroring $url ($storePath, $algo, $hash)...\n";
if ($dryRun) {
$mirrored++;
last;
}
# Substitute the output.
if (!isValidPath($storePath)) {
system("nix-store", "-r", $storePath);
}
# Otherwise download the file using nix-prefetch-url.
if (!isValidPath($storePath)) {
$ENV{QUIET} = 1;
$ENV{PRINT_PATH} = 1;
my $fh;
my $pid = open($fh, "-|", "nix-prefetch-url", "--type", $algo, $url, $hash) or die;
waitpid($pid, 0) or die;
if ($? != 0) {
print STDERR "failed to fetch $url: $?\n";
next;
}
<$fh>; my $storePath2 = <$fh>; chomp $storePath2;
if ($storePath ne $storePath2) {
warn "strange: $storePath != $storePath2\n";
next;
}
}
uploadFile($storePath, $url);
if ($dryRun) {
$mirrored++;
last;
next;
}
# Substitute the output.
if (!isValidPath($storePath)) {
system("nix-store", "-r", $storePath);
}
# Otherwise download the file using nix-prefetch-url.
if (!isValidPath($storePath)) {
$ENV{QUIET} = 1;
$ENV{PRINT_PATH} = 1;
my $fh;
my $pid = open($fh, "-|", "nix-prefetch-url", "--type", $algo, $url, $hash) or die;
waitpid($pid, 0) or die;
if ($? != 0) {
print STDERR "failed to fetch $url: $?\n";
next;
}
<$fh>; my $storePath2 = <$fh>; chomp $storePath2;
if ($storePath ne $storePath2) {
warn "strange: $storePath != $storePath2\n";
next;
}
}
uploadFile($storePath, $url);
$mirrored++;
}
print STDERR "mirrored $mirrored files, already have $have files\n";

View File

@@ -9,12 +9,12 @@ let
root = expr;
uniqueFiles = map (x: x.file) (genericClosure {
startSet = map (file: { key = with file; (if type == null then "" else type + "+") + hash; inherit file; }) files;
uniqueUrls = map (x: x.file) (genericClosure {
startSet = map (file: { key = file.url; inherit file; }) urls;
operator = const [ ];
});
files = map (drv: { urls = drv.urls or [ drv.url ]; hash = drv.outputHash; isPatch = (drv?postFetch && drv.postFetch != ""); type = drv.outputHashAlgo; name = drv.name; }) fetchurlDependencies;
urls = map (drv: { url = head (drv.urls or [ drv.url ]); hash = drv.outputHash; isPatch = (drv?postFetch && drv.postFetch != ""); type = drv.outputHashAlgo; name = drv.name; }) fetchurlDependencies;
fetchurlDependencies =
filter
@@ -47,4 +47,4 @@ let
canEval = val: (builtins.tryEval val).success;
in uniqueFiles
in uniqueUrls

View File

@@ -32,6 +32,8 @@ EOF
sort -iu "$tmpfile" >> "$broken_config"
clear="env -u HOME -u NIXPKGS_CONFIG"
$clear maintainers/scripts/haskell/regenerate-hackage-packages.sh
$clear maintainers/scripts/haskell/regenerate-transitive-broken-packages.sh
$clear maintainers/scripts/haskell/regenerate-hackage-packages.sh
evalline=$(maintainers/scripts/haskell/hydra-report.hs eval-info)
if [[ "${1:-}" == "--do-commit" ]]; then

View File

@@ -53,10 +53,6 @@ if ! gh auth status 2>/dev/null ; then
die "You must setup the \`gh\` command. Run \`gh auth login\`."
fi
# Make sure this is configured before we start doing anything
push_remote="$(git config branch.haskell-updates.pushRemote \
|| die 'Can'\''t determine pushRemote for haskell-updates. Please set using `git config branch.haskell-updates.pushremote <remote name>`.')"
# Fetch nixpkgs to get an up-to-date origin/haskell-updates branch.
echo "Fetching origin..."
git fetch origin >/dev/null
@@ -89,12 +85,11 @@ echo "Updating Stackage..."
echo "Updating Hackage hashes..."
./maintainers/scripts/haskell/update-hackage.sh --do-commit
echo "Regenerating Hackage packages..."
# Using fast here because after the hackage-update eval errors will likely break the transitive dependencies check.
./maintainers/scripts/haskell/regenerate-hackage-packages.sh --fast --do-commit
./maintainers/scripts/haskell/regenerate-hackage-packages.sh --do-commit
# Push these new commits to the haskell-updates branch
echo "Pushing commits just created to the remote $push_remote/haskell-updates branch..."
git push "$push_remote" haskell-updates
echo "Pushing commits just created to the remote haskell-updates branch..."
git push
# Open new PR
new_pr_body=$(cat <<EOF

View File

@@ -1,69 +1,22 @@
#! /usr/bin/env nix-shell
#! nix-shell -i bash -p coreutils haskellPackages.cabal2nix-unstable git nix -I nixpkgs=.
# This script is used to regenerate nixpkgs' Haskell package set, using the
# tool hackage2nix from the nixos/cabal2nix repo. hackage2nix looks at the
# config files in pkgs/development/haskell-modules/configuration-hackage2nix
# and generates a Nix expression for package version specified there, using the
# Cabal files from the Hackage database (available under all-cabal-hashes) and
# its companion tool cabal2nix.
#
# Related scripts are update-hackage.sh, for updating the snapshot of the
# Hackage database used by hackage2nix, and update-cabal2nix-unstable.sh,
# for updating the version of hackage2nix used to perform this task.
#
# Note that this script doesn't gcroot anything, so it may be broken by an
# unfortunately timed nix-store --gc.
set -euo pipefail
self=$0
print_help () {
cat <<END_HELP
Usage: $self [options]
Options:
--do-commit Commit changes to this file.
-f | --fast Do not update the transitive-broken.yaml file.
-h | --help Show this help.
This script is used to regenerate nixpkgs' Haskell package set, using the
tool hackage2nix from the nixos/cabal2nix repo. hackage2nix looks at the
config files in pkgs/development/haskell-modules/configuration-hackage2nix
and generates a Nix expression for package version specified there, using the
Cabal files from the Hackage database (available under all-cabal-hashes) and
its companion tool cabal2nix.
Unless --fast is used, it will then use the generated nix expression by
running regenerate-transitive-broken-packages.sh which updates the transitive-broken.yaml
file. Then it re-runs hackage2nix.
Related scripts are update-hackage.sh, for updating the snapshot of the
Hackage database used by hackage2nix, and update-cabal2nix-unstable.sh,
for updating the version of hackage2nix used to perform this task.
Note that this script doesn't gcroot anything, so it may be broken by an
unfortunately timed nix-store --gc.
END_HELP
}
DO_COMMIT=0
REGENERATE_TRANSITIVE=1
options=$(getopt -o "fh" -l "help,fast,do-commit" -- "$@")
eval set -- "$options"
while true; do
case "$1" in
--do-commit)
DO_COMMIT=1
;;
-f|--fast)
REGENERATE_TRANSITIVE=0
;;
-h|--help)
print_help
exit 0
;;
--)
break;;
*)
print_help
exit 1
;;
esac
shift
done
HACKAGE2NIX="${HACKAGE2NIX:-hackage2nix}"
# To prevent hackage2nix fails because of encoding.
@@ -72,7 +25,14 @@ export LC_ALL=C.UTF-8
config_dir=pkgs/development/haskell-modules/configuration-hackage2nix
run_hackage2nix() {
echo "Obtaining Hackage data"
extraction_derivation='with import ./. {}; runCommandLocal "unpacked-cabal-hashes" { } "tar xf ${all-cabal-hashes} --strip-components=1 --one-top-level=$out"'
unpacked_hackage="$(nix-build -E "$extraction_derivation" --no-out-link)"
echo "Generating compiler configuration"
compiler_config="$(nix-build -A haskellPackages.cabal2nix-unstable.compilerConfig --no-out-link)"
echo "Starting hackage2nix to regenerate pkgs/development/haskell-modules/hackage-packages.nix ..."
"$HACKAGE2NIX" \
--hackage "$unpacked_hackage" \
--preferred-versions <(for n in "$unpacked_hackage"/*/preferred-versions; do cat "$n"; echo; done) \
@@ -82,33 +42,8 @@ run_hackage2nix() {
--config "$config_dir/stackage.yaml" \
--config "$config_dir/broken.yaml" \
--config "$config_dir/transitive-broken.yaml"
}
echo "Obtaining Hackage data …"
extraction_derivation='with import ./. {}; runCommandLocal "unpacked-cabal-hashes" { } "tar xf ${all-cabal-hashes} --strip-components=1 --one-top-level=$out"'
unpacked_hackage="$(nix-build -E "$extraction_derivation" --no-out-link)"
echo "Generating compiler configuration …"
compiler_config="$(nix-build -A haskellPackages.cabal2nix-unstable.compilerConfig --no-out-link)"
echo "Running hackage2nix to regenerate pkgs/development/haskell-modules/hackage-packages.nix …"
run_hackage2nix
if [[ "$REGENERATE_TRANSITIVE" -eq 1 ]]; then
echo "Regenerating transitive-broken.yaml … (pass --fast to $self to skip this step)"
maintainers/scripts/haskell/regenerate-transitive-broken-packages.sh
echo "Running hackage2nix again to reflect changes in transitive-broken.yaml …"
run_hackage2nix
fi
if [[ "$DO_COMMIT" -eq 1 ]]; then
git add pkgs/development/haskell-modules/configuration-hackage2nix/transitive-broken.yaml
if [[ "${1:-}" == "--do-commit" ]]; then
git add pkgs/development/haskell-modules/hackage-packages.nix
git commit -F - << EOF
haskellPackages: regenerate package set based on current config

View File

@@ -1,18 +1,9 @@
#! /usr/bin/env nix-shell
#! nix-shell -i bash -p coreutils jq nix -I nixpkgs=.
set -euo pipefail
TMP_TEMPLATE=transitive-broken.XXXXXXX
readonly TMP_TEMPLATE
tmpfile=$(mktemp "$TMP_TEMPLATE")
trap 'rm -f "${tmpfile}"' 0
config_file=pkgs/development/haskell-modules/configuration-hackage2nix/transitive-broken.yaml
cat > $tmpfile << EOF
cat > $config_file << EOF
# This file is automatically generated by
# maintainers/scripts/haskell/regenerate-transitive-broken-packages.sh
# It is supposed to list all haskellPackages that cannot evaluate because they
@@ -20,6 +11,5 @@ cat > $tmpfile << EOF
dont-distribute-packages:
EOF
nix-instantiate --eval --option restrict-eval true -I . --strict --json maintainers/scripts/haskell/transitive-broken-packages.nix | jq -r . | LC_ALL=C.UTF-8 sort -i >> $tmpfile
mv $tmpfile $config_file
echo "Regenerating list of transitive broken packages ..."
nix-instantiate --eval --option restrict-eval true -I . --strict --json maintainers/scripts/haskell/transitive-broken-packages.nix | jq -r . | LC_ALL=C.UTF-8 sort -i >> $config_file

View File

@@ -100,12 +100,11 @@ def convert_to_throw(date_older_list: list[str]) -> list[tuple[str, str]]:
date_older_list.remove(line)
continue
alias = before_equal
alias_unquoted = before_equal.strip('"')
alias = before_equal.strip()
after_equal_list = [x.strip(";:") for x in after_equal.split()]
converted = (
f"{indent}{alias} = throw \"'{alias_unquoted}' has been renamed to/replaced by"
f"{indent}{alias} = throw \"'{alias}' has been renamed to/replaced by"
f" '{after_equal_list.pop(0)}'\";"
f' # Converted to throw {datetime.today().strftime("%Y-%m-%d")}'
)

View File

@@ -149,17 +149,6 @@ with lib.maintainers; {
enableFeatureFreezePing = true;
};
cuda = {
members = [
connorbaker
samuela
SomeoneSerge
];
scope = "Maintain CUDA-enabled packages";
shortName = "Cuda";
githubTeams = [ "cuda-maintainers" ];
};
darwin = {
members = [
toonn
@@ -213,7 +202,7 @@ with lib.maintainers; {
dhall = {
members = [
Gabriella439
Gabriel439
ehmry
];
scope = "Maintain Dhall and related packages.";
@@ -292,8 +281,6 @@ with lib.maintainers; {
members = [
imincik
sikmir
nh2
willcohen
];
scope = "Maintain geospatial packages.";
shortName = "Geospatial";
@@ -385,6 +372,7 @@ with lib.maintainers; {
members = [
cleeyv
ryantm
yuka
];
scope = "Maintain Jitsi.";
shortName = "Jitsi";
@@ -524,7 +512,6 @@ with lib.maintainers; {
mate = {
members = [
bobby285271
j03
romildo
];
@@ -547,26 +534,6 @@ with lib.maintainers; {
shortName = "Matrix";
};
minimal-bootstrap = {
members = [
artturin
emilytrau
ericson2314
jk
];
scope = "Maintain the minimal-bootstrap toolchain and related packages.";
shortName = "Minimal Bootstrap";
};
mercury = {
members = [
_9999years
Gabriella439
];
scope = "Group registry for packages maintained by Mercury";
shortName = "Mercury Employees";
};
mobile = {
members = [
samueldr
@@ -604,6 +571,7 @@ with lib.maintainers; {
lilyinstarlight
marsam
winter
yuka
];
scope = "Maintain Node.js runtimes and build tooling.";
shortName = "Node.js";
@@ -850,7 +818,6 @@ with lib.maintainers; {
xfce = {
members = [
bobby285271
romildo
muscaln
];

View File

@@ -25,8 +25,6 @@ These include `pkgs.nixosTest`, `testing-python.nix` and `make-test-python.nix`.
## Testing changes to the test framework {#sec-test-the-test-framework}
We currently have limited unit tests for the framework itself. You may run these with `nix-build -A nixosTests.nixos-test-driver`.
When making significant changes to the test framework, we run the tests on Hydra, to avoid disrupting the larger NixOS project.
For this, we use the `python-test-refactoring` branch in the `NixOS/nixpkgs` repository, and its [corresponding Hydra jobset](https://hydra.nixos.org/jobset/nixos/python-test-refactoring).

View File

@@ -13,7 +13,7 @@ checking for entire option trees, it is only recommended for use in
submodules.
::: {#ex-freeform-module .example}
### Freeform submodule
**Example: Freeform submodule**
The following shows a submodule assigning a freeform type that allows
arbitrary attributes with `str` values below `settings`, but also

View File

@@ -77,7 +77,6 @@ The option's description is "Whether to enable \<name\>.".
For example:
::: {#ex-options-declarations-util-mkEnableOption-magic .example}
### `mkEnableOption` usage
```nix
lib.mkEnableOption (lib.mdDoc "magic")
# is like
@@ -127,7 +126,6 @@ During the transition to CommonMark documentation `mkPackageOption` creates an o
Examples:
::: {#ex-options-declarations-util-mkPackageOption-hello .example}
### Simple `mkPackageOption` usage
```nix
lib.mkPackageOptionMD pkgs "hello" { }
# is like
@@ -141,7 +139,6 @@ lib.mkOption {
:::
::: {#ex-options-declarations-util-mkPackageOption-ghc .example}
### `mkPackageOption` with explicit default and example
```nix
lib.mkPackageOptionMD pkgs "GHC" {
default = [ "ghc" ];
@@ -159,7 +156,6 @@ lib.mkOption {
:::
::: {#ex-options-declarations-util-mkPackageOption-extraDescription .example}
### `mkPackageOption` with additional description text
```nix
mkPackageOption pkgs [ "python39Packages" "pytorch" ] {
extraDescription = "This is an example and doesn't actually do anything.";
@@ -221,7 +217,7 @@ changing the main service module file and the type system automatically
enforces that there can only be a single display manager enabled.
::: {#ex-option-declaration-eot-service .example}
### Extensible type placeholder in the service module
**Example: Extensible type placeholder in the service module**
```nix
services.xserver.displayManager.enable = mkOption {
description = "Display manager to use";
@@ -231,7 +227,7 @@ services.xserver.displayManager.enable = mkOption {
:::
::: {#ex-option-declaration-eot-backend-gdm .example}
### Extending `services.xserver.displayManager.enable` in the `gdm` module
**Example: Extending `services.xserver.displayManager.enable` in the `gdm` module**
```nix
services.xserver.displayManager.enable = mkOption {
type = with types; nullOr (enum [ "gdm" ]);
@@ -240,7 +236,7 @@ services.xserver.displayManager.enable = mkOption {
:::
::: {#ex-option-declaration-eot-backend-sddm .example}
### Extending `services.xserver.displayManager.enable` in the `sddm` module
**Example: Extending `services.xserver.displayManager.enable` in the `sddm` module**
```nix
services.xserver.displayManager.enable = mkOption {
type = with types; nullOr (enum [ "sddm" ]);

View File

@@ -36,7 +36,7 @@ merging is handled.
together. This type is recommended when the option type is unknown.
::: {#ex-types-anything .example}
### `types.anything`
**Example: `types.anything` Example**
Two definitions of this type like
@@ -99,10 +99,6 @@ merging is handled.
problems.
:::
`types.pkgs`
: A type for the top level Nixpkgs package set.
### Numeric types {#sec-option-types-numeric}
`types.int`
@@ -360,7 +356,7 @@ you will still need to provide a default value (e.g. an empty attribute set)
if you want to allow users to leave it undefined.
::: {#ex-submodule-direct .example}
### Directly defined submodule
**Example: Directly defined submodule**
```nix
options.mod = mkOption {
description = "submodule example";
@@ -379,7 +375,7 @@ options.mod = mkOption {
:::
::: {#ex-submodule-reference .example}
### Submodule defined as a reference
**Example: Submodule defined as a reference**
```nix
let
modOptions = {
@@ -407,7 +403,7 @@ multiple definitions of the submodule option set
([Example: Definition of a list of submodules](#ex-submodule-listof-definition)).
::: {#ex-submodule-listof-declaration .example}
### Declaration of a list of submodules
**Example: Declaration of a list of submodules**
```nix
options.mod = mkOption {
description = "submodule example";
@@ -426,7 +422,7 @@ options.mod = mkOption {
:::
::: {#ex-submodule-listof-definition .example}
### Definition of a list of submodules
**Example: Definition of a list of submodules**
```nix
config.mod = [
{ foo = 1; bar = "one"; }
@@ -441,7 +437,7 @@ multiple named definitions of the submodule option set
([Example: Definition of attribute sets of submodules](#ex-submodule-attrsof-definition)).
::: {#ex-submodule-attrsof-declaration .example}
### Declaration of attribute sets of submodules
**Example: Declaration of attribute sets of submodules**
```nix
options.mod = mkOption {
description = "submodule example";
@@ -460,7 +456,7 @@ options.mod = mkOption {
:::
::: {#ex-submodule-attrsof-definition .example}
### Definition of attribute sets of submodules
**Example: Definition of attribute sets of submodules**
```nix
config.mod.one = { foo = 1; bar = "one"; };
config.mod.two = { foo = 2; bar = "two"; };
@@ -480,7 +476,7 @@ Types are mainly characterized by their `check` and `merge` functions.
([Example: Overriding a type check](#ex-extending-type-check-2)).
::: {#ex-extending-type-check-1 .example}
### Adding a type check
**Example: Adding a type check**
```nix
byte = mkOption {
@@ -491,7 +487,7 @@ Types are mainly characterized by their `check` and `merge` functions.
:::
::: {#ex-extending-type-check-2 .example}
### Overriding a type check
**Example: Overriding a type check**
```nix
nixThings = mkOption {

View File

@@ -143,7 +143,7 @@ These functions all return an attribute set with these values:
:::
::: {#ex-settings-nix-representable .example}
### Module with conventional `settings` option
**Example: Module with conventional `settings` option**
The following shows a module for an example program that uses a JSON
configuration file. It demonstrates how above values can be used, along
@@ -218,7 +218,7 @@ the port, which will enforce it to be a valid integer and make it show
up in the manual.
::: {#ex-settings-typed-attrs .example}
### Declaring a type-checked `settings` attribute
**Example: Declaring a type-checked `settings` attribute**
```nix
settings = lib.mkOption {
type = lib.types.submodule {

View File

@@ -37,7 +37,7 @@ options, but does not declare any. The structure of full NixOS modules
is shown in [Example: Structure of NixOS Modules](#ex-module-syntax).
::: {#ex-module-syntax .example}
### Structure of NixOS Modules
**Example: Structure of NixOS Modules**
```nix
{ config, pkgs, ... }:
@@ -100,7 +100,7 @@ Exec directives](#exec-escaping-example) for an example. When using these
functions system environment substitution should *not* be disabled explicitly.
::: {#locate-example .example}
### NixOS Module for the "locate" Service
**Example: NixOS Module for the "locate" Service**
```nix
{ config, lib, pkgs, ... }:
@@ -161,7 +161,7 @@ in {
:::
::: {#exec-escaping-example .example}
### Escaping in Exec directives
**Example: Escaping in Exec directives**
```nix
{ config, lib, pkgs, utils, ... }:

View File

@@ -130,11 +130,6 @@ starting them in parallel:
start_all()
```
If the hostname of a node contains characters that can't be used in a
Python variable name, those characters will be replaced with
underscores in the variable name, so `nodes.machine-a` will be exposed
to Python as `machine_a`.
## Machine objects {#ssec-machine-objects}
The following methods are available on machine objects:

View File

@@ -538,7 +538,7 @@ drive (here `/dev/sda`). [Example: NixOS Configuration](#ex-config) shows a
corresponding configuration Nix expression.
::: {#ex-partition-scheme-MBR .example}
### Example partition schemes for NixOS on `/dev/sda` (MBR)
**Example: Example partition schemes for NixOS on `/dev/sda` (MBR)**
```ShellSession
# parted /dev/sda -- mklabel msdos
# parted /dev/sda -- mkpart primary 1MB -8GB
@@ -547,7 +547,7 @@ corresponding configuration Nix expression.
:::
::: {#ex-partition-scheme-UEFI .example}
### Example partition schemes for NixOS on `/dev/sda` (UEFI)
**Example: Example partition schemes for NixOS on `/dev/sda` (UEFI)**
```ShellSession
# parted /dev/sda -- mklabel gpt
# parted /dev/sda -- mkpart primary 512MB -8GB
@@ -558,7 +558,7 @@ corresponding configuration Nix expression.
:::
::: {#ex-install-sequence .example}
### Commands for Installing NixOS on `/dev/sda`
**Example: Commands for Installing NixOS on `/dev/sda`**
With a partitioned disk.
@@ -578,7 +578,7 @@ With a partitioned disk.
:::
::: {#ex-config .example}
### Example: NixOS Configuration
**Example: NixOS Configuration**
```ShellSession
{ config, pkgs, ... }: {
imports = [

View File

@@ -6,7 +6,7 @@ expressions and associated binaries. The NixOS channels are updated
automatically from NixOS's Git repository after certain tests have
passed and all packages have been built. These channels are:
- *Stable channels*, such as [`nixos-23.05`](https://channels.nixos.org/nixos-23.05).
- *Stable channels*, such as [`nixos-22.11`](https://nixos.org/channels/nixos-22.11).
These only get conservative bug fixes and package upgrades. For
instance, a channel update may cause the Linux kernel on your system
to be upgraded from 4.19.34 to 4.19.38 (a minor bug fix), but not
@@ -14,13 +14,13 @@ passed and all packages have been built. These channels are:
Stable channels are generally maintained until the next stable
branch is created.
- The *unstable channel*, [`nixos-unstable`](https://channels.nixos.org/nixos-unstable).
- The *unstable channel*, [`nixos-unstable`](https://nixos.org/channels/nixos-unstable).
This corresponds to NixOS's main development branch, and may thus see
radical changes between channel updates. It's not recommended for
production systems.
- *Small channels*, such as [`nixos-23.05-small`](https://channels.nixos.org/nixos-23.05-small)
or [`nixos-unstable-small`](https://channels.nixos.org/nixos-unstable-small).
- *Small channels*, such as [`nixos-22.11-small`](https://nixos.org/channels/nixos-22.11-small)
or [`nixos-unstable-small`](https://nixos.org/channels/nixos-unstable-small).
These are identical to the stable and unstable channels described above,
except that they contain fewer binary packages. This means they get updated
faster than the regular channels (for instance, when a critical security patch
@@ -28,7 +28,7 @@ passed and all packages have been built. These channels are:
built from source than usual. They're mostly intended for server environments
and as such contain few GUI applications.
To see what channels are available, go to <https://channels.nixos.org>.
To see what channels are available, go to <https://nixos.org/channels>.
(Note that the URIs of the various channels redirect to a directory that
contains the channel's latest version and includes ISO images and
VirtualBox appliances.) Please note that during the release process,
@@ -38,38 +38,38 @@ newest supported stable release.
When you first install NixOS, you're automatically subscribed to the
NixOS channel that corresponds to your installation source. For
instance, if you installed from a 23.05 ISO, you will be subscribed to
the `nixos-23.05` channel. To see which NixOS channel you're subscribed
instance, if you installed from a 22.11 ISO, you will be subscribed to
the `nixos-22.11` channel. To see which NixOS channel you're subscribed
to, run the following as root:
```ShellSession
# nix-channel --list | grep nixos
nixos https://channels.nixos.org/nixos-unstable
nixos https://nixos.org/channels/nixos-unstable
```
To switch to a different NixOS channel, do
```ShellSession
# nix-channel --add https://channels.nixos.org/channel-name nixos
# nix-channel --add https://nixos.org/channels/channel-name nixos
```
(Be sure to include the `nixos` parameter at the end.) For instance, to
use the NixOS 23.05 stable channel:
use the NixOS 22.11 stable channel:
```ShellSession
# nix-channel --add https://channels.nixos.org/nixos-23.05 nixos
# nix-channel --add https://nixos.org/channels/nixos-22.11 nixos
```
If you have a server, you may want to use the "small" channel instead:
```ShellSession
# nix-channel --add https://channels.nixos.org/nixos-23.05-small nixos
# nix-channel --add https://nixos.org/channels/nixos-22.11-small nixos
```
And if you want to live on the bleeding edge:
```ShellSession
# nix-channel --add https://channels.nixos.org/nixos-unstable nixos
# nix-channel --add https://nixos.org/channels/nixos-unstable nixos
```
You can then upgrade NixOS to the latest version in your chosen channel
@@ -114,5 +114,5 @@ the new generation contains a different kernel, initrd or kernel
modules. You can also specify a channel explicitly, e.g.
```nix
system.autoUpgrade.channel = "https://channels.nixos.org/nixos-23.05";
system.autoUpgrade.channel = https://nixos.org/channels/nixos-22.11;
```

View File

@@ -17,7 +17,7 @@ In any manpage, commands, flags and arguments to the *current* executable should
- Use `Cm` to mark literal string arguments, e.g. the `boot` command argument passed to `nixos-rebuild`.
- Optional flags or arguments should be marked with `Op`. This includes optional repeating arguments.
- Required flags or arguments should not be marked.
- Mutually exclusive groups of arguments should be enclosed in curly brackets, preferably created with `Bro`/`Brc` blocks.
- Mutually exclusive groups of arguments should be enclosed in curly brackets, preferrably created with `Bro`/`Brc` blocks.
When an argument is used in an example it should be marked up with `Ar` again to differentiate it from a constant. For example, a command with a `--host name` flag that calls ssh to retrieve the host's local time would signify this thusly:
```
@@ -45,7 +45,7 @@ Larger code blocks or those that cannot be shown inline should use indented lite
...
.Ed
```
Contents of code blocks may be marked up further, e.g. if they refer to arguments that will be substituted into them:
Contents of code blocks may be marked up further, e.g. if they refer to arguments that will be subsituted into them:
```
.Bd -literal -offset indent
{

View File

@@ -4,7 +4,7 @@ This manual describes how to install, use and extend NixOS, a Linux distribution
Additional information regarding the Nix package manager and the Nixpkgs project can be found in respectively the [Nix manual](https://nixos.org/nix/manual) and the [Nixpkgs manual](https://nixos.org/nixpkgs/manual).
If you encounter problems, please report them on the [`Discourse`](https://discourse.nixos.org), the [Matrix room](https://matrix.to/#/%23nix:nixos.org), or on the [`#nixos` channel on Libera.Chat](irc://irc.libera.chat/#nixos). Alternatively, consider [contributing to this manual](#chap-contributing). Bugs should be reported in [NixOS GitHub issue tracker](https://github.com/NixOS/nixpkgs/issues).
If you encounter problems, please report them on the [`Discourse`](https://discourse.nixos.org), the [Matrix room](https://matrix.to/#nix:nixos.org), or on the [`#nixos` channel on Libera.Chat](irc://irc.libera.chat/#nixos). Alternatively, consider [contributing to this manual](#chap-contributing). Bugs should be reported in [NixOS GitHub issue tracker](https://github.com/NixOS/nixpkgs/issues).
::: {.note}
Commands prefixed with `#` have to be run as root, either requiring to login as root user or temporarily switching to it using `sudo` for example.

View File

@@ -3,7 +3,6 @@
This section lists the release notes for each stable version of NixOS and current unstable revision.
```{=include=} sections
rl-2311.section.md
rl-2305.section.md
rl-2211.section.md
rl-2205.section.md

View File

@@ -20,7 +20,7 @@ When upgrading from a previous release, please be aware of the following incompa
- A large number of packages have been converted to use the multiple outputs feature of Nix to greatly reduce the amount of required disk space, as mentioned above. This may require changes to any custom packages to make them build again; see the relevant chapter in the Nixpkgs manual for more information. (Additional caveat to packagers: some packaging conventions related to multiple-output packages [were changed](https://github.com/NixOS/nixpkgs/pull/14766) late (August 2016) in the release cycle and differ from the initial introduction of multiple outputs.)
- Previous versions of Nixpkgs had support for all versions of the LTS Haskell package set. That support has been dropped. The previously provided `haskell.packages.lts-x_y` package sets still exist in name to avoid breaking user code, but these package sets don't actually contain the versions mandated by the corresponding LTS release. Instead, our package set it loosely based on the latest available LTS release, i.e. LTS 7.x at the time of this writing. New releases of NixOS and Nixpkgs will drop those old names entirely. [The motivation for this change](https://nixos.org/nix-dev/2016-June/020585.html) has been discussed at length on the `nix-dev` mailing list and in [Github issue \#14897](https://github.com/NixOS/nixpkgs/issues/14897). Development strategies for Haskell hackers who want to rely on Nix and NixOS have been described in [another nix-dev article](https://nixos.org/nix-dev/2016-June/020642.html).
- Previous versions of Nixpkgs had support for all versions of the LTS Haskell package set. That support has been dropped. The previously provided `haskell.packages.lts-x_y` package sets still exist in name to aviod breaking user code, but these package sets don't actually contain the versions mandated by the corresponding LTS release. Instead, our package set it loosely based on the latest available LTS release, i.e. LTS 7.x at the time of this writing. New releases of NixOS and Nixpkgs will drop those old names entirely. [The motivation for this change](https://nixos.org/nix-dev/2016-June/020585.html) has been discussed at length on the `nix-dev` mailing list and in [Github issue \#14897](https://github.com/NixOS/nixpkgs/issues/14897). Development strategies for Haskell hackers who want to rely on Nix and NixOS have been described in [another nix-dev article](https://nixos.org/nix-dev/2016-June/020642.html).
- Shell aliases for systemd sub-commands [were dropped](https://github.com/NixOS/nixpkgs/pull/15598): `start`, `stop`, `restart`, `status`.
@@ -28,7 +28,7 @@ When upgrading from a previous release, please be aware of the following incompa
- `/var/empty` is now immutable. Activation script runs `chattr +i` to forbid any modifications inside the folder. See [ the pull request](https://github.com/NixOS/nixpkgs/pull/18365) for what bugs this caused.
- Gitlab's maintenance script `gitlab-runner` was removed and split up into the more clearer `gitlab-run` and `gitlab-rake` scripts, because `gitlab-runner` is a component of Gitlab CI.
- Gitlab's maintainance script `gitlab-runner` was removed and split up into the more clearer `gitlab-run` and `gitlab-rake` scripts, because `gitlab-runner` is a component of Gitlab CI.
- `services.xserver.libinput.accelProfile` default changed from `flat` to `adaptive`, as per [ official documentation](https://wayland.freedesktop.org/libinput/doc/latest/group__config.html#gad63796972347f318b180e322e35cee79).

View File

@@ -275,7 +275,7 @@ When upgrading from a previous release, please be aware of the following incompa
You can check that backups still work by running `systemctl start mysql-backup` then `systemctl status mysql-backup`.
- Templated systemd services e.g `container@name` are now handled correctly when switching to a new configuration, resulting in them being reloaded.
- Templated systemd services e.g `container@name` are now handled currectly when switching to a new configuration, resulting in them being reloaded.
- Steam: the `newStdcpp` parameter was removed and should not be needed anymore.

View File

@@ -174,7 +174,7 @@ When upgrading from a previous release, please be aware of the following incompa
- The `openssh` package now includes Kerberos support by default; the `openssh_with_kerberos` package is now a deprecated alias. If you do not want Kerberos support, you can do `openssh.override { withKerberos = false; }`. Note, this also applies to the `openssh_hpn` package.
- `cc-wrapper` has been split in two; there is now also a `bintools-wrapper`. The most commonly used files in `nix-support` are now split between the two wrappers. Some commonly used ones, like `nix-support/dynamic-linker`, are duplicated for backwards compatibility, even though they rightly belong only in `bintools-wrapper`. Other more obscure ones are just moved.
- `cc-wrapper` has been split in two; there is now also a `bintools-wrapper`. The most commonly used files in `nix-support` are now split between the two wrappers. Some commonly used ones, like `nix-support/dynamic-linker`, are duplicated for backwards compatability, even though they rightly belong only in `bintools-wrapper`. Other more obscure ones are just moved.
- The propagation logic has been changed. The new logic, along with new types of dependencies that go with, is thoroughly documented in the "Specifying dependencies" section of the "Standard Environment" chapter of the nixpkgs manual. The old logic isn't but is easy to describe: dependencies were propagated as the same type of dependency no matter what. In practice, that means that many `propagatedNativeBuildInputs` should instead be `propagatedBuildInputs`. Thankfully, that was and is the least used type of dependency. Also, it means that some `propagatedBuildInputs` should instead be `depsTargetTargetPropagated`. Other types dependencies should be unaffected.

View File

@@ -81,7 +81,7 @@ When upgrading from a previous release, please be aware of the following incompa
The slurmctld now runs as user `slurm` instead of `root`. If you want to keep slurmctld running as `root`, set `services.slurm.user = root`.
The options `services.slurm.nodeName` and `services.slurm.partitionName` are now sets of strings to correctly reflect that fact that each of these options can occur more than once in the configuration.
The options `services.slurm.nodeName` and `services.slurm.partitionName` are now sets of strings to correctly reflect that fact that each of these options can occour more than once in the configuration.
- The `solr` package has been upgraded from 4.10.3 to 7.5.0 and has undergone some major changes. The `services.solr` module has been updated to reflect these changes. Please review http://lucene.apache.org/solr/ carefully before upgrading.
@@ -91,7 +91,7 @@ When upgrading from a previous release, please be aware of the following incompa
- Network interface indiscriminate NixOS firewall options (`networking.firewall.allow*`) are now preserved when also setting interface specific rules such as `networking.firewall.interfaces.en0.allow*`. These rules continue to use the pseudo device "default" (`networking.firewall.interfaces.default.*`), and assigning to this pseudo device will override the (`networking.firewall.allow*`) options.
- The `nscd` service now disables all caching of `passwd` and `group` databases by default. This was interfering with the correct functioning of the `libnss_systemd.so` module which is used by `systemd` to manage uids and usernames in the presence of `DynamicUser=` in systemd services. This was already the default behaviour in presence of `services.sssd.enable = true` because nscd caching would interfere with `sssd` in unpredictable ways as well. Because we're using nscd not for caching, but for convincing glibc to find NSS modules in the nix store instead of an absolute path, we have decided to disable caching globally now, as it's usually not the behaviour the user wants and can lead to surprising behaviour. Furthermore, negative caching of host lookups is also disabled now by default. This should fix the issue of dns lookups failing in the presence of an unreliable network.
- The `nscd` service now disables all caching of `passwd` and `group` databases by default. This was interferring with the correct functioning of the `libnss_systemd.so` module which is used by `systemd` to manage uids and usernames in the presence of `DynamicUser=` in systemd services. This was already the default behaviour in presence of `services.sssd.enable = true` because nscd caching would interfere with `sssd` in unpredictable ways as well. Because we're using nscd not for caching, but for convincing glibc to find NSS modules in the nix store instead of an absolute path, we have decided to disable caching globally now, as it's usually not the behaviour the user wants and can lead to surprising behaviour. Furthermore, negative caching of host lookups is also disabled now by default. This should fix the issue of dns lookups failing in the presence of an unreliable network.
If the old behaviour is desired, this can be restored by setting the `services.nscd.config` option with the desired caching parameters.
@@ -135,7 +135,7 @@ When upgrading from a previous release, please be aware of the following incompa
- GitLab Shell previously used the nix store paths for the `gitlab-shell` command in its `authorized_keys` file, which might stop working after garbage collection. To circumvent that, we regenerated that file on each startup. As `gitlab-shell` has now been changed to use `/var/run/current-system/sw/bin/gitlab-shell`, this is not necessary anymore, but there might be leftover lines with a nix store path. Regenerate the `authorized_keys` file via `sudo -u git -H gitlab-rake gitlab:shell:setup` in that case.
- The `pam_unix` account module is now loaded with its control field set to `required` instead of `sufficient`, so that later PAM account modules that might do more extensive checks are being executed. Previously, the whole account module verification was exited prematurely in case a nss module provided the account name to `pam_unix`. The LDAP and SSSD NixOS modules already add their NSS modules when enabled. In case your setup breaks due to some later PAM account module previously shadowed, or failing NSS lookups, please file a bug. You can get back the old behaviour by manually setting `security.pam.services.<name?>.text`.
- The `pam_unix` account module is now loaded with its control field set to `required` instead of `sufficient`, so that later PAM account modules that might do more extensive checks are being executed. Previously, the whole account module verification was exited prematurely in case a nss module provided the account name to `pam_unix`. The LDAP and SSSD NixOS modules already add their NSS modules when enabled. In case your setup breaks due to some later PAM account module previosuly shadowed, or failing NSS lookups, please file a bug. You can get back the old behaviour by manually setting `security.pam.services.<name?>.text`.
- The `pam_unix` password module is now loaded with its control field set to `sufficient` instead of `required`, so that password managed only by later PAM password modules are being executed. Previously, for example, changing an LDAP account's password through PAM was not possible: the whole password module verification was exited prematurely by `pam_unix`, preventing `pam_ldap` to manage the password as it should.

View File

@@ -194,7 +194,7 @@ When upgrading from a previous release, please be aware of the following incompa
`security.acme.preDelay` and `security.acme.activationDelay` options have been removed. To execute a service before certificates are provisioned or renewed add a `RequiredBy=acme-${cert}.service` to any service.
Furthermore, the acme module will not automatically add a dependency on `lighttpd.service` anymore. If you are using certificates provided by letsencrypt for lighttpd, then you should depend on the certificate service `acme-${cert}.service>` manually.
Furthermore, the acme module will not automatically add a dependency on `lighttpd.service` anymore. If you are using certficates provided by letsencrypt for lighttpd, then you should depend on the certificate service `acme-${cert}.service>` manually.
For nginx, the dependencies are still automatically managed when `services.nginx.virtualhosts.<name>.enableACME` is enabled just like before. What changed is that nginx now directly depends on the specific certificates that it needs, instead of depending on the catch-all `acme-certificates.target`. This target unit was also removed from the codebase. This will mean nginx will no longer depend on certificates it isn't explicitly managing and fixes a bug with certificate renewal ordering racing with nginx restarting which could lead to nginx getting in a broken state as described at [NixOS/nixpkgs\#60180](https://github.com/NixOS/nixpkgs/issues/60180).

View File

@@ -130,7 +130,7 @@ In addition to 1119 new, 118 updated, and 476 removed options; 61 new modules we
- [services.cage.enable](options.html#opt-services.cage.enable) Wayland cage service
- [services.convos.enable](options.html#opt-services.convos.enable) IRC daemon, which can be accessed through the browser
- [services.convos.enable](options.html#opt-services.convos.enable) IRC daemon, which can be accessed throught the browser
- [services.engelsystem.enable](options.html#opt-services.engelsystem.enable) Tool for coordinating volunteers and shifts on large events
@@ -552,7 +552,7 @@ When upgrading from a previous release, please be aware of the following incompa
- The [jellyfin](options.html#opt-services.jellyfin.enable) module will use and stay on the Jellyfin version `10.5.5` if `stateVersion` is lower than `20.09`. This is because significant changes were made to the database schema, and it is highly recommended to backup your instance before upgrading. After making your backup, you can upgrade to the latest version either by setting your `stateVersion` to `20.09` or higher, or set the `services.jellyfin.package` to `pkgs.jellyfin`. If you do not wish to upgrade Jellyfin, but want to change your `stateVersion`, you can set the value of `services.jellyfin.package` to `pkgs.jellyfin_10_5`.
- The `security.rngd` service is now disabled by default. This choice was made because there's krngd in the linux kernel space making it (for most usecases) functionally redundant.
- The `security.rngd` service is now disabled by default. This choice was made because there's krngd in the linux kernel space making it (for most usecases) functionally redundent.
- The `hardware.nvidia.optimus_prime.enable` service has been renamed to `hardware.nvidia.prime.sync.enable` and has many new enhancements. Related nvidia prime settings may have also changed.

View File

@@ -197,7 +197,7 @@ When upgrading from a previous release, please be aware of the following incompa
Android packages are now loaded from a repo.json file created by parsing Android repo XML files. The arguments `repoJson` and `repoXmls` have been added to allow overriding the built-in androidenv repo.json with your own. Additionally, license files are now written to allow compatibility with Gradle-based tools, and the `extraLicenses` argument has been added to accept more SDK licenses if your project requires it. See the androidenv documentation for more details.
- The attribute `mpi` is now consistently used to provide a default, system-wide MPI implementation. The default implementation is openmpi, which has been used before by all derivations affects by this change. Note that all packages that have used `mpi ? null` in the input for optional MPI builds, have been changed to the boolean input parameter `useMpi` to enable building with MPI. Building all packages with `mpich` instead of the default `openmpi` can now be achieved like this:
- The attribute `mpi` is now consistently used to provide a default, system-wide MPI implementation. The default implementation is openmpi, which has been used before by all derivations affects by this change. Note that all packages that have used `mpi ? null` in the input for optional MPI builds, have been changed to the boolean input paramater `useMpi` to enable building with MPI. Building all packages with `mpich` instead of the default `openmpi` can now be achived like this:
```nix
self: super:
@@ -272,7 +272,7 @@ When upgrading from a previous release, please be aware of the following incompa
- `environment.defaultPackages` now includes the nano package. If pkgs.nano is not added to the list, make sure another editor is installed and the `EDITOR` environment variable is set to it. Environment variables can be set using `environment.variables`.
- `services.minio.dataDir` changed type to a list of paths, required for specifying multiple data directories for using with erasure coding. Currently, the service doesn't enforce nor checks the correct number of paths to correspond to minio requirements.
- `services.minio.dataDir` changed type to a list of paths, required for specifiyng multiple data directories for using with erasure coding. Currently, the service doesn't enforce nor checks the correct number of paths to correspond to minio requirements.
- All CUDA toolkit versions prior to CUDA 10 have been removed.
@@ -375,7 +375,7 @@ When upgrading from a previous release, please be aware of the following incompa
- When defining a new user, one of [users.users._name_.isNormalUser](options.html#opt-users.users._name_.isNormalUser) and [users.users._name_.isSystemUser](options.html#opt-users.users._name_.isSystemUser) is now required. This is to prevent accidentally giving a UID above 1000 to system users, which could have unexpected consequences, like running user activation scripts for system users. Note that users defined with an explicit UID below 500 are exempted from this check, as [users.users._name_.isSystemUser](options.html#opt-users.users._name_.isSystemUser) has no effect for those.
- The `security.apparmor` module, for the [AppArmor](https://gitlab.com/apparmor/apparmor/-/wikis/Documentation) Mandatory Access Control system, has been substantially improved along with related tools, so that module maintainers can now more easily write AppArmor profiles for NixOS. The most notable change on the user-side is the new option [security.apparmor.policies](options.html#opt-security.apparmor.policies), replacing the previous `profiles` option to provide a way to disable a profile and to select whether to confine in enforce mode (default) or in complain mode (see `journalctl -b --grep apparmor`). Security-minded users may also want to enable [security.apparmor.killUnconfinedConfinables](options.html#opt-security.apparmor.killUnconfinedConfinables), at the cost of having some of their processes killed when updating to a NixOS version introducing new AppArmor profiles.
- The `security.apparmor` module, for the [AppArmor](https://gitlab.com/apparmor/apparmor/-/wikis/Documentation) Mandatory Access Control system, has been substantialy improved along with related tools, so that module maintainers can now more easily write AppArmor profiles for NixOS. The most notable change on the user-side is the new option [security.apparmor.policies](options.html#opt-security.apparmor.policies), replacing the previous `profiles` option to provide a way to disable a profile and to select whether to confine in enforce mode (default) or in complain mode (see `journalctl -b --grep apparmor`). Security-minded users may also want to enable [security.apparmor.killUnconfinedConfinables](options.html#opt-security.apparmor.killUnconfinedConfinables), at the cost of having some of their processes killed when updating to a NixOS version introducing new AppArmor profiles.
- The GNOME desktop manager once again installs gnome.epiphany by default.

View File

@@ -375,7 +375,7 @@ In addition to numerous new and upgraded packages, this release has the followin
- `programs.neovim.runtime` switched to a `linkFarm` internally, making it impossible to use wildcards in the `source` argument.
- The `openrazer` and `openrazer-daemon` packages as well as the `hardware.openrazer` module now require users to be members of the `openrazer` group instead of `plugdev`. With this change, users no longer need be granted the entire set of `plugdev` group permissions, which can include permissions other than those required by `openrazer`. This is desirable from a security point of view. The setting [`hardware.openrazer.users`](options.html#opt-services.hardware.openrazer.users) can be used to add users to the `openrazer` group.
- The `openrazer` and `openrazer-daemon` packages as well as the `hardware.openrazer` module now require users to be members of the `openrazer` group instead of `plugdev`. With this change, users no longer need be granted the entire set of `plugdev` group permissions, which can include permissions other than those required by `openrazer`. This is desirable from a security point of view. The setting [`harware.openrazer.users`](options.html#opt-services.hardware.openrazer.users) can be used to add users to the `openrazer` group.
- The fontconfig service's dpi option has been removed.
Fontconfig should use Xft settings by default so there's no need to override one value in multiple places.

View File

@@ -10,7 +10,7 @@ In addition to numerous new and upgraded packages, this release has the followin
for Flakes, but also marks the `nix` command as experimental which now has to
be enabled via the configuration explicitly. For more information and
instructions for upgrades, see the
release notes for [nix-2.4](https://nixos.org/manual/nix/stable/release-notes/rl-2.4.html),
relase notes for [nix-2.4](https://nixos.org/manual/nix/stable/release-notes/rl-2.4.html),
[nix-2.5](https://nixos.org/manual/nix/stable/release-notes/rl-2.5.html),
[nix-2.6](https://nixos.org/manual/nix/stable/release-notes/rl-2.6.html),
[nix-2.7](https://nixos.org/manual/nix/stable/release-notes/rl-2.7.html) and
@@ -278,11 +278,11 @@ In addition to numerous new and upgraded packages, this release has the followin
- `openldap` (and therefore the slapd LDAP server) were updated to version 2.6.2. The project introduced backwards-incompatible changes, namely the removal of the bdb, hdb, ndb, and shell backends in slapd. Therefore before updating, dump your database `slapcat -n 1` in LDIF format, and reimport it after updating your `services.openldap.settings`, which represents your `cn=config`.
Additionally with 2.5 the argon2 module was included in the standard distribution and renamed from `pw-argon2` to `argon2`. Remember to update your `olcModuleLoad` entry in `cn=config`.
Additionally with 2.5 the argon2 module was included in the standard distrubtion and renamed from `pw-argon2` to `argon2`. Remember to update your `olcModuleLoad` entry in `cn=config`.
- `openssh` has been update to 8.9p1, changing the FIDO security key middleware interface.
- `git` no longer hardcodes the path to openssh' ssh binary to reduce the amount of rebuilds. If you are using git with ssh remotes and do not have a ssh binary in your environment consider adding `openssh` to it or switching to `gitFull`.
- `git` no longer hardcodes the path to openssh' ssh binary to reduce the amount of rebuilds. If you are using git with ssh remotes and do not have a ssh binary in your enviroment consider adding `openssh` to it or switching to `gitFull`.
- `services.k3s.enable` no longer implies `systemd.enableUnifiedCgroupHierarchy = false`, and will default to the 'systemd' cgroup driver when using `services.k3s.docker = true`.
This change may require a reboot to take effect, and k3s may not be able to run if the boot cgroup hierarchy does not match its configuration.
@@ -639,7 +639,7 @@ In addition to numerous new and upgraded packages, this release has the followin
changes in the database scheme and configuration format.
- Some top-level settings under [services.epgstation](#opt-services.epgstation.enable)
is now deprecated because it was redundant due to the same options being
is now deprecated because it was redudant due to the same options being
present in [services.epgstation.settings](#opt-services.epgstation.settings).
- The option `services.epgstation.basicAuth` was removed because basic
@@ -653,7 +653,7 @@ In addition to numerous new and upgraded packages, this release has the followin
option now expects options for `config.yml` in EPGStation v2.
- Existing data for the [services.epgstation](#opt-services.epgstation.enable)
module would have to be backed up prior to the upgrade. To back up existing
module would have to be backed up prior to the upgrade. To back up exising
data to `/tmp/epgstation.bak`, run
`sudo -u epgstation epgstation run backup /tmp/epgstation.bak`.
To import that data after to the upgrade, run
@@ -804,7 +804,7 @@ In addition to numerous new and upgraded packages, this release has the followin
- The `influxdb2` package was split into `influxdb2-server` and
`influxdb2-cli`, matching the split that took place upstream. A
combined `influxdb2` package is still provided in this release for
backwards compatibility, but will be removed at a later date.
backwards compatibilty, but will be removed at a later date.
- The `unifi` package was switched from `unifi6` to `unifi7`.
Direct downgrades from Unifi 7 to Unifi 6 are not possible and require restoring from a backup made by Unifi 6.

View File

@@ -205,7 +205,7 @@ In addition to numerous new and upgraded packages, this release includes the fol
- Linux 4.9 has been removed because it will reach its end of life within the lifespan of 22.11.
- (Neo)Vim can not be configured with `configure.pathogen` anymore to reduce maintenance burden.
- (Neo)Vim can not be configured with `configure.pathogen` anymore to reduce maintainance burden.
Use `configure.packages` instead.
- Neovim can not be configured with plug anymore (still works for vim).
@@ -221,7 +221,7 @@ In addition to numerous new and upgraded packages, this release includes the fol
- `mysql57` has been removed. Please update to `mysql80` or `mariadb`. See the [upgrade guide](https://mariadb.com/kb/en/upgrading-from-mysql-to-mariadb/) for more information.
- Consequently, `cqrlog` and `amorok` now use `mariadb` instead of `mysql57` for their embedded databases. Running `mysql_upgrade` may be necessary.
- Consequently, `cqrlog` and `amorok` now use `mariadb` instead of `mysql57` for their embedded databases. Running `mysql_upgrade` may be neccesary.
- `k3s` supports `clusterInit` option, and it is enabled by default, for servers.
- `percona-server56` has been removed. Please migrate to `mysql` or `mariadb` if possible.

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