pkgs/by-name/README.md

   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 Packages found in the named-based structure do not need to be explicitly added to the
   7 `top-level/all-packages.nix` file unless they require overriding the default value
   8 of an implicit attribute (see below).
   9
  10 ## Example
  11
  12 The top-level package `pkgs.some-package` may be declared by setting up this file structure:
  13
  14 ```
  15 pkgs
  16 └── by-name
  17    ├── so
  18    ┊  ├── some-package
  19       ┊  └── package.nix
  20
  21 ```
  22
  23 Where `some-package` is the package name and `so` is the lowercased 2-letter prefix of the package name.
  24
  25 The `package.nix` may look like this:
  26
  27 ```nix
  28 # A function taking an attribute set as an argument
  29 {
  30   # Get access to top-level attributes for use as dependencies
  31   lib,
  32   stdenv,
  33   libbar,
  34
  35   # Make this derivation configurable using `.override { enableBar = true }`
  36   enableBar ? false,
  37 }:
  38
  39 # The return value must be a derivation
  40 stdenv.mkDerivation {
  41   # ...
  42   buildInputs =
  43     lib.optional enableBar libbar;
  44 }
  45 ```
  46
  47 You can also split up the package definition into more files in the same directory if necessary.
  48
  49 Once defined, the package can be built from the Nixpkgs root directory using:
  50 ```
  51 nix-build -A some-package
  52 ```
  53
  54 See the [general package conventions](../README.md#conventions) for more information on package definitions.
  55
  56 ### Changing implicit attribute defaults
  57
  58 The above expression is called using these arguments by default:
  59 ```nix
  60 {
  61   lib = pkgs.lib;
  62   stdenv = pkgs.stdenv;
  63   libbar = pkgs.libbar;
  64 }
  65 ```
  66
  67 But the package might need `pkgs.libbar_2` instead.
  68 While the function could be changed to take `libbar_2` directly as an argument,
  69 this would change the `.override` interface, breaking code like `.override { libbar = ...; }`.
  70 So instead it is preferable to use the same generic parameter name `libbar`
  71 and override its value in [`pkgs/top-level/all-packages.nix`](../top-level/all-packages.nix):
  72
  73 ```nix
  74 libfoo = callPackage ../by-name/so/some-package/package.nix {
  75   libbar = libbar_2;
  76 };
  77 ```
  78
  79 ## Manual migration guidelines
  80
  81 Most packages are still defined in `all-packages.nix` and the [category hierarchy](../README.md#category-hierarchy).
  82 Please hold off migrating your maintained packages to this directory.
  83
  84 1. An automated migration for the majority of packages [is being worked on](https://github.com/NixOS/nixpkgs/pull/211832).
  85    In order to save on contributor and reviewer time, packages should only be migrated manually afterwards if they couldn't be migrated automatically.
  86
  87 1. Manual migrations should only be lightly encouraged if the relevant code is being worked on anyways.
  88    For example with a package update or refactoring.
  89
  90 1. Manual migrations should not remove definitions from `all-packages.nix` with custom arguments.
  91    That is a backwards-incompatible change because it changes the `.override` interface.
  92    Such packages may still be moved to `pkgs/by-name` however, while keeping the definition in `all-packages.nix`.
  93    See also [changing implicit attribute defaults](#changing-implicit-attribute-defaults).
  94
  95 ## Limitations
  96
  97 There's some limitations as to which packages can be defined using this structure:
  98
  99 - Only packages defined using `pkgs.callPackage`.
 100   This excludes packages defined using `pkgs.python3Packages.callPackage ...`.
 101
 102   Instead use the [category hierarchy](../README.md#category-hierarchy) for such attributes.
 103
 104 - Only top-level packages.
 105   This excludes packages for other package sets like `pkgs.pythonPackages.*`.
 106
 107   Refer to the definition and documentation of the respective package set to figure out how such packages can be declared.
 108
 109 ## Validation
 110
 111 CI performs [certain checks](../test/nixpkgs-check-by-name/README.md#validity-checks) on the `pkgs/by-name` structure.
 112 This is done using the [`nixpkgs-check-by-name` tool](../test/nixpkgs-check-by-name).
 113 The version of this tool used is the one that corresponds to the NixOS channel of the PR base branch.
 114 See [here](../../.github/workflows/check-by-name.yml) for details.
 115
 116 The tool can be run locally using
 117
 118 ```bash
 119 nix-build -A tests.nixpkgs-check-by-name
 120 result/bin/nixpkgs-check-by-name .
 121 ```