Common Lisp, Asdf, and Quicklisp: Packaging Explained
Postedabout 1 month agoActive29 days ago
cdegroot.comTech Discussionstory
informativepositive
Debate
20/100
Common LispDependency_managementQuicklisp
Key topics
Common Lisp
Dependency_management
Quicklisp
Discussion Activity
Active discussionFirst comment
12h
Peak period
14
12-18h
Avg / period
5.1
Comment distribution36 data points
Loading chart...
Based on 36 loaded comments
Key moments
- 01Story posted
Dec 10, 2025 at 6:10 AM EST
about 1 month ago
Step 01 - 02First comment
Dec 10, 2025 at 6:34 PM EST
12h after posting
Step 02 - 03Peak activity
14 comments in 12-18h
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 12, 2025 at 7:15 PM EST
29 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46216446Type: storyLast synced: 12/13/2025, 7:10:29 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It's hamstrung by archaic naming conventions that confuse newcomers. What CL calls a system is roughly analogous to what most other languages call a package. What CL calls a package is what other languages call a namespace.
Despite all that it's a pretty good language if you can find libraries for what you need. The de facto standard implementation (sbcl) has a very good compiler and an acceptable GC. The language itself is expressive and it makes for very quick and pleasant DX. I love writing common lisp.
Or a crate, or an artifact, or a module, or a gem, and there's probably other variations I can't remember off-hand.
> * What CL calls a package is what other languages call a namespace.*
Or a module, or a package, or... actually, I don't know what Perl or Ruby call it. I believe C calls it a header, but that's not quite the same thing as a package.
Turns out naming things is difficult (as well as cache invalidation, off-by-one errors concurrency, and).
(1) https://docs.racket-lang.org/pkg/index.html
You can always just add a version check and error out if it's too outdated. The thing there isn't an easy way to do is say "this needs a version of that system lower than X" but it would be unusual for a system to intentionally break backwards compatibility (or for an unintentional break to not be fixed relatively quickly after being discovered); usually if there is the semver equivalent of a "major version" change in lisp, the system-name itself gets changed.
https://github.com/fukamachi/qlot/
https://github.com/ocicl/ocicl/
https://github.com/fosskers/vend/ (new)
Use HTTPS instead of HTTP - https://github.com/quicklisp/quicklisp-client/issues/167
https://susam.net/lisp-in-vim.html
https://github.com/susam/emacs4cl
However, I usually just download the packages I need with a simple while loop:
https://github.com/susam/susam.net/blob/0.4.0/Makefile#L83-L...
https://github.com/susam/susam.net/blob/0.4.0/meta/cldeps/fo...
Then I point ASDF to the download directory with CL_SOURCE_REGISTRY and load it in my Lisp program using good old ASDF:LOAD-SYSTEM:
https://github.com/susam/susam.net/blob/0.4.0/etc/form.servi...
https://github.com/susam/susam.net/blob/0.4.0/form.lisp#L5
The last four links I have shared above all get automated by a simple QL:QUICKLOAD call if we're using Quicklisp.
But, yeah, while I do not like submodules, for vendoring stuff it seems a reasonable approach. There's also https://github.com/fosskers/vend if you lean that way.
https://www.gnu.org/software/emacs/manual/html_mono/woman.ht...
more: https://lispcookbook.github.io/cl-cookbook/
libraries: https://github.com/CodyReichert/awesome-cl/
I think that that's one of the strengths and one of the weaknesses of CL and its ecosystem. Rolling your own variation is just too easy and it almost seems to be encouraged. Which artificially steepens the learning curve. Anyway, I decided to focus on just "packaging", but I agree that testing needs attention, just like all the other topics people here touched on: secure distribution, versioning and pinning, and all these other modern comforts we're used to when doing our daytime non-Common-Lisp jobs :)
That is to say, a cargo-, uv-, homebrew-, golang-style all-in-one CLI tool that has opinionated defaults, reasonable basic functionality (lockfiles, hashing, HTTPS) and is thoroughly idiot-proof ('approachable') for beginners.
To be entirely honest though, I don't sense that the CL community is interested in that kind of onboarding though, and so I expect the language to continue its slide into senescence, sadly.
The kind of CLI tool I think would be necessary would need to (a) be able to download, manage, pin (etc) various CL compilers, (b) offer a REPL where - at minimum - rlwrap functionality is included, but preferably is as interactive as something like `irb`, (c) offer comparable ease of use to tools like cargo. That is tot say - language management, project management, package management, accessible at logical keywords under an all-in-one tool (i.e. what everyone else is doing).
The REPL is meant to be the soul of CL, and yet by default the average newcomer can't even use arrow keys or backspace in SBCL. Sure, sure, they should use rlwrap, but they'd have to know that exists, and they generally don't. So they'll go back to Python or Node, and not worry about a language that can't even figure out backspaces (from their perspective).
Both OCaml and Haskell have invested heavily in their tooling recently, to good effect. CL... not so much.