debianRevision = "5";
patch = "Add-quotes-to-SOAPAction-header-in-SoapClient.patch";
hash = "sha256-xA8Wnrpr31H8wy3zHSNfezFNjUJt1HbSXn3qUMzeKc0=";
})
];
# ...
}
```
Patches are fetched from `sources.debian.org`, and so must come from a
package version that was uploaded to the Debian archive. Packages may
be removed from there once that specific version isn't in any suite
anymore (stable, testing, unstable, etc.), so maintainers should use
`copy-tarballs.pl` to archive the patch if it needs to be available
longer-term.
## `fetchsvn` {#fetchsvn}
Used with Subversion. Expects `url` to a Subversion directory, `rev`, and `hash`.
## `fetchgit` {#fetchgit}
Used with Git. Expects `url` to a Git repo, `rev`, and `hash`. `rev` in this case can be full the git commit id (SHA1 hash) or a tag name like `refs/tags/v1.0`.
If you want to fetch a tag you should pass the `tag` parameter instead of `rev` which has the same effect as setting `rev = "refs/tags"/${version}"`.
This is safer than just setting `rev = version` w.r.t. possible branch and tag name conflicts.
Additionally, the following optional arguments can be given:
*`fetchSubmodules`* (Boolean)
: Whether to also fetch the submodules of a repository.
*`fetchLFS`* (Boolean)
: Whether to fetch LFS objects.
*`preFetch`* (String)
: Shell code to be executed before the repository has been fetched, to allow
changing the environment the fetcher runs in.
*`postFetch`* (String)
: Shell code executed after the repository has been fetched successfully.
This can do things like check or transform the file.
*`leaveDotGit`* (Boolean)
: Whether the `.git` directory of the clone should *not* be removed after checkout.
Be warned though that the git repository format is not stable and this flag is therefore not suitable for actual use by itself.
Only use this for testing purposes or in conjunction with removing the `.git` directory in `postFetch`.
*`deepClone`* (Boolean)
: Clone the entire repository as opposing to just creating a shallow clone.
This implies `leaveDotGit`.
*`fetchTags`* (Boolean)
: Whether to fetch all tags from the remote repository. This is useful when the build process needs to run `git describe` or other commands that require tag information to be available. This parameter implies `leaveDotGit`, as tags are stored in the `.git` directory.
*`sparseCheckout`* (List of String)
: Prevent git from fetching unnecessary blobs from server.
This is useful if only parts of the repository are needed.
::: {.example #ex-fetchgit-sparseCheckout}
# Use `sparseCheckout` to only include some directories:
```nix
{ stdenv, fetchgit }:
stdenv.mkDerivation {
name = "hello";
src = fetchgit {
url = "https://...";
sparseCheckout = [
"directory/to/be/included"
"another/directory"
];
hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};
}
```
:::
See [git sparse-checkout](https://git-scm.com/docs/git-sparse-checkout) for more information.
Some additional parameters for niche use-cases can be found listed in the function parameters in the declaration of `fetchgit`: `pkgs/build-support/fetchgit/default.nix`.
Future parameters additions might also happen without immediately being documented here.
## `fetchfossil` {#fetchfossil}
Used with Fossil. Expects `url` to a Fossil archive, `rev`, and `hash`.
## `fetchcvs` {#fetchcvs}
Used with CVS. Expects `cvsRoot`, `tag`, and `hash`.
## `fetchhg` {#fetchhg}
Used with Mercurial. Expects `url`, `rev`, and `hash`.
A number of fetcher functions wrap part of `fetchurl` and `fetchzip`. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
## `fetchFromGitea` {#fetchfromgitea}
`fetchFromGitea` expects five arguments. `domain` is the gitea server name. `owner` is a string corresponding to the Gitea user or organization that controls this repository. `repo` corresponds to the name of the software repository. These are located at the top of every Gitea HTML page as `owner`/`repo`. `rev` corresponds to the Git commit hash or tag (e.g `v1.0`) that will be downloaded from Git. Finally, `hash` corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but `hash` is currently preferred.