1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
## 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:
1. Installing a Lisp implementation
2. Installing a package manager
3. 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 `--fancy` flag
- 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])
[zlib]: https://zlib.net
[SBCL]: https://sbcl.org
[ECL]: https://ecl.common-lisp.dev/
[Ultralisp]: https://ultralisp.org/
[jzon]: https://github.com/Zulu-Inuoe/jzon
[cl-tar]: https://gitlab.common-lisp.net/cl-tar/cl-tar
[bootstrap tools]: https://github.com/NixOS/nixpkgs/tree/master/pkgs/stdenv/linux/bootstrap-files
[nixpkgs]: https://github.com/NixOS/nixpkgs
## 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.
|