Common Lisp, ASDF, and Quicklisp: packaging explained

I'd suggest you submodule in dependencies rather than curl. Supply chain attacks and version incompatibilities both happen and suck

  curl -sSL https://github.com/edicl/hunchentoot/archive/v1.3.1.tar.gz | tar -xz

  git submodule add https://github.com/edicl/hunchentoot.git && cd hunchentoot/ && git checkout v1.3.1

?

For anybody who's still confused, the tl;dr is ASDF is the actual package loading mechanism, Quicklisp doubles as an ASDF wrapper and a package manager.

The packaging story in common lisp is.... Not great.

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.

YMMV, of course. I switched to it half a year or so ago, when doing a close read of the ASDF docs, and for my purposes it works well. But I may be odd: I have a monorepo of Lisp code which I don't intend to distribute in the sense of turning them into Open Source packages. There's an `l` subdirectory for libraries, a `p` subdirectory for "projects", and if I need something I can just import `ca.berksoft.l/math/fft` and be done. I think that having a file-per-package is not a limitation, it makes packages probably a bit more like modules in my daytime language (Elixir/Erlang), and it does save a lot of typing telling ASDF what to find where.

You can pin dependencies with Qlot or Ocicl (or vendor them with vend), but it might be a long time before you actually need this (the ecosystem is pretty darn stable).

https://github.com/fukamachi/qlot/

https://github.com/ocicl/ocicl/

https://github.com/fosskers/vend/ (new)

TL;DR: If I find a library I'm using would need dependency versioning, I consider that library broken and find (or write) an alternative.

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.

Last time I checked quicklisp also didn’t support https and doesn’t do any signature checking.

Mine is GNU WoMan, an alternative to man.

https://www.gnu.org/software/emacs/manual/html_mono/woman.ht...

Don't forget about UIOP (Utilities for Implementation and OS Portability) which is part of the ASDF project. Also very easy to type!

I considered that (author here), but how I test is way too odd to share lol.

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 :)

https://sabracrolleton.github.io/testing-framework There's this pretty in-depth comparison of testing frameworks, but I'm not sure if any of the frameworks there satisfy your specifications.