Home • Explore • Blog • CI
☰



nixpkgs
2nd chunk of `pkgs/by-name/README.md`
2fbe8e44e0a356396f2e818835bfcb5fb16b473c392ff1330000000100000920
please see [this ticket](https://github.com/NixOS/nixpkgs-vet/issues/56).

Since [only PRs to packages in `pkgs/by-name` can be automatically merged](../../CONTRIBUTING.md#how-to-merge-pull-requests-yourself),
if package maintainers would like to use this feature, they are welcome to migrate their packages to `pkgs/by-name`.
To lessen PR traffic, they're encouraged to also perform some more general maintenance on the package in the same PR,
though this is not required and must not be expected.

Note that `callPackage` definitions in `all-packages.nix` with custom arguments should not be removed.
That is a backwards-incompatible change because it changes the `.override` interface.
Such packages may still be moved to `pkgs/by-name` however, in order to avoid the slightly superficial choice of directory / category in which the `default.nix` file was placed, but please keep the definition in `all-packages.nix` using `callPackage`.
See also [changing implicit attribute defaults](#changing-implicit-attribute-defaults).

Definitions like the following however, _can_ be transitioned:

```nix
# all-packages.nix
fooWithBaz = foo.override {
  bar = baz;
};
# turned into pkgs/by-name/fo/fooWithBaz/package.nix with:
{
  foo,
  baz,
}:

foo.override {
  bar = baz;
}
```

## Limitations

There's some limitations as to which packages can be defined using this structure:

- Only packages defined using `pkgs.callPackage`.
  This excludes packages defined using `pkgs.python3Packages.callPackage ...`.

  Instead:
  - Either change the package definition to work with `pkgs.callPackage`.
  - Or use the [category hierarchy](../README.md#category-hierarchy).

- Only top-level packages.
  This excludes packages for other package sets like `pkgs.pythonPackages.*`.

  Refer to the definition and documentation of the respective package set to figure out how such packages can be declared.

## Validation

CI performs [certain checks](https://github.com/NixOS/nixpkgs-vet?tab=readme-ov-file#validity-checks) on the `pkgs/by-name` structure.
This is done using the [`nixpkgs-vet` tool](https://github.com/NixOS/nixpkgs-vet).

You can locally emulate the CI check using

```
$ ./ci/nixpkgs-vet.sh master
```

See [here](../../.github/workflows/nixpkgs-vet.yml) for more info.

## Recommendation for new packages with multiple versions
Title: Migration, Limitations, Validation, and Versioning Recommendations for Name-Based Packages
Summary
This section provides guidance on migrating packages to the `pkgs/by-name` structure for automatic merging of pull requests. It advises against removing `callPackage` definitions in `all-packages.nix` with custom arguments to avoid breaking the `.override` interface, but shows how some definitions can be transitioned. The section also outlines limitations on which packages can be defined using this structure, specifically those using `pkgs.callPackage` and top-level packages only. Additionally, it describes the validation checks performed by CI using the `nixpkgs-vet` tool, which can be emulated locally. Finally, it touches on recommendations for new packages that have multiple versions.