commit hash (`rev`). Note that unlike Git, GitHub allows fetching by
commit hash without specifying a branch or tag.
You can also specify `host` as a parameter, to point to a custom GitHub
Enterprise server.
Some examples:
* `github:edolstra/dwarffs`
* `github:edolstra/dwarffs/unstable`
* `github:edolstra/dwarffs/d3f2baba8f425779026c6ec04021b2e927f61e31`
* `github:internal/project?host=company-github.example.org`
* `gitlab`: Similar to `github`, is a more efficient way to fetch
GitLab repositories. The following attributes are required:
* `owner`: The owner of the repository.
* `repo`: The name of the repository.
Like `github`, these are downloaded as tarball archives.
The URL syntax for `gitlab` flakes is:
`gitlab:<owner>/<repo>(/<rev-or-ref>)?(\?<params>)?`
`<rev-or-ref>` works the same as `github`. Either a branch or tag name
(`ref`), or a commit hash (`rev`) can be specified.
Since GitLab allows for self-hosting, you can specify `host` as
a parameter, to point to any instances other than `gitlab.com`.
Some examples:
* `gitlab:veloren/veloren`
* `gitlab:veloren/veloren/master`
* `gitlab:veloren/veloren/80a4d7f13492d916e47d6195be23acae8001985a`
* `gitlab:openldap/openldap?host=git.openldap.org`
When accessing a project in a (nested) subgroup, make sure to URL-encode any
slashes, i.e. replace `/` with `%2F`:
* `gitlab:veloren%2Fdev/rfcs`
* `sourcehut`: Similar to `github`, is a more efficient way to fetch
SourceHut repositories. The following attributes are required:
* `owner`: The owner of the repository (including leading `~`).
* `repo`: The name of the repository.
Like `github`, these are downloaded as tarball archives.
The URL syntax for `sourcehut` flakes is:
`sourcehut:<owner>/<repo>(/<rev-or-ref>)?(\?<params>)?`
`<rev-or-ref>` works the same as `github`. Either a branch or tag name
(`ref`), or a commit hash (`rev`) can be specified.
Since SourceHut allows for self-hosting, you can specify `host` as
a parameter, to point to any instances other than `git.sr.ht`.
Currently, `ref` name resolution only works for Git repositories.
You can refer to Mercurial repositories by simply changing `host` to
`hg.sr.ht` (or any other Mercurial instance). With the caveat
that you must explicitly specify a commit hash (`rev`).
Some examples:
* `sourcehut:~misterio/nix-colors`
* `sourcehut:~misterio/nix-colors/main`
* `sourcehut:~misterio/nix-colors?host=git.example.org`
* `sourcehut:~misterio/nix-colors/182b4b8709b8ffe4e9774a4c5d6877bf6bb9a21c`
* `sourcehut:~misterio/nix-colors/21c1a380a6915d890d408e9f22203436a35bb2de?host=hg.sr.ht`
# Flake format
As an example, here is a simple `flake.nix` that depends on the
Nixpkgs flake and provides a single package (i.e. an
[installable](./nix.md#installables) derivation):
```nix
{
description = "A flake for building Hello World";
inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-20.03";
outputs = { self, nixpkgs }: {
packages.x86_64-linux.default =
# Notice the reference to nixpkgs here.
with import nixpkgs { system = "x86_64-linux"; };
stdenv.mkDerivation {
name = "hello";
src = self;
buildPhase = "gcc -o hello ./hello.c";
installPhase = "mkdir -p $out/bin; install -t $out/bin hello";
};
};
}
```
The following attributes are supported in `flake.nix`:
* `description`: A short, one-line description of the flake.
* `inputs`: An attrset specifying the dependencies of the flake
(described below).
* `outputs`: A function that, given an attribute set containing the
outputs of each of the input flakes keyed by their identifier,
yields the Nix values provided by this flake. Thus, in the example
above, `inputs.nixpkgs` contains the result of the call to the
`outputs` function of the `nixpkgs` flake.
In addition to the outputs of each input, each input in `inputs`
also contains some metadata about the inputs. These are: