The devil's guide to Quicklisp projects

Stuart Overton asked me "How can I make my projects Quicklisp-friendly?"

Here are some answers to the opposite question: How can you make your projects Quicklisp-hostile?
  • Use a name that someone else is already using
  • Use SourceForge
  • Require extra steps to build, like running a shell script, make, ./configure, etc. outside of the asdf infrastructure
  • Require libraries (especially foreign libraries) that are hard to find, hard to build, or both
  • Bundle third-party libraries with your project; make sure they are either several versions out of date or locally modified in incompatible ways (stealth forking!)
  • Make symlinks a critical part of the build process
  • Your project name (cl-foo) should differ from its primary system name (foo, or even better, quux)
  • System names should not be boring, so try using mixed-case or exotic characters for your system file names
  • Make sure there are multiple forks of the project on github, the original one isn't the canonical one any more
  • Depend on your own personal utility library, which is clearly better in many respects than the twelve other utility libraries already available
  • Use your implementation's MOP and FFI directly instead of Closer to MOP and CFFI
  • Make releases at most once or twice per decade
  • Make your system definition be just a thin loader for your complicated loader script, which uses none of the defsystem's infrastructure or configuration
That's all I can think of for now...


  1. What's wrong with using SourceForge?

  2. Their CVS server is old enough that "cvs export" doesn't work in a very nice way.

    Their download pages are awkward. It can be hard to find a permanent link to download a tarball, what with ad pages and mirrors getting involved.

  3. Remind me how my code should load dependencies after I install them with (ql:quickload "some-dep"). The only way I've found so far is to evaluate that very expression inside my code.

  4. @Xach:
    folio needs a new fixes to reduce its quicklisp-hostility. Most notably, I should (and soon will) remove FSet from folio and rely upon the fact that Quicklisp provides Fset for me.

    Why was Fset included in folio to begin with? Because folio depends intimately on FSet, and I have always found it really annoying to have to hunt all over the net for some number of dependencies in order to try out some library. But Quicklisp does a good job of solving that problem for me, so I'm inclined to stop including dependencies in my libraries.

    There's some sort of positive feedback there, too: it makes packages that are already in Quicklisp significantly more attractive as dependencies than ones that are not.

    Just put :depends-on :foo in your asdf system definition when you want to use Foo. When you asdf-load your system, if Fo is not present, asdf will complain. Then you can do (ql:quickload "foo") just that one time. On future loads (as long as your Lisp's init file loads quicklisp), asdf will automagically find Foo for you.

    Maybe there is room for some simple utility that one can use to load ones project with ASDF, and that catches missing dependencies and attempts to automagically quickload them?

  5. ql:quickload will already load local projects and automatically fetch missing dependencies. See http://www.quicklisp.org/beta/#basic-commands for info.