From 16d733bbe58baa9e4dfd1912d13d7fdc59268212 Mon Sep 17 00:00:00 2001 From: Frederik Rietdijk Date: Sun, 20 Oct 2019 13:34:32 +0200 Subject: doc: move fetchers and trivial builders under builders --- doc/builders/fetchers.xml | 148 +++++++++++++++++++++++++++++++++++++ doc/builders/trivial-builders.xml | 79 ++++++++++++++++++++ doc/functions.xml | 2 - doc/functions/fetchers.xml | 148 ------------------------------------- doc/functions/trivial-builders.xml | 79 -------------------- doc/manual.xml | 4 +- 6 files changed, 230 insertions(+), 230 deletions(-) create mode 100644 doc/builders/fetchers.xml create mode 100644 doc/builders/trivial-builders.xml delete mode 100644 doc/functions/fetchers.xml delete mode 100644 doc/functions/trivial-builders.xml diff --git a/doc/builders/fetchers.xml b/doc/builders/fetchers.xml new file mode 100644 index 00000000000..6f8990e8d16 --- /dev/null +++ b/doc/builders/fetchers.xml @@ -0,0 +1,148 @@ + + Fetchers + + + When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way. + + + + The two fetcher primitives are fetchurl and fetchzip. Both of these have two required arguments, a URL and a hash. The hash is typically sha256, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use sha256. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below. + + + + + + The main difference between fetchurl and fetchzip is in how they store the contents. fetchurl will store the unaltered contents of the URL within the Nix store. fetchzip on the other hand will decompress the archive for you, making files and directories directly accessible in the future. fetchzip can only be used with archives. Despite the name, fetchzip is not limited to .zip files and can also be used with any tarball. + + + + fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and 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. + + + + Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward names based on the name of the command used with the VCS system. Because they give you a working repository, they act most like fetchzip. + + + + + + fetchsvn + + + + Used with Subversion. Expects url to a Subversion directory, rev, and sha256. + + + + + + fetchgit + + + + Used with Git. Expects url to a Git repo, rev, and sha256. rev in this case can be full the git commit id (SHA1 hash) or a tag name like refs/tags/v1.0. + + + + + + fetchfossil + + + + Used with Fossil. Expects url to a Fossil archive, rev, and sha256. + + + + + + fetchcvs + + + + Used with CVS. Expects cvsRoot, tag, and sha256. + + + + + + fetchhg + + + + Used with Mercurial. Expects url, rev, and sha256. + + + + + + + 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. + + + + + + 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, sha256 corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but sha256 is currently preferred. + + + + + + fetchFromGitLab + + + + This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above. + + + + + + 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. + + + + + diff --git a/doc/builders/trivial-builders.xml b/doc/builders/trivial-builders.xml new file mode 100644 index 00000000000..c99425620b1 --- /dev/null +++ b/doc/builders/trivial-builders.xml @@ -0,0 +1,79 @@ + + Trivial builders + + + Nixpkgs provides a couple of functions that help with building derivations. The most important one, stdenv.mkDerivation, has already been documented above. The following functions wrap stdenv.mkDerivation, making it easier to use in certain cases. + + + + + + runCommand + + + + This takes three arguments, name, env, and buildCommand. name is just the name that Nix will append to the store path in the same way that stdenv.mkDerivation uses its name attribute. env is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped stdenv.mkDerivation. buildCommand specifies the commands that will be run to create this derivation. Note that you will need to create $out for Nix to register the command as successful. + + + An example of using runCommand is provided below. + + +(import <nixpkgs> {}).runCommand "my-example" {} '' + echo My example command is running + + mkdir $out + + echo I can write data to the Nix store > $out/message + + echo I can also run basic commands like: + + echo ls + ls + + echo whoami + whoami + + echo date + date +'' + + + + + + runCommandCC + + + + This works just like runCommand. The only difference is that it also provides a C compiler in buildCommand’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command. + + + + + + writeTextFile, writeText, writeTextDir, writeScript, writeScriptBin + + + + These functions write text to the Nix store. This is useful for creating scripts from Nix expressions. writeTextFile takes an attribute set and expects two arguments, name and text. name corresponds to the name used in the Nix store path. text will be the contents of the file. You can also set executable to true to make this file have the executable bit set. + + + Many more commands wrap writeTextFile including writeText, writeTextDir, writeScript, and writeScriptBin. These are convenience functions over writeTextFile. + + + + + + symlinkJoin + + + + This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, name, and paths. name is the name used in the Nix store path for the created derivation. paths is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within. + + + + + diff --git a/doc/functions.xml b/doc/functions.xml index 3e126e6b139..81aef5f3a83 100644 --- a/doc/functions.xml +++ b/doc/functions.xml @@ -10,8 +10,6 @@ - - diff --git a/doc/functions/fetchers.xml b/doc/functions/fetchers.xml deleted file mode 100644 index 369c1fb153e..00000000000 --- a/doc/functions/fetchers.xml +++ /dev/null @@ -1,148 +0,0 @@ -
- Fetcher functions - - - When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way. - - - - The two fetcher primitives are fetchurl and fetchzip. Both of these have two required arguments, a URL and a hash. The hash is typically sha256, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use sha256. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below. - - - - - - The main difference between fetchurl and fetchzip is in how they store the contents. fetchurl will store the unaltered contents of the URL within the Nix store. fetchzip on the other hand will decompress the archive for you, making files and directories directly accessible in the future. fetchzip can only be used with archives. Despite the name, fetchzip is not limited to .zip files and can also be used with any tarball. - - - - fetchpatch works very similarly to fetchurl with the same arguments expected. It expects patch files as a source and 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. - - - - Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward names based on the name of the command used with the VCS system. Because they give you a working repository, they act most like fetchzip. - - - - - - fetchsvn - - - - Used with Subversion. Expects url to a Subversion directory, rev, and sha256. - - - - - - fetchgit - - - - Used with Git. Expects url to a Git repo, rev, and sha256. rev in this case can be full the git commit id (SHA1 hash) or a tag name like refs/tags/v1.0. - - - - - - fetchfossil - - - - Used with Fossil. Expects url to a Fossil archive, rev, and sha256. - - - - - - fetchcvs - - - - Used with CVS. Expects cvsRoot, tag, and sha256. - - - - - - fetchhg - - - - Used with Mercurial. Expects url, rev, and sha256. - - - - - - - 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. - - - - - - 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, sha256 corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but sha256 is currently preferred. - - - - - - fetchFromGitLab - - - - This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above. - - - - - - 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. - - - - -
diff --git a/doc/functions/trivial-builders.xml b/doc/functions/trivial-builders.xml deleted file mode 100644 index ae9f3a1b255..00000000000 --- a/doc/functions/trivial-builders.xml +++ /dev/null @@ -1,79 +0,0 @@ -
- Trivial builders - - - Nixpkgs provides a couple of functions that help with building derivations. The most important one, stdenv.mkDerivation, has already been documented above. The following functions wrap stdenv.mkDerivation, making it easier to use in certain cases. - - - - - - runCommand - - - - This takes three arguments, name, env, and buildCommand. name is just the name that Nix will append to the store path in the same way that stdenv.mkDerivation uses its name attribute. env is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped stdenv.mkDerivation. buildCommand specifies the commands that will be run to create this derivation. Note that you will need to create $out for Nix to register the command as successful. - - - An example of using runCommand is provided below. - - -(import <nixpkgs> {}).runCommand "my-example" {} '' - echo My example command is running - - mkdir $out - - echo I can write data to the Nix store > $out/message - - echo I can also run basic commands like: - - echo ls - ls - - echo whoami - whoami - - echo date - date -'' - - - - - - runCommandCC - - - - This works just like runCommand. The only difference is that it also provides a C compiler in buildCommand’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command. - - - - - - writeTextFile, writeText, writeTextDir, writeScript, writeScriptBin - - - - These functions write text to the Nix store. This is useful for creating scripts from Nix expressions. writeTextFile takes an attribute set and expects two arguments, name and text. name corresponds to the name used in the Nix store path. text will be the contents of the file. You can also set executable to true to make this file have the executable bit set. - - - Many more commands wrap writeTextFile including writeText, writeTextDir, writeScript, and writeScriptBin. These are convenience functions over writeTextFile. - - - - - - symlinkJoin - - - - This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, name, and paths. name is the name used in the Nix store path for the created derivation. paths is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within. - - - - -
diff --git a/doc/manual.xml b/doc/manual.xml index 001a5f3eca5..d0ded1e2e16 100644 --- a/doc/manual.xml +++ b/doc/manual.xml @@ -21,7 +21,9 @@ - Languages, frameworks and packages + Builders + + -- cgit 1.4.1