Quicklisp provides a lot of software, but there’s also a simple way to load things that Quicklisp doesn’t provide. That same mechanism can be used to override libraries Quicklisp does provide.
The local projects mechanism sets up a special directory that is automatically scanned for software to load. Here are a few quick examples.
Trying a library not in Quicklisp
First, imagine that you just heard about a great new library and want to try it. However, it’s not available through Quicklisp yet, only through a git repository on https://example.com/fun-project.git. One easy way to try it:
$ cd ~/quicklisp/local-projects $ git clone https://example.com/fun-project.git
After the git command completes, and there is a
fun-projectsubdirectory with a
fun-project/fun-project.asdfile present, the system is visible to ASDF and can be loaded either with
asdf:find-system. When loaded through
ql:quickload, Quicklisp will automatically fetch and load any prerequisites if needed.
Overriding a library in Quicklisp
Second, imagine that you want to hack on a library that Quicklisp already provides. You don’t want to load and hack on the version from Quicklisp - that software is not under version control, and just represents a snapshot of the project at a particular point in time.
Once again, the procedure is to put the software in the
$ cd ~/quicklisp/local-projects/ $ git clone https://github.com/xach/vecto.git
After the git command completes,
(ql:quickload "vecto")will load the library from local-projects rather than from the standard Quicklisp release.
How it works
The local-projects mechanism is relatively automatic. Here’s how it works underneath, and how to fix problems that might crop up.
ASDF has an extensible mechansim (the
asdf:*system-definition-search-functions*variable) for searching for system files. Quicklisp extends this mechanism with a function that does the following, all in the context of the
- If there is no file named system-index.txt, it is created by scanning the directory tree for system files (matching "*.asd"). Each pathname is added to the file.
- If the system-index.txt file exists, but its timestamp is older than its containing directory, the directory is rescanned and the index recreated.
- The system-index.txt is searched for any entry with a pathname-name that matches the desired system name. If there’s a match, matching pathname is probed. If it still exists, it is returned. If it has disappeared, the system-index.txt is recreated as in step 1 and the search is retried.
- Otherwise the system search is deferred to the remaining ASDF system search functions.
When there are multiple system files with the same name in the directory tree, the one with the shortest full pathname name is returned. In the case of a pathname length tie, the one that is
Timestamp problems can sometimes crop up with step 2 above. For example, if you have a directory
local-projects/my-project/and you create
local-projects/my-project/supporting-system.asd, the timestamp of
local-projects/is not updated and
supporting-system.asdwon’t be automatically added to the system index file.
There are a couple ways to force an update of the system index file. Within Lisp, you can use
(ql:register-local-projects)to immediately regenerate system-index.txt. Outside of Lisp, you can use the
touchcommand (or an equivalent) to update the timestamp of the local-projects directory, which will trigger a rebuild of the index on the next attempt to find systems..
Because of how the system index file is created (and recreated as needed), Quicklisp must have write access to the local-projects directory to make use of it.
The local-projects mechanism is configured through a special variable
ql:*local-project-directories*. By default, it includes only the
local-projectssubdirectory in the Quicklisp install directory, but you can add or remove directories at any time to have more places scanned for systems.
To disable the local-projects mechanism entirely, set