pyrox.dev
1# Agda {#agda}
2
3## How to use Agda {#how-to-use-agda}
4
5Agda is available as the [agda](https://search.nixos.org/packages?channel=unstable&show=agda&from=0&size=30&sort=relevance&query=agda)
6package.
7
8The `agda` package installs an Agda-wrapper, which calls `agda` with `--library-file`
9set to a generated library-file within the nix store, this means your library-file in
10`$HOME/.agda/libraries` will be ignored. By default the agda package installs Agda
11with no libraries, i.e. the generated library-file is empty. To use Agda with libraries,
12the `agda.withPackages` function can be used. This function either takes:
13
14* A list of packages,
15* or a function which returns a list of packages when given the `agdaPackages` attribute set,
16* or an attribute set containing a list of packages and a GHC derivation for compilation (see below).
17* or an attribute set containing a function which returns a list of packages when given the `agdaPackages` attribute set and a GHC derivation for compilation (see below).
18
19For example, suppose we wanted a version of Agda which has access to the standard library. This can be obtained with the expressions:
20
21```nix
22agda.withPackages [ agdaPackages.standard-library ]
23```
24
25or
26
27```nix
28agda.withPackages (p: [ p.standard-library ])
29```
30
31or can be called as in the [Compiling Agda](#compiling-agda) section.
32
33If you want to use a different version of a library (for instance a development version)
34override the `src` attribute of the package to point to your local repository
35
36```nix
37agda.withPackages (p: [
38 (p.standard-library.overrideAttrs (oldAttrs: {
39 version = "local version";
40 src = /path/to/local/repo/agda-stdlib;
41 }))
42])
43```
44
45You can also reference a GitHub repository
46
47```nix
48agda.withPackages (p: [
49 (p.standard-library.overrideAttrs (oldAttrs: {
50 version = "1.5";
51 src = fetchFromGitHub {
52 repo = "agda-stdlib";
53 owner = "agda";
54 rev = "v1.5";
55 hash = "sha256-nEyxYGSWIDNJqBfGpRDLiOAnlHJKEKAOMnIaqfVZzJk=";
56 };
57 }))
58])
59```
60
61If you want to use a library not added to Nixpkgs, you can add a
62dependency to a local library by calling `agdaPackages.mkDerivation`.
63
64```nix
65agda.withPackages (p: [
66 (p.mkDerivation {
67 pname = "your-agda-lib";
68 version = "1.0.0";
69 src = /path/to/your-agda-lib;
70 })
71])
72```
73
74Again you can reference GitHub
75
76```nix
77agda.withPackages (p: [
78 (p.mkDerivation {
79 pname = "your-agda-lib";
80 version = "1.0.0";
81 src = fetchFromGitHub {
82 repo = "repo";
83 owner = "owner";
84 version = "...";
85 rev = "...";
86 hash = "...";
87 };
88 })
89])
90```
91
92See [Building Agda Packages](#building-agda-packages) for more information on `mkDerivation`.
93
94Agda will not by default use these libraries. To tell Agda to use a library we have some options:
95
96* Call `agda` with the library flag:
97 ```ShellSession
98 $ agda -l standard-library -i . MyFile.agda
99 ```
100* Write a `my-library.agda-lib` file for the project you are working on which may look like:
101 ```
102 name: my-library
103 include: .
104 depend: standard-library
105 ```
106* Create the file `~/.agda/defaults` and add any libraries you want to use by default.
107
108More information can be found in the [official Agda documentation on library management](https://agda.readthedocs.io/en/v2.6.1/tools/package-system.html).
109
110## Compiling Agda {#compiling-agda}
111
112Agda modules can be compiled using the GHC backend with the `--compile` flag. A version of `ghc` with `ieee754` is made available to the Agda program via the `--with-compiler` flag.
113This can be overridden by a different version of `ghc` as follows:
114
115```nix
116agda.withPackages {
117 pkgs = [ /* ... */ ];
118 ghc = haskell.compiler.ghcHEAD;
119}
120```
121
122## Writing Agda packages {#writing-agda-packages}
123
124To write a nix derivation for an Agda library, first check that the library has a `*.agda-lib` file.
125
126A derivation can then be written using `agdaPackages.mkDerivation`. This has similar arguments to `stdenv.mkDerivation` with the following additions:
127
128* `everythingFile` can be used to specify the location of the `Everything.agda` file, defaulting to `./Everything.agda`. If this file does not exist then either it should be patched in or the `buildPhase` should be overridden (see below).
129* `libraryName` should be the name that appears in the `*.agda-lib` file, defaulting to `pname`.
130* `libraryFile` should be the file name of the `*.agda-lib` file, defaulting to `${libraryName}.agda-lib`.
131
132Here is an example `default.nix`
133
134```nix
135{ nixpkgs ? <nixpkgs> }:
136with (import nixpkgs {});
137agdaPackages.mkDerivation {
138 version = "1.0";
139 pname = "my-agda-lib";
140 src = ./.;
141 buildInputs = [
142 agdaPackages.standard-library
143 ];
144}
145```
146
147### Building Agda packages {#building-agda-packages}
148
149The default build phase for `agdaPackages.mkDerivation` runs `agda` on the `Everything.agda` file.
150If something else is needed to build the package (e.g. `make`) then the `buildPhase` should be overridden.
151Additionally, a `preBuild` or `configurePhase` can be used if there are steps that need to be done prior to checking the `Everything.agda` file.
152`agda` and the Agda libraries contained in `buildInputs` are made available during the build phase.
153
154### Installing Agda packages {#installing-agda-packages}
155
156The default install phase copies Agda source files, Agda interface files (`*.agdai`) and `*.agda-lib` files to the output directory.
157This can be overridden.
158
159By default, Agda sources are files ending on `.agda`, or literate Agda files ending on `.lagda`, `.lagda.tex`, `.lagda.org`, `.lagda.md`, `.lagda.rst`. The list of recognised Agda source extensions can be extended by setting the `extraExtensions` config variable.
160
161## Maintaining the Agda package set on Nixpkgs {#maintaining-the-agda-package-set-on-nixpkgs}
162
163We are aiming at providing all common Agda libraries as packages on `nixpkgs`,
164and keeping them up to date.
165Contributions and maintenance help is always appreciated,
166but the maintenance effort is typically low since the Agda ecosystem is quite small.
167
168The `nixpkgs` Agda package set tries to take up a role similar to that of [Stackage](https://www.stackage.org/) in the Haskell world.
169It is a curated set of libraries that:
170
1711. Always work together.
1722. Are as up-to-date as possible.
173
174While the Haskell ecosystem is huge, and Stackage is highly automatised,
175the Agda package set is small and can (still) be maintained by hand.
176
177### Adding Agda packages to Nixpkgs {#adding-agda-packages-to-nixpkgs}
178
179To add an Agda package to `nixpkgs`, the derivation should be written to `pkgs/development/libraries/agda/${library-name}/` and an entry should be added to `pkgs/top-level/agda-packages.nix`. Here it is called in a scope with access to all other Agda libraries, so the top line of the `default.nix` can look like:
180
181```nix
182{ mkDerivation, standard-library, fetchFromGitHub }:
183{}
184```
185
186Note that the derivation function is called with `mkDerivation` set to `agdaPackages.mkDerivation`, therefore you
187could use a similar set as in your `default.nix` from [Writing Agda Packages](#writing-agda-packages) with
188`agdaPackages.mkDerivation` replaced with `mkDerivation`.
189
190Here is an example skeleton derivation for iowa-stdlib:
191
192```nix
193mkDerivation {
194 version = "1.5.0";
195 pname = "iowa-stdlib";
196
197 src = <...>;
198
199 libraryFile = "";
200 libraryName = "IAL-1.3";
201
202 buildPhase = ''
203 patchShebangs find-deps.sh
204 make
205 '';
206}
207```
208
209This library has a file called `.agda-lib`, and so we give an empty string to `libraryFile` as nothing precedes `.agda-lib` in the filename. This file contains `name: IAL-1.3`, and so we let `libraryName = "IAL-1.3"`. This library does not use an `Everything.agda` file and instead has a Makefile, so there is no need to set `everythingFile` and we set a custom `buildPhase`.
210
211When writing an Agda package it is essential to make sure that no `.agda-lib` file gets added to the store as a single file (for example by using `writeText`). This causes Agda to think that the nix store is a Agda library and it will attempt to write to it whenever it typechecks something. See [https://github.com/agda/agda/issues/4613](https://github.com/agda/agda/issues/4613).
212
213In the pull request adding this library,
214you can test whether it builds correctly by writing in a comment:
215
216```
217@ofborg build agdaPackages.iowa-stdlib
218```
219
220### Maintaining Agda packages {#agda-maintaining-packages}
221
222As mentioned before, the aim is to have a compatible, and up-to-date package set.
223These two conditions sometimes exclude each other:
224For example, if we update `agdaPackages.standard-library` because there was an upstream release,
225this will typically break many reverse dependencies,
226i.e. downstream Agda libraries that depend on the standard library.
227In `nixpkgs` we are typically among the first to notice this,
228since we have build tests in place to check this.
229
230In a pull request updating e.g. the standard library, you should write the following comment:
231
232```
233@ofborg build agdaPackages.standard-library.passthru.tests
234```
235
236This will build all reverse dependencies of the standard library,
237for example `agdaPackages.agda-categories`, or `agdaPackages.generic`.
238
239In some cases it is useful to build _all_ Agda packages.
240This can be done with the following Github comment:
241
242```
243@ofborg build agda.passthru.tests.allPackages
244```
245
246Sometimes, the builds of the reverse dependencies fail because they have not yet been updated and released.
247You should drop the maintainers a quick issue notifying them of the breakage,
248citing the build error (which you can get from the ofborg logs).
249If you are motivated, you might even send a pull request that fixes it.
250Usually, the maintainers will answer within a week or two with a new release.
251Bumping the version of that reverse dependency should be a further commit on your PR.
252
253In the rare case that a new release is not to be expected within an acceptable time,
254mark the broken package as broken by setting `meta.broken = true;`.
255This will exclude it from the build test.
256It can be added later when it is fixed,
257and does not hinder the advancement of the whole package set in the meantime.