tjh.dev
1## Importing package definitions from Quicklisp
2
3This page documents how to import packages from Quicklisp.
4
5## Nix dumper
6
7Run:
8
9```
10$ nix-shell
11$ sbcl --script ql-import.lisp
12```
13
14This command runs a program that dumps a `imported.nix` file
15containing Nix expressions for all packages in Quicklisp. They will be
16automatically picked up by the `lispPackagesFor` and
17`lispWithPackages` API functions.
18
19It also creates a 'packages.sqlite' file. It's used during the
20generation of the 'imported.nix' file and can be safely removed. It
21contains the full information of Quicklisp packages, so you can use it
22to query the dependency graphs using SQL, if you're interested.
23
24## Tarball hashes
25
26The Nix dumper program will re-use hashes from "imported.nix" if it
27detects that it's being run for the first time. This saves a lot of
28bandwidth by not having to download each tarball again.
29
30But when upgrading the Quicklisp release URL, this can take a while
31because it needs to fetch the source code of each new system to
32compute its SHA256 hash. This is because Quicklisp only provides a
33SHA1 , and Nix's `builtins.fetchTarball` requires a SHA256.
34
35Later on, the hashes are cached in `packages.sqlite`, and are reused
36in subsequent invocations. Therefore you might want to keep the
37'packages.sqlite' file around if you'd like to keep hashes of
38historical Quicklisp tarballs, for example for archival purposes.
39
40## Choosing a Quicklisp release
41
42Quicklisp release url's are currently hard-coded and can be changed
43directly in the source code. See the `import` directory.
44
45## Native and Java libraries
46
47At the moment, native and Java libraries need to be added manually to
48imported systems in `ql.nix` on an as-needed basis.
49
50## Dependencies from packages.nix
51
52Also worth noting is that systems imported from Quicklisp will prefer
53packages from `packages.nix` as dependencies, so that custom versions
54can be provided or broken versions replaced.