···1+# Checks pkgs/by-name (see pkgs/by-name/README.md)
2+# using the nixpkgs-check-by-name tool (see pkgs/test/nixpkgs-check-by-name)
3+name: Check pkgs/by-name
4+5+# The pre-built tool is fetched from a channel,
6+# making it work predictable on all PRs
7+on: pull_request
8+9+# The tool doesn't need any permissions, it only outputs success or not based on the checkout
10+permissions: {}
11+12+jobs:
13+ check:
14+ # This is x86_64-linux, for which the tool is always prebuilt on the nixos-* channels,
15+ # as specified in nixos/release-combined.nix
16+ runs-on: ubuntu-latest
17+ steps:
18+ - uses: actions/checkout@v3
19+ - uses: cachix/install-nix-action@v22
20+ - name: Determining channel to use for dependencies
21+ run: |
22+ echo "Determining which channel to use for PR base branch $GITHUB_BASE_REF"
23+ if [[ "$GITHUB_BASE_REF" =~ ^(release|staging|staging-next)-([0-9][0-9]\.[0-9][0-9])$ ]]; then
24+ # Use the release channel for all PRs to release-XX.YY, staging-XX.YY and staging-next-XX.YY
25+ channel=nixos-${BASH_REMATCH[2]}
26+ echo "PR is for a release branch, using release channel $channel"
27+ else
28+ # Use the nixos-unstable channel for all other PRs
29+ channel=nixos-unstable
30+ echo "PR is for a non-release branch, using unstable channel $channel"
31+ fi
32+ echo "channel=$channel" >> "$GITHUB_ENV"
33+ - name: Fetching latest version of channel
34+ run: |
35+ echo "Fetching latest version of channel $channel"
36+ # This is probably the easiest way to get Nix to output the path to a downloaded channel!
37+ nixpkgs=$(nix-instantiate --find-file nixpkgs -I nixpkgs=channel:"$channel")
38+ # This file only exists in channels
39+ rev=$(<"$nixpkgs"/.git-revision)
40+ echo "Channel $channel is at revision $rev"
41+ echo "nixpkgs=$nixpkgs" >> "$GITHUB_ENV"
42+ echo "rev=$rev" >> "$GITHUB_ENV"
43+ - name: Fetching pre-built nixpkgs-check-by-name from the channel
44+ run: |
45+ echo "Fetching pre-built nixpkgs-check-by-name from channel $channel at revision $rev"
46+ # Passing --max-jobs 0 makes sure that we won't build anything
47+ nix-build "$nixpkgs" -A tests.nixpkgs-check-by-name --max-jobs 0
48+ - name: Running nixpkgs-check-by-name
49+ run: result/bin/nixpkgs-check-by-name .
+6
maintainers/maintainer-list.nix
···12885 githubId = 915970;
12886 name = "Austin Platt";
12887 };
00000012888 ony = {
12889 name = "Mykola Orliuk";
12890 email = "virkony@gmail.com";
···49 # Wait for lxd to settle
50 machine.succeed("lxd waitready")
5100052 machine.succeed("lxd init --minimal")
5354 machine.succeed(
···49 # Wait for lxd to settle
50 machine.succeed("lxd waitready")
5152+ # no preseed should mean no service
53+ machine.fail("systemctl status lxd-preseed.service")
54+55 machine.succeed("lxd init --minimal")
5657 machine.succeed(
+3-1
nixos/tests/lxd/default.nix
···2 system ? builtins.currentSystem,
3 config ? {},
4 pkgs ? import ../../.. {inherit system config;},
05}: {
6 container = import ./container.nix {inherit system pkgs;};
7 nftables = import ./nftables.nix {inherit system pkgs;};
08 ui = import ./ui.nix {inherit system pkgs;};
9- virtual-machine = import ./virtual-machine.nix { inherit system pkgs; };
10}
···2 system ? builtins.currentSystem,
3 config ? {},
4 pkgs ? import ../../.. {inherit system config;},
5+ handleTestOn,
6}: {
7 container = import ./container.nix {inherit system pkgs;};
8 nftables = import ./nftables.nix {inherit system pkgs;};
9+ preseed = import ./preseed.nix {inherit system pkgs;};
10 ui = import ./ui.nix {inherit system pkgs;};
11+ virtual-machine = handleTestOn ["x86_64-linux"] ./virtual-machine.nix { inherit system pkgs; };
12}
···78- [`top-level`](./top-level): Entrypoints, package set aggregations
9 - [`impure.nix`](./top-level/impure.nix), [`default.nix`](./top-level/default.nix), [`config.nix`](./top-level/config.nix): Definitions for the evaluation entry point of `import <nixpkgs>`
10- - [`stage.nix`](./top-level/stage.nix), [`all-packages.nix`](./top-level/all-packages.nix), [`splice.nix`](./top-level/splice.nix): Definitions for the top-level attribute set made available through `import <nixpkgs> {…}`
11 - `*-packages.nix`, [`linux-kernels.nix`](./top-level/linux-kernels.nix), [`unixtools.nix`](./top-level/unixtools.nix): Aggregations of nested package sets defined in `development`
12 - [`aliases.nix`](./top-level/aliases.nix), [`python-aliases.nix`](./top-level/python-aliases.nix): Aliases for package definitions that have been renamed or removed
13 - `release*.nix`, [`make-tarball.nix`](./top-level/make-tarball.nix), [`packages-config.nix`](./top-level/packages-config.nix), [`metrics.nix`](./top-level/metrics.nix), [`nixpkgs-basic-release-checks.nix`](./top-level/nixpkgs-basic-release-checks.nix): Entry-points and utilities used by Hydra for continuous integration
···19- [`stdenv`](./stdenv): [Standard environment](https://nixos.org/manual/nixpkgs/stable/#part-stdenv)
20- [`pkgs-lib`](./pkgs-lib): Definitions for utilities that need packages but are not needed for packages
21- [`test`](./test): Tests not directly associated with any specific packages
022- All other directories loosely categorise top-level packages definitions, see [category hierarchy][categories]
2324## Quick Start to Adding a Package
···49 $ cd nixpkgs
50 ```
5152-2. Find a good place in the Nixpkgs tree to add the Nix expression for your package. For instance, a library package typically goes into `pkgs/development/libraries/pkgname`, while a web browser goes into `pkgs/applications/networking/browsers/pkgname`. See the [category hierarchy section][categories] for some hints on the tree organisation. Create a directory for your package, e.g.
5354 ```ShellSession
55- $ mkdir pkgs/development/libraries/libfoo
56 ```
5758-3. In the package directory, create a Nix expression — a piece of code that describes how to build the package. In this case, it should be a _function_ that is called with the package dependencies as arguments, and returns a build of the package in the Nix store. The expression should usually be called `default.nix`.
005960 ```ShellSession
61- $ emacs pkgs/development/libraries/libfoo/default.nix
62- $ git add pkgs/development/libraries/libfoo/default.nix
63 ```
6465- You can have a look at the existing Nix expressions under `pkgs/` to see how it’s done. Here are some good ones:
06667- - GNU Hello: [`pkgs/applications/misc/hello/default.nix`](applications/misc/hello/default.nix). Trivial package, which specifies some `meta` attributes which is good practice.
6869 - GNU cpio: [`pkgs/tools/archivers/cpio/default.nix`](tools/archivers/cpio/default.nix). Also a simple package. The generic builder in `stdenv` does everything for you. It has no dependencies beyond `stdenv`.
70···9495 The exact syntax and semantics of the Nix expression language, including the built-in function, are [described in the Nix manual](https://nixos.org/manual/nix/stable/language/).
9697-4. Add a call to the function defined in the previous step to [`pkgs/top-level/all-packages.nix`](top-level/all-packages.nix) with some descriptive name for the variable, e.g. `libfoo`.
98-99- ```ShellSession
100- $ emacs pkgs/top-level/all-packages.nix
101- ```
102-103- The attributes in that file are sorted by category (like “Development / Libraries”) that more-or-less correspond to the directory structure of Nixpkgs, and then by attribute name.
104-1055. To test whether the package builds, run the following command from the root of the nixpkgs source tree:
106107 ```ShellSession
108- $ nix-build -A libfoo
109 ```
110111- where `libfoo` should be the variable name defined in the previous step. You may want to add the flag `-K` to keep the temporary build directory in case something fails. If the build succeeds, a symlink `./result` to the package in the Nix store is created.
1121136. If you want to install the package into your profile (optional), do
114···121## Category Hierarchy
122[categories]: #category-hierarchy
123124-Each package should be stored in its own directory somewhere in the `pkgs/` tree, i.e. in `pkgs/category/subcategory/.../pkgname`. Below are some rules for picking the right category for a package. Many packages fall under several categories; what matters is the _primary_ purpose of a package. For example, the `libxml2` package builds both a library and some tools; but it’s a library foremost, so it goes under `pkgs/development/libraries`.
000000000125126-When in doubt, consider refactoring the `pkgs/` tree, e.g. creating new categories or splitting up an existing category.
0127128**If it’s used to support _software development_:**
129···298**Else:**
299300- `misc`
00301302# Conventions
303
···78- [`top-level`](./top-level): Entrypoints, package set aggregations
9 - [`impure.nix`](./top-level/impure.nix), [`default.nix`](./top-level/default.nix), [`config.nix`](./top-level/config.nix): Definitions for the evaluation entry point of `import <nixpkgs>`
10+ - [`stage.nix`](./top-level/stage.nix), [`all-packages.nix`](./top-level/all-packages.nix), [`by-name-overlay.nix`](./top-level/by-name-overlay.nix), [`splice.nix`](./top-level/splice.nix): Definitions for the top-level attribute set made available through `import <nixpkgs> {…}`
11 - `*-packages.nix`, [`linux-kernels.nix`](./top-level/linux-kernels.nix), [`unixtools.nix`](./top-level/unixtools.nix): Aggregations of nested package sets defined in `development`
12 - [`aliases.nix`](./top-level/aliases.nix), [`python-aliases.nix`](./top-level/python-aliases.nix): Aliases for package definitions that have been renamed or removed
13 - `release*.nix`, [`make-tarball.nix`](./top-level/make-tarball.nix), [`packages-config.nix`](./top-level/packages-config.nix), [`metrics.nix`](./top-level/metrics.nix), [`nixpkgs-basic-release-checks.nix`](./top-level/nixpkgs-basic-release-checks.nix): Entry-points and utilities used by Hydra for continuous integration
···19- [`stdenv`](./stdenv): [Standard environment](https://nixos.org/manual/nixpkgs/stable/#part-stdenv)
20- [`pkgs-lib`](./pkgs-lib): Definitions for utilities that need packages but are not needed for packages
21- [`test`](./test): Tests not directly associated with any specific packages
22+- [`by-name`](./by-name): Top-level packages organised by name ([docs](./by-name/README.md))
23- All other directories loosely categorise top-level packages definitions, see [category hierarchy][categories]
2425## Quick Start to Adding a Package
···50 $ cd nixpkgs
51 ```
5253+2. Create a package directory `pkgs/by-name/so/some-package` where `some-package` is the package name and `so` is the lowercased 2-letter prefix of the package name:
5455 ```ShellSession
56+ $ mkdir -p pkgs/by-name/so/some-package
57 ```
5859+ For more detailed information, see [here](./by-name/README.md).
60+61+3. Create a `package.nix` file in the package directory, containing a Nix expression — a piece of code that describes how to build the package. In this case, it should be a _function_ that is called with the package dependencies as arguments, and returns a build of the package in the Nix store.
6263 ```ShellSession
64+ $ emacs pkgs/by-name/so/some-package/package.nix
65+ $ git add pkgs/by-name/so/some-package/package.nix
66 ```
6768+ You can have a look at the existing Nix expressions under `pkgs/` to see how it’s done, some of which are also using the [category hierarchy](#category-hierarchy).
69+ Here are some good ones:
7071+ - GNU Hello: [`pkgs/by-name/he/hello/package.nix`](./by-name/he/hello/package.nix). Trivial package, which specifies some `meta` attributes which is good practice.
7273 - GNU cpio: [`pkgs/tools/archivers/cpio/default.nix`](tools/archivers/cpio/default.nix). Also a simple package. The generic builder in `stdenv` does everything for you. It has no dependencies beyond `stdenv`.
74···9899 The exact syntax and semantics of the Nix expression language, including the built-in function, are [described in the Nix manual](https://nixos.org/manual/nix/stable/language/).
100000000001015. To test whether the package builds, run the following command from the root of the nixpkgs source tree:
102103 ```ShellSession
104+ $ nix-build -A some-package
105 ```
106107+ where `some-package` should be the package name. You may want to add the flag `-K` to keep the temporary build directory in case something fails. If the build succeeds, a symlink `./result` to the package in the Nix store is created.
1081096. If you want to install the package into your profile (optional), do
110···117## Category Hierarchy
118[categories]: #category-hierarchy
119120+Most top-level packages are organised in a loosely-categorised directory hierarchy in this directory.
121+See the [overview](#overview) for which directories are part of this.
122+123+This category hierarchy is partially deprecated and will be migrated away over time.
124+The new `pkgs/by-name` directory ([docs](./by-name/README.md)) should be preferred instead.
125+The category hierarchy may still be used for packages that should be imported using an alternate `callPackage`, such as `python3Packages.callPackage` or `libsForQt5.callPackage`.
126+127+If that is the case for a new package, here are some rules for picking the right category.
128+Many packages fall under several categories; what matters is the _primary_ purpose of a package.
129+For example, the `libxml2` package builds both a library and some tools; but it’s a library foremost, so it goes under `pkgs/development/libraries`.
130131+<details>
132+<summary>Categories</summary>
133134**If it’s used to support _software development_:**
135···304**Else:**
305306- `misc`
307+308+</details>
309310# Conventions
311
···1+# Name-based package directories
2+3+The structure of this directory maps almost directly to top-level package attributes.
4+This is the recommended way to add new top-level packages to Nixpkgs [when possible](#limitations).
5+6+## Example
7+8+The top-level package `pkgs.some-package` may be declared by setting up this file structure:
9+10+```
11+pkgs
12+└── by-name
13+ ├── so
14+ ┊ ├── some-package
15+ ┊ └── package.nix
16+17+```
18+19+Where `some-package` is the package name and `so` is the lowercased 2-letter prefix of the package name.
20+21+The `package.nix` may look like this:
22+23+```nix
24+# A function taking an attribute set as an argument
25+{
26+ # Get access to top-level attributes for use as dependencies
27+ lib,
28+ stdenv,
29+ libbar,
30+31+ # Make this derivation configurable using `.override { enableBar = true }`
32+ enableBar ? false,
33+}:
34+35+# The return value must be a derivation
36+stdenv.mkDerivation {
37+ # ...
38+ buildInputs =
39+ lib.optional enableBar libbar;
40+}
41+```
42+43+You can also split up the package definition into more files in the same directory if necessary.
44+45+Once defined, the package can be built from the Nixpkgs root directory using:
46+```
47+nix-build -A some-package
48+```
49+50+See the [general package conventions](../README.md#conventions) for more information on package definitions.
51+52+### Changing implicit attribute defaults
53+54+The above expression is called using these arguments by default:
55+```nix
56+{
57+ lib = pkgs.lib;
58+ stdenv = pkgs.stdenv;
59+ libbar = pkgs.libbar;
60+}
61+```
62+63+But the package might need `pkgs.libbar_2` instead.
64+While the function could be changed to take `libbar_2` directly as an argument,
65+this would change the `.override` interface, breaking code like `.override { libbar = ...; }`.
66+So instead it is preferable to use the same generic parameter name `libbar`
67+and override its value in [`pkgs/top-level/all-packages.nix`](../top-level/all-packages.nix):
68+69+```nix
70+libfoo = callPackage ../by-name/so/somePackage/package.nix {
71+ libbar = libbar_2;
72+};
73+```
74+75+## Limitations
76+77+There's some limitations as to which packages can be defined using this structure:
78+79+- Only packages defined using `pkgs.callPackage`.
80+ This excludes packages defined using `pkgs.python3Packages.callPackage ...`.
81+82+ Instead use the [category hierarchy](../README.md#category-hierarchy) for such attributes.
83+84+- Only top-level packages.
85+ This excludes packages for other package sets like `pkgs.pythonPackages.*`.
86+87+ Refer to the definition and documentation of the respective package set to figure out how such packages can be declared.
88+89+## Validation
90+91+CI performs [certain checks](../test/nixpkgs-check-by-name/README.md#validity-checks) on the `pkgs/by-name` structure.
92+This is done using the [`nixpkgs-check-by-name` tool](../test/nixpkgs-check-by-name).
93+The version of this tool used is the one that corresponds to the NixOS channel of the PR base branch.
94+See [here](../../.github/workflows/check-by-name.yml) for details.
95+96+The tool can be run locally using
97+98+```bash
99+nix-build -A tests.nixpkgs-check-by-name
100+result/bin/nixpkgs-check-by-name .
101+```
+2-2
pkgs/data/fonts/sarasa-gothic/default.nix
···23stdenvNoCC.mkDerivation rec {
4 pname = "sarasa-gothic";
5- version = "0.41.6";
67 src = fetchurl {
8 # Use the 'ttc' files here for a smaller closure size.
9 # (Using 'ttf' files gives a closure size about 15x larger, as of November 2021.)
10 url = "https://github.com/be5invis/Sarasa-Gothic/releases/download/v${version}/sarasa-gothic-ttc-${version}.7z";
11- hash = "sha256-6CDK9DNjBQ5EPp562na0DOWFmlxnlVl8Z8pwm3pGQ9A=";
12 };
1314 sourceRoot = ".";
···23stdenvNoCC.mkDerivation rec {
4 pname = "sarasa-gothic";
5+ version = "0.41.8";
67 src = fetchurl {
8 # Use the 'ttc' files here for a smaller closure size.
9 # (Using 'ttf' files gives a closure size about 15x larger, as of November 2021.)
10 url = "https://github.com/be5invis/Sarasa-Gothic/releases/download/v${version}/sarasa-gothic-ttc-${version}.7z";
11+ hash = "sha256-TLEyCFQfBsCCHqnYmJNMJFkM+iKWqly3969zw9AbTFQ=";
12 };
1314 sourceRoot = ".";
···1# Nixpkgs pkgs/by-name checker
23This directory implements a program to check the [validity](#validity-checks) of the `pkgs/by-name` Nixpkgs directory once introduced.
04This is part of the implementation of [RFC 140](https://github.com/NixOS/rfcs/pull/140).
56## API
78-This API may be changed over time if the CI making use of it is adjusted to deal with the change appropriately, see [Hydra builds](#hydra-builds).
910- Command line: `nixpkgs-check-by-name <NIXPKGS>`
11- Arguments:
···1# Nixpkgs pkgs/by-name checker
23This directory implements a program to check the [validity](#validity-checks) of the `pkgs/by-name` Nixpkgs directory once introduced.
4+It is being used by [this GitHub Actions workflow](../../../.github/workflows/check-by-name.yml).
5This is part of the implementation of [RFC 140](https://github.com/NixOS/rfcs/pull/140).
67## API
89+This API may be changed over time if the CI workflow making use of it is adjusted to deal with the change appropriately.
1011- Command line: `nixpkgs-check-by-name <NIXPKGS>`
12- Arguments:
···1+# This file turns the pkgs/by-name directory (see its README.md for more info) into an overlay that adds all the defined packages.
2+# No validity checks are done here,
3+# instead this file is optimised for performance,
4+# and validity checks are done by CI on PRs.
5+6+# Type: Path -> Overlay
7+baseDirectory:
8+let
9+ # Because of Nix's import-value cache, importing lib is free
10+ lib = import ../../lib;
11+12+ inherit (builtins)
13+ readDir
14+ ;
15+16+ inherit (lib.attrsets)
17+ mapAttrs
18+ mapAttrsToList
19+ mergeAttrsList
20+ ;
21+22+ # Package files for a single shard
23+ # Type: String -> String -> AttrsOf Path
24+ namesForShard = shard: type:
25+ if type != "directory" then
26+ # Ignore all non-directories. Technically only README.md is allowed as a file in the base directory, so we could alternatively:
27+ # - Assume that README.md is the only file and change the condition to `shard == "README.md"` for a minor performance improvement.
28+ # This would however cause very poor error messages if there's other files.
29+ # - Ensure that README.md is the only file, throwing a better error message if that's not the case.
30+ # However this would make for a poor code architecture, because one type of error would have to be duplicated in the validity checks and here.
31+ # Additionally in either of those alternatives, we would have to duplicate the hardcoding of "README.md"
32+ { }
33+ else
34+ mapAttrs
35+ (name: _: baseDirectory + "/${shard}/${name}/package.nix")
36+ (readDir (baseDirectory + "/${shard}"));
37+38+ # The attribute set mapping names to the package files defining them
39+ # This is defined up here in order to allow reuse of the value (it's kind of expensive to compute)
40+ # if the overlay has to be applied multiple times
41+ packageFiles = mergeAttrsList (mapAttrsToList namesForShard (readDir baseDirectory));
42+in
43+# TODO: Consider optimising this using `builtins.deepSeq packageFiles`,
44+# which could free up the above thunks and reduce GC times.
45+# Currently this would be hard to measure until we have more packages
46+# and ideally https://github.com/NixOS/nix/pull/8895
47+self: super:
48+mapAttrs (name: file:
49+ self.callPackage file { }
50+) packageFiles
+8
pkgs/top-level/stage.nix
···8 arguments. Normal users should not import this directly but instead
9 import `pkgs/default.nix` or `default.nix`. */
1000000001112{ ## Misc parameters kept the same for all stages
13 ##
···279 stdenvAdapters
280 trivialBuilders
281 splice
0282 allPackages
283 otherPackageSets
284 aliases
···8 arguments. Normal users should not import this directly but instead
9 import `pkgs/default.nix` or `default.nix`. */
1011+let
12+ # An overlay to auto-call packages in ../by-name.
13+ # By defining it at the top of the file,
14+ # this value gets reused even if this file is imported multiple times,
15+ # thanks to Nix's import-value cache.
16+ autoCalledPackages = import ./by-name-overlay.nix ../by-name;
17+in
1819{ ## Misc parameters kept the same for all stages
20 ##
···286 stdenvAdapters
287 trivialBuilders
288 splice
289+ autoCalledPackages
290 allPackages
291 otherPackageSets
292 aliases