Home Explore Blog Models CI



nixpkgs

10th chunk of `pkgs/README.md`
8f9e99c4bc493a494d458ed1fd68893bc93ead9501f3aedb0000000100000fa4
If you need a patch applied to a dependency, discuss with the maintainer of that dependency whether it would be acceptable to apply to the main version of the package.
If you need a different version of a dependency, first try modifying your package to work with the version in Nixpkgs — it's often not very hard! — and if that's not possible, try to factor out a function that can build multiple versions of the package, including the main version.
If you need to enable or disable optional functionality of a dependency, add an explicit flag to the package and use `override` instead.

## Sources

Always fetch source files using [Nixpkgs fetchers](https://nixos.org/manual/nixpkgs/unstable/#chap-pkgs-fetchers).
Use reproducible sources with a high degree of availability.
Prefer protocols that support proxies.

A list of schemes for `mirror://` URLs can be found in [`pkgs/build-support/fetchurl/mirrors.nix`](build-support/fetchurl/mirrors.nix), and is supported by [`fetchurl`](https://nixos.org/manual/nixpkgs/unstable/#fetchurl).
Other fetchers which end up relying on `fetchurl` may also support mirroring.

The preferred source hash type is `sha256`.

Examples going from bad to best practices:

- Bad: Uses `git://` which won't be proxied.

  ```nix
  {
    src = fetchgit {
      url = "git://github.com/NixOS/nix.git";
      rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
      hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
    };
  }
  ```

- Better: This is ok, but an archive fetch will still be faster.

  ```nix
  {
    src = fetchgit {
      url = "https://github.com/NixOS/nix.git";
      rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
      hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
    };
  }
  ```

- Best: Fetches a snapshot archive for the given revision.

  ```nix
  {
    src = fetchFromGitHub {
      owner = "NixOS";
      repo = "nix";
      rev = "1f795f9f44607cc5bec70d1300150bfefcef2aae";
      hash = "sha256-7D4m+saJjbSFP5hOwpQq2FGR2rr+psQMTcyb1ZvtXsQ=";
    };
  }
  ```

> [!Note]
> When fetching from GitHub, always reference revisions by their full commit hash.
> GitHub shares commit hashes among all forks and returns `404 Not Found` when a short commit hash is ambiguous.
> It already happened in Nixpkgs for short, 6-character commit hashes.
>
> Pushing large amounts of auto generated commits into forks is a practical vector for a denial-of-service attack, and was already [demonstrated against GitHub Actions Beta](https://blog.teddykatz.com/2019/11/12/github-actions-dos.html).

## Patches

Sometimes, changes are needed to the source to allow building a derivation in nixpkgs, or to get earlier access to an upstream fix or improvement.
When using the `patches` parameter to `mkDerivation`, make sure the patch name clearly describes the reason for the patch, or add a comment.

> [!Note]
> The version of the package does not need to be changed just because a patch is applied.
> Declarative package installations don't depend on the version, while imperative `nix-env` installations can use [`upgrade --eq/leq/--always`](https://nix.dev/manual/nix/2.25/command-ref/nix-env/upgrade#flags).
>
> See [Versioning](#versioning) for details on package versioning.

The following describes two ways to include the patch.
Regardless of how the patch is included, you _must_ ensure its purpose is clear and obvious.
This enables other maintainers to more easily determine when old patches are no longer required.
Typically, you can improve clarity with carefully considered filenames, attribute names, and/or comments; these should explain the patch's _intention_.
Additionally, it may sometimes be helpful to clarify _how_ it resolves the issue.
For example: _"fix gcc14 build by adding missing include"_.

### Fetching patches

In the interest of keeping our maintenance burden and the size of Nixpkgs to a minimum, patches already merged upstream or published elsewhere _should_ be retrieved using `fetchpatch2`:

Title: Nixpkgs Source Fetching, Patching, and Dependency Management Guidelines
Summary
This document outlines Nixpkgs best practices for dependency management, source fetching, and applying patches. For dependencies, it advises collaborating with maintainers for patches, adapting to existing versions or implementing multi-version build functions, and using explicit flags with `override` for optional features. Regarding sources, it mandates using Nixpkgs fetchers, favoring reproducible, highly available, and proxy-compatible sources, with `sha256` as the preferred hash type. Examples demonstrate fetching sources from GitHub, recommending `fetchFromGitHub` for snapshot archives over direct `git://` or `https://` git clones, and stressing the use of full commit hashes to avoid ambiguities. Finally, it provides guidelines for patches, emphasizing clear naming and commenting to explain their purpose, noting that package versions don't need to change for patches, and introducing `fetchpatch2` for upstream or publicly available patches to minimize maintenance.