* doc: document fetchurl more completely, follow doc conventions Co-authored-by: Johannes Kirschbauer <hsjobeki+github@gmail.com>
34 KiB
Fetchers
Building software with Nix often requires downloading source code and other files from the internet. To this end, we use functions that we call fetchers, which obtain remote sources via various protocols and services.
Nix provides built-in fetchers such as builtins.fetchTarball
.
Nixpkgs provides its own fetchers, which work differently:
- A built-in fetcher will download and cache files at evaluation time and produce a store path. A Nixpkgs fetcher will create a (fixed-output) derivation, and files are downloaded at build time.
- Built-in fetchers will invalidate their cache after
tarball-ttl
expires, and will require network activity to check if the cache entry is up to date. Nixpkgs fetchers only re-download if the specified hash changes or the store object is not available. - Built-in fetchers do not use substituters. Derivations produced by Nixpkgs fetchers will use any configured binary cache transparently.
This significantly reduces the time needed to evaluate Nixpkgs, and allows Hydra to retain and re-distribute sources used by Nixpkgs in the public binary cache. For these reasons, Nix's built-in fetchers are not allowed in Nixpkgs.
The following table summarises the differences:
Fetchers | Download | Output | Cache | Re-download when |
---|---|---|---|---|
builtins.fetch* |
evaluation time | store path | /nix/store , ~/.cache/nix |
tarball-ttl expires, cache miss in ~/.cache/nix , output store object not in local store |
pkgs.fetch* |
build time | derivation | /nix/store , substituters |
output store object not available |
:::{.tip}
pkgs.fetchFrom*
helpers retrieve snapshots of version-controlled sources, as opposed to the entire version history, which is more efficient.
pkgs.fetchgit
by default also has the same behaviour, but can be changed through specific attributes given to it.
:::
Caveats
Because Nixpkgs fetchers are fixed-output derivations, an output hash has to be specified, usually indirectly through a hash
attribute.
This hash refers to the derivation output, which can be different from the remote source itself!
This has the following implications that you should be aware of:
-
Use Nix (or Nix-aware) tooling to produce the output hash.
-
When changing any fetcher parameters, always update the output hash. Use one of the methods from . Otherwise, existing store objects that match the output hash will be re-used rather than fetching new content.
:::{.note} A similar problem arises while testing changes to a fetcher's implementation. If the output of the derivation already exists in the Nix store, test failures can go undetected. The
invalidateFetcherByDrvHash
function helps prevent reusing cached derivations. :::
Updating source hashes
There are several ways to obtain the hash corresponding to a remote source. Unless you understand how the fetcher you're using calculates the hash from the downloaded contents, you should use the fake hash method.
-
[]{#sec-pkgs-fetchers-updating-source-hashes-fakehash-method} The fake hash method: In your package recipe, set the hash to one of
""
lib.fakeHash
lib.fakeSha256
lib.fakeSha512
Attempt to build, extract the calculated hashes from error messages, and put them into the recipe.
:::{.warning} You must use one of these four fake hashes and not some arbitrarily-chosen hash. See for details. :::
:::{.example #ex-fetchers-update-fod-hash}
Update source hash with the fake hash method
Consider the following recipe that produces a plain file:
{ fetchurl }: fetchurl { url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.05/.version"; hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM="; }
A common mistake is to update a fetcher parameter, such as
url
, without updating the hash:{ fetchurl }: fetchurl { url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"; hash = "sha256-ZHl1emidXVojm83LCVrwULpwIzKE/mYwfztVkvpruOM="; }
This will produce the same output as before! Set the hash to an empty string:
{ fetchurl }: fetchurl { url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"; hash = ""; }
When building the package, use the error message to determine the correct hash:
$ nix-build (some output removed for clarity) error: hash mismatch in fixed-output derivation '/nix/store/7yynn53jpc93l76z9zdjj4xdxgynawcw-version.drv': specified: sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= got: sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I= error: build of '/nix/store/bqdjcw5ij5ymfbm41dq230chk9hdhqff-version.drv' failed
:::
-
Prefetch the source with
nix-prefetch-<type> <URL>
, where<type>
is one ofurl
git
hg
cvs
bzr
svn
The hash is printed to stdout.
-
Prefetch by package source (with
nix-prefetch-url '<nixpkgs>' -A <package>.src
, where<package>
is package attribute name). The hash is printed to stdout.This works well when you've upgraded the existing package version and want to find out new hash, but is useless if the package can't be accessed by attribute or the package has multiple sources (
.srcs
, architecture-dependent sources, etc). -
Upstream hash: use it when upstream provides
sha256
orsha512
. Don't use it when upstream providesmd5
, computesha256
instead.A little nuance is that
nix-prefetch-*
tools produce hashes with thenix32
encoding (a Nix-specific base32 adaptation), but upstream usually provides hexadecimal (base16
) encoding. Fetchers understand both formats. Nixpkgs does not standardise on any one format.You can convert between hash formats with
nix-hash
. -
Extract the hash from a local source archive with
sha256sum
. Usenix-prefetch-url file:///path/to/archive
if you want the custom Nixbase32
hash.
Obtaining hashes securely
It's always a good idea to avoid Man-in-the-Middle (MITM) attacks when downloading source contents. Otherwise, you could unknowingly download malware instead of the intended source, and instead of the actual source hash, you'll end up using the hash of malware. Here are security considerations for this scenario:
-
http://
URLs are not secure to prefetch hashes. -
Upstream hashes should be obtained via a secure protocol.
-
https://
URLs give you more protections when usingnix-prefetch-*
or for upstream hashes. -
https://
URLs are secure when using the fake hash method only if you use one of the listed fake hashes. If you use any other hash, the download will be exposed to MITM attacks even if you use HTTPS URLs.In more concrete terms, if you use any other hash, the
--insecure
flag will be passed to the underlying call tocurl
when downloading content.
[]{#fetchurl}
fetchurl
fetchurl
returns a fixed-output derivation which downloads content from a given URL and stores the unaltered contents within the Nix store.
It uses {manpage}curl(1)
internally, and allows its behaviour to be modified by specifying a few attributes in the argument to fetchurl
(see the documentation for attributes curlOpts
, curlOptsList
, and netrcPhase
).
The resulting store path is determined by the hash given to fetchurl
, and also the name
(or pname
and version
) values.
If neither name
nor pname
and version
are specified when calling fetchurl
, it will default to using the basename of url
or the first element of urls
.
If pname
and version
are specified, fetchurl
will use those values and will ignore name
, even if it is also specified.
Inputs
fetchurl
requires an attribute set with the following attributes:
url
(String; optional)- The URL to download from.
:::{.note} Either
url
orurls
must be specified, but not both. :::All URLs of the format specified here are supported.
Default value:
""
. urls
(List of String; optional)- A list of URLs, specifying download locations for the same content.
Each URL will be tried in order until one of them succeeds with some content or all of them fail.
See to understand how this attribute affects the behaviour of
fetchurl
.:::{.note} Either
url
orurls
must be specified, but not both. :::Default value:
[]
. hash
(String; optional)- Hash of the derivation output of
fetchurl
, following the format for integrity metadata as defined by SRI. For more information, see .:::{.note} It is recommended that you use the
hash
attribute instead of the other hash-specific attributes that exist for backwards compatibility.If
hash
is not specified, you must specifyoutputHash
andoutputHashAlgo
, or one ofsha512
,sha256
, orsha1
. :::Default value:
""
. outputHash
(String; optional)- Hash of the derivation output of
fetchurl
in the format expected by Nix. See the documentation on the Nix manual for more information about its format.:::{.note} It is recommended that you use the
hash
attribute instead.If
outputHash
is specified, you must also specifyoutputHashAlgo
. :::Default value:
""
. outputHashAlgo
(String; optional)- Algorithm used to generate the value specified in
outputHash
. See the documentation on the Nix manual for more information about the values it supports.:::{.note} It is recommended that you use the
hash
attribute instead.The value specified in
outputHashAlgo
will be ignored ifoutputHash
isn't also specified. :::Default value:
""
. sha1
(String; optional)- SHA-1 hash of the derivation output of
fetchurl
in the format expected by Nix. See the documentation on the Nix manual for more information about its format.:::{.note} It is recommended that you use the
hash
attribute instead. :::Default value:
""
. sha256
(String; optional)- SHA-256 hash of the derivation output of
fetchurl
in the format expected by Nix. See the documentation on the Nix manual for more information about its format.:::{.note} It is recommended that you use the
hash
attribute instead. :::Default value:
""
. sha512
(String; optional)- SHA-512 hash of the derivation output of
fetchurl
in the format expected by Nix. See the documentation on the Nix manual for more information about its format.:::{.note} It is recommended that you use the
hash
attribute instead. :::Default value:
""
. name
(String; optional)- The symbolic name of the downloaded file when saved in the Nix store.
See the
fetchurl
overview for details on how the name of the file is decided.Default value:
""
. pname
(String; optional)- A base name, which will be combined with
version
to form the symbolic name of the downloaded file when saved in the Nix store. See thefetchurl
overview for details on how the name of the file is decided.:::{.note} If
pname
is specified, you must also specifyversion
, otherwisefetchurl
will ignore the value ofpname
. :::Default value:
""
. version
(String; optional)- A version, which will be combined with
pname
to form the symbolic name of the downloaded file when saved in the Nix store. See thefetchurl
overview for details on how the name of the file is decided.Default value:
""
. recursiveHash
(Boolean; optional)- If set to
true
, will signal to Nix that the hash given tofetchurl
was calculated using the"recursive"
mode. See the documentation on the Nix manual for more information about the existing modes.By default,
fetchurl
uses"recursive"
mode when theexecutable
attribute is set totrue
, so you don't need to specifyrecursiveHash
in this case.Default value:
false
. executable
(Boolean; optional)- If
true
, sets the executable bit on the downloaded file.Default value:
false
. downloadToTemp
(Boolean; optional)- If
true
, saves the downloaded file to a temporary location instead of the expected Nix store location. This is useful when used in conjunction withpostFetch
attribute, otherwisefetchurl
will not produce any meaningful output.The location of the downloaded file will be set in the
$downloadedFile
variable, which should be used by the script in thepostFetch
attribute. See to understand how to work with this attribute.Default value:
false
. postFetch
(String; optional)- Script executed after the file has been downloaded successfully, and before
fetchurl
finishes running. Useful for post-processing, to check or transform the file in some way. See to understand how to work with this attribute.Default value:
""
. netrcPhase
(String or Null; optional)- Script executed to create a {manpage}
netrc(5)
file to be used with {manpage}curl(1)
. The script should create thenetrc
file (note that it does not begin with a ".") in the directory it's currently running in ($PWD
).The script is executed during the setup done by
fetchurl
before it runs any of its code to download the specified content.:::{.note} If specified,
fetchurl
will automatically alter its invocation of {manpage}curl(1)
to use thenetrc
file, so you don't need to add anything tocurlOpts
orcurlOptsList
. ::::::{.caution} Since
netrcPhase
needs to be specified in your source Nix code, any secrets that you put directly in it will be world-readable by design (both in your source code, and when the derivation gets created in the Nix store).If you want to avoid this behaviour, see the documentation of
netrcImpureEnvVars
for an alternative way of dealing with these secrets. :::Default value:
null
. netrcImpureEnvVars
(List of String; optional)- If specified,
fetchurl
will add these environment variable names to the list of impure environment variables, which will be passed from the environment of the calling user to the builder running thefetchurl
code.This is useful when used with
netrcPhase
to hide any secrets that are used in it, because the script innetrcPhase
only needs to reference the environment variables with the secrets in them instead. However, note that these are called impure variables for a reason: the environment that starts the build needs to have these variables declared for everything to work properly, which means that additional setup is required outside what Nix controls.Default value:
[]
. curlOpts
(String; optional)- If specified, this value will be appended to the invocation of {manpage}
curl(1)
when downloading the URL(s) given tofetchurl
. Multiple arguments can be separated by spaces normally, but values with whitespaces will be interpreted as multiple arguments (instead of a single value), even if the value is escaped. SeecurlOptsList
for a way to pass values with whitespaces in them.Default value:
""
. curlOptsList
(List of String; optional)- If specified, each element of this list will be passed as an argument to the invocation of {manpage}
curl(1)
when downloading the URL(s) given tofetchurl
. This allows passing values that contain spaces, with no escaping needed.Default value:
[]
. showURLs
(Boolean; optional)- If set to
true
, this will stopfetchurl
from downloading anything at all. Instead, it will output a list of all the URLs it would've used to download the content (after resolvingmirror://
URLs, for example). This is useful for debugging.Default value:
false
. meta
(Attribute Set; optional)- Specifies any meta-attributes for the derivation returned by
fetchurl
.Default value:
{}
. passthru
(Attribute Set; optional)- Specifies any extra passthru attributes for the derivation returned by
fetchurl
. Note thatfetchurl
defines passthru attributes of its own. Attributes specified inpassthru
can override the default attributes returned byfetchurl
.Default value:
{}
. preferLocalBuild
(Boolean; optional)- This is the same attribute as defined in the Nix manual.
It is
true
by default because making a remote machine download the content just duplicates network traffic (since the local machine might download the results from the derivation anyway), but this could be useful in cases where network access is restricted on local machines.Default value:
true
. nativeBuildInputs
(List of Attribute Set; optional)- Additional packages needed to download the content.
This is useful if you need extra packages for
postFetch
ornetrcPhase
, for example. Has the same semantics as in . See to understand how this can be used withpostFetch
.Default value:
[]
.
Passthru outputs
fetchurl
also defines its own passthru
attributes:
url
(String)-
The same
url
attribute passed in the argument tofetchurl
.
Examples
:::{.example #ex-fetchers-fetchurl-nixpkgs-version}
Using fetchurl
to download a file
The following package downloads a small file from a URL and shows the most common way to use fetchurl
:
{ fetchurl }:
fetchurl {
url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
}
After building the package, the file will be downloaded and place into the Nix store:
$ nix-build
(output removed for clarity)
/nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
$ cat /nix/store/4g9y3x851wqrvim4zcz5x2v3zivmsq8n-version
23.11
:::
:::{.example #ex-fetchers-fetchurl-nixpkgs-version-multiple-urls}
Using fetchurl
to download a file with multiple possible URLs
The following package adapts to use multiple URLs.
The first URL was crafted to intentionally return an error to illustrate how fetchurl
will try multiple URLs until it finds one that works (or all URLs fail).
{ fetchurl }:
fetchurl {
urls = [
"https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
"https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
];
hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
}
After building the package, both URLs will be used to download the file:
$ nix-build
(some output removed for clarity)
trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist
(some output removed for clarity)
curl: (22) The requested URL returned error: 404
trying https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version
(some output removed for clarity)
/nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
$ cat /nix/store/n9asny31z32q7sdw6a8r1gllrsfy53kl-does-not-exist
23.11
However, note that the name of the file was derived from the first URL (this is further explained in the fetchurl
overview).
To ensure the result will have the same name regardless of which URLs are used, we can modify the package:
{ fetchurl }:
fetchurl {
name = "nixpkgs-version";
urls = [
"https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/does-not-exist"
"https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version"
];
hash = "sha256-BZqI7r0MNP29yGH5+yW2tjU9OOpOCEvwWKrWCv5CQ0I=";
}
After building the package, the result will have the name we specified:
$ nix-build
(output removed for clarity)
/nix/store/zczb6wl3al6jm9sm5h3pr6nqn0i5ji9z-nixpkgs-version
:::
:::{.example #ex-fetchers-fetchurl-nixpkgs-version-postfetch}
Manipulating the content downloaded by fetchurl
It might be useful to manipulate the content downloaded by fetchurl
directly in its derivation.
In this example, we'll adapt to append the result of running the hello
package to the contents we download, purely to illustrate how to manipulate the content.
{ fetchurl, hello, lib }:
fetchurl {
url = "https://raw.githubusercontent.com/NixOS/nixpkgs/23.11/.version";
nativeBuildInputs = [ hello ];
downloadToTemp = true;
postFetch = ''
${lib.getExe hello} >> $downloadedFile
mv $downloadedFile $out
'';
hash = "sha256-ceooQQYmDx5+0nfg40uU3NNI2yKrixP7HZ/xLZUNv+w=";
}
After building the package, the resulting file will have "Hello, world!" appended to it:
$ nix-build
(output removed for clarity)
/nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
$ cat /nix/store/ifi6pp7q0ag5h7c5v9h1c1c7bhd10c7f-version
23.11
Hello, world!
Note that the hash
specified in the package is different than the hash specified in , because the contents of the output have changed (even though the actual file that was downloaded is the same).
See for more details on how to work with the hash
attribute when the output changes.
:::
fetchzip
Downloads content from a given URL (which is assumed to be an archive), and decompresses the archive for you, making files and directories directly accessible.
fetchzip
can only be used with archives.
Despite its name, fetchzip
is not limited to .zip
files and can also be used with any tarball.
It has two required arguments, a URL and a hash.
The hash is typically hash
, although many more hash algorithms are supported.
Nixpkgs contributors are currently recommended to use hash
.
This hash will be used by Nix to identify your source.
A typical usage of fetchzip
is provided below.
{ fetchzip }:
fetchzip {
url = "https://github.com/NixOS/patchelf/releases/download/0.18.0/patchelf-0.18.0.tar.gz";
hash = "sha256-3ABYlME9R8klcpJ7MQpyFEFwHmxDDEzIYBqu/CpDYmg=";
}
fetchpatch
fetchpatch
works very similarly to fetchurl
with the same arguments expected. It expects patch files as a source and performs normalization on them before computing the checksum. For example, it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
relative
: Similar to usinggit-diff
's--relative
flag, only keep changes inside the specified directory, making paths relative to it.stripLen
: Remove the firststripLen
components of pathnames in the patch.decode
: Pipe the downloaded data through this command before processing it as a patch.extraPrefix
: Prefix pathnames by this string.excludes
: Exclude files matching these patterns (applies after the above arguments).includes
: Include only files matching these patterns (applies after the above arguments).revert
: Revert the patch.
Note that because the checksum is computed after applying these effects, using or modifying these arguments will have no effect unless the hash
argument is changed as well.
Most other fetchers return a directory rather than a single file.
fetchDebianPatch
A wrapper around fetchpatch
, which takes:
patch
andhash
: the patch's filename, and its hash after normalization byfetchpatch
;pname
: the Debian source package's name ;version
: the upstream version number ;debianRevision
: the Debian revision number if applicable ;- the
area
of the Debian archive:main
(default),contrib
, ornon-free
.
Here is an example of fetchDebianPatch
in action:
{ lib
, fetchDebianPatch
, buildPythonPackage
}:
buildPythonPackage rec {
pname = "pysimplesoap";
version = "1.16.2";
src = <...>;
patches = [
(fetchDebianPatch {
inherit pname version;
debianRevision = "5";
name = "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
Used with Subversion. Expects url
to a Subversion directory, rev
, and hash
.
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
.
Additionally, the following optional arguments can be given: fetchSubmodules = true
makes fetchgit
also fetch the submodules of a repository. If deepClone
is set to true, the entire repository is cloned as opposing to just creating a shallow clone. deepClone = true
also implies leaveDotGit = true
which means that the .git
directory of the clone won't be removed after checkout.
If only parts of the repository are needed, sparseCheckout
can be used. This will prevent git from fetching unnecessary blobs from server, see git sparse-checkout for more information:
{ stdenv, fetchgit }:
stdenv.mkDerivation {
name = "hello";
src = fetchgit {
url = "https://...";
sparseCheckout = [
"directory/to/be/included"
"another/directory"
];
hash = "sha256-AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};
}
fetchfossil
Used with Fossil. Expects url
to a Fossil archive, rev
, and hash
.
fetchcvs
Used with CVS. Expects cvsRoot
, tag
, and hash
.
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
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.
fetchFromGitHub
fetchFromGitHub
expects four arguments. owner
is a string corresponding to the GitHub user or organization that controls this repository. repo
corresponds to the name of the software repository. These are located at the top of every GitHub 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.
To use a different GitHub instance, use githubBase
(defaults to "github.com"
).
fetchFromGitHub
uses fetchzip
to download the source archive generated by GitHub for the specified revision. If leaveDotGit
, deepClone
or fetchSubmodules
are set to true
, fetchFromGitHub
will use fetchgit
instead. Refer to its section for documentation of these options.
fetchFromGitLab
This is used with GitLab repositories. It behaves similarly to fetchFromGitHub
, and expects owner
, repo
, rev
, and hash
.
To use a specific GitLab instance, use domain
(defaults to "gitlab.com"
).
fetchFromGitiles
This is used with Gitiles repositories. The arguments expected are similar to fetchgit
.
fetchFromBitbucket
This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub
above.
fetchFromSavannah
This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub
above.
fetchFromRepoOrCz
This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub
above.
fetchFromSourcehut
This is used with sourcehut repositories. Similar to fetchFromGitHub
above,
it expects owner
, repo
, rev
and hash
, but don't forget the tilde (~)
in front of the username! Expected arguments also include vc
("git" (default)
or "hg"), domain
and fetchSubmodules
.
If fetchSubmodules
is true
, fetchFromSourcehut
uses fetchgit
or fetchhg
with fetchSubmodules
or fetchSubrepos
set to true
,
respectively. Otherwise, the fetcher uses fetchzip
.
requireFile
requireFile
allows requesting files that cannot be fetched automatically, but whose content is known.
This is a useful last-resort workaround for license restrictions that prohibit redistribution, or for downloads that are only accessible after authenticating interactively in a browser.
If the requested file is present in the Nix store, the resulting derivation will not be built, because its expected output is already available.
Otherwise, the builder will run, but fail with a message explaining to the user how to provide the file. The following code, for example:
requireFile {
name = "jdk-${version}_linux-x64_bin.tar.gz";
url = "https://www.oracle.com/java/technologies/javase-jdk11-downloads.html";
hash = "sha256-lL00+F7jjT71nlKJ7HRQuUQ7kkxVYlZh//5msD8sjeI=";
}
results in this error message:
***
Unfortunately, we cannot download file jdk-11.0.10_linux-x64_bin.tar.gz automatically.
Please go to https://www.oracle.com/java/technologies/javase-jdk11-downloads.html to download it yourself, and add it to the Nix store
using either
nix-store --add-fixed sha256 jdk-11.0.10_linux-x64_bin.tar.gz
or
nix-prefetch-url --type sha256 file:///path/to/jdk-11.0.10_linux-x64_bin.tar.gz
***
This function should only be used by non-redistributable software with an unfree license that we need to require the user to download manually. It produces packages that cannot be built automatically.
fetchtorrent
fetchtorrent
expects two arguments. url
which can either be a Magnet URI (Magnet Link) such as magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c
or an HTTP URL pointing to a .torrent
file. It can also take a config
argument which will craft a settings.json
configuration file and give it to transmission
, the underlying program that is performing the fetch. The available config options for transmission
can be found here
{ fetchtorrent }:
fetchtorrent {
config = { peer-limit-global = 100; };
url = "magnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c";
sha256 = "";
}
Parameters
-
url
: Magnet URI (Magnet Link) such asmagnet:?xt=urn:btih:dd8255ecdc7ca55fb0bbf81323d87062db1f6d1c
or an HTTP URL pointing to a.torrent
file. -
backend
: Which bittorrent program to use. Default:"transmission"
. Valid values are"rqbit"
or"transmission"
. These are the two most suitable torrent clients for fetching in a fixed-output derivation at the time of writing, as they can be easily exited after usage.rqbit
is written in Rust and has a smaller closure size thantransmission
, and the performance and peer discovery properties differs between these clients, requiring experimentation to decide upon which is the best. -
config
: When usingtransmission
as thebackend
, a json configuration can be supplied to transmission. Refer to the upstream documentation for information on how to configure.