Home • Explore • Blog • Models • CI
☰



nixpkgs
17th chunk of `pkgs/README.md`
dd3a549a1ce6ddc751eb9938771292efffcb4c2ad3ec00c80000000100000fbf
  - If switching from e.g. PyPi to GitHub, verify that the repo is the official one.
  - If switching to a fork, check with external sources like other package repositories for community consensus.
- Ensure any special packaging choices and required context are documented in i.e. the name of a patch or in a comment.
  - If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
  - If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
  - If any non-default build flags are set, document why.
  - If checks are partially or fully disabled, document why.
- Ensure that the code contains no typos.
- Build the package locally.
  - Pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
  - It is possible to rebase the changes on nixos-unstable or nixpkgs-unstable for easier review by running the following commands from a nixpkgs clone.

    ```ShellSession
    $ git fetch origin nixos-unstable
    $ git fetch origin pull/PRNUMBER/head
    $ git rebase --onto nixos-unstable BASEBRANCH FETCH_HEAD
    ```

    - The first command fetches the nixos-unstable branch.
    - The second command fetches the pull request changes, `PRNUMBER` is the number at the end of the pull request title and `BASEBRANCH` the base branch of the pull request.
    - The third command rebases the pull request changes to the nixos-unstable branch.
  - The [nixpkgs-review](https://github.com/Mic92/nixpkgs-review) tool can be used to review a pull request content in a single command.
    `PRNUMBER` should be replaced by the number at the end of the pull request title.
    You can also provide the full github pull request url.

    ```ShellSession
    $ nix-shell -p nixpkgs-review --run "nixpkgs-review pr PRNUMBER"
    ```
- Run every binary.

Sample template for a package update review is provided below.

```markdown
##### Reviewed points

- [ ] package name fits guidelines
- [ ] package version fits guidelines
- [ ] package builds on ARCHITECTURE
- [ ] executables tested on ARCHITECTURE
- [ ] any change of upstream are verified
- [ ] the motives for any special packaging choices are documented
- [ ] all depending packages build
- [ ] patches have a comment describing either the upstream URL or a reason why the patch wasn't upstreamed
- [ ] patches that are remotely available are fetched rather than vendored

##### Possible improvements

##### Comments
```

### New packages

New packages are a common type of pull requests.
These pull requests consist in adding a new nix-expression for a package.

Review process:

- Ensure that all file paths [fit the guidelines](../CONTRIBUTING.md#file-naming-and-organisation).
- Ensure that the package name and version [fits the guidelines](#package-naming).
- Ensure that the package versioning [fits the guidelines](#versioning).
- Ensure that the commit text [fits the guidelines](../CONTRIBUTING.md#commit-conventions).
- Ensure that the source is fetched from an official location, one of our [trusted mirrors](./build-support/fetchurl/mirrors.nix), or a mirror trusted by the authors.
- Ensure that the meta fields [fits the guidelines](#meta-attributes) and contain the correct information:
  - License must match the upstream license.
  - Platforms should be set (or the package will not get binary substitutes).
  - Maintainers must be set.
    This can be the package submitter or a community member that accepts taking up maintainership of the package.
  - The `meta.mainProgram` must be set if a main executable exists.
- Ensure any special packaging choices and required context are documented in, i.e., the name of a patch or in a comment.
  - If a special version of a package is pinned, document why, so others know if/when it can be unpinned.
  - If any (especially opinionated) patch or `substituteInPlace` is applied, document why.
  - If any non-default build flags are set, document why.
Title: Nixpkgs: Comprehensive Review Guidelines for Package Updates and New Packages
Summary
This chunk continues the guidelines for reviewing Nixpkgs package updates, emphasizing verification of upstream sources, thorough documentation of any special packaging choices (like pinned versions, patches, or non-default build flags), typo checks, and local package building. It provides detailed `git` commands for rebasing pull requests onto unstable branches for easier review and recommends using the `nixpkgs-review` tool. A markdown template for package update reviews is also included. The document then transitions to the review process for new packages, outlining requirements such as adherence to file path, naming, versioning, and commit guidelines, ensuring sources are from official or trusted locations, and correctly populating `meta` fields (license, platforms, maintainers, mainProgram). It reiterates the importance of documenting any special packaging decisions for new packages.