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