3.5 KiB
Use cases
This page lists some possible use cases for nix-cl.
Pinning down the exact commits of libraries
Sometimes, a bug is fixed upstream but is not yet available in package repositories such as Quicklisp or Ultralisp. The users have to wait for the repository maintainer to update it, or download and compile the patched sources themselves.
This is a manual and hard to reproduce process. By leveraging Nix,
users of nix-cl can essentially "run their own package repository",
written as Nix code, with all the benefits of that (shareability,
cacheability, reproducibility, version-controllable etc.)
Modifying libraries with patches
Other times, a bug in a library is not fixed upstream, but you fixed it yourself. Or, you would like a change to the internals that the maintainers don't like.
Sure, you could fork the code or maintain patches manually, but that becomes hard to manage with a lot of patches. It also doesn't have the benefits mentioned in the previous section.
nix-cl provides a way of applying version-controlled patches to any
package.
Using libraries not available in repositories
There are useful and working libraries out there, that are nontheless unavailable to users of package managers such as Quicklisp or Ultralisp. Two real-world examples are jzon and cl-tar.
nix-cl is not tied to any particular package source: instead,
packages are written as a Nix expression, which can be done manually
or generated/imported.
This frees the user to have any package they want, and not be constrained by a central repository.
Reproducible environments
The usual way to develop a project involves several steps, such as:
- Installing a Lisp implementation
- Installing a package manager
- Installing the chosen libraries
This is not necessarily reproducible. It's unlikely to come back a year later and develop the project using the exact same versions of the dependencies.
Things can break between attempts at different points in time. The repository could have updated versions in the meantime. The source tarballs could become unreachable.
With nix-cl you can have your own binary cache for Lisp libraries
and not be affected by downtime of other central repositories.
Testing across CL implementations
One can manually download different Lisp implementations and run tests of a package. This works well in most cases, but it is limited in how you can tweak the software. Some practical examples are:
- Statically compiling zlib into SBCL
- Building SBCL with the
--fancyflag - Compiling ECL as a static library
These are usually hard to do manually, unless you have the necessary compilers already configured. These combinations are usually not available from package managers as well.
With Nix it's easier, because it will set up the build environment automatically. It could be useful to, for example:
- Test against all possible compiler flag combinations
- Libc versions (ECL)
- JDK versions ([ABCL])
Windows note
Note that all of this still only applies to Unix systems - primarily because Nix doesn't work on Windows.
If you have an idea how to port some of the functionality to Windows, get in touch.