pkgs/development/lisp-modules-new-obsolete/doc/nix-cl.md

   1 ## Use cases
   2
   3 This page lists some possible use cases for nix-cl.
   4
   5 ## Pinning down the exact commits of libraries
   6
   7 Sometimes, a bug is fixed upstream but is not yet available in package
   8 repositories such as Quicklisp or Ultralisp. The users have to wait
   9 for the repository maintainer to update it, or download and compile
  10 the patched sources themselves.
  11
  12 This is a manual and hard to reproduce process. By leveraging Nix,
  13 users of `nix-cl` can essentially "run their own package repository",
  14 written as Nix code, with all the benefits of that (shareability,
  15 cacheability, reproducibility, version-controllable etc.)
  16
  17
  18 ## Modifying libraries with patches
  19
  20 Other times, a bug in a library is not fixed upstream, but you fixed
  21 it yourself. Or, you would like a change to the internals that the
  22 maintainers don't like.
  23
  24 Sure, you could fork the code or maintain patches manually, but that
  25 becomes hard to manage with a lot of patches. It also doesn't have the
  26 benefits mentioned in the previous section.
  27
  28 `nix-cl` provides a way of applying version-controlled patches to any
  29 package.
  30
  31
  32 ## Using libraries not available in repositories
  33
  34 There are useful and working libraries out there, that are nonetheless
  35 unavailable to users of package managers such as Quicklisp or
  36 Ultralisp. Two real-world examples are [jzon] and [cl-tar].
  37
  38 `nix-cl` is not tied to any particular package source: instead,
  39 packages are written as a Nix expression, which can be done manually
  40 or generated/imported.
  41
  42 This frees the user to have any package they want, and not be
  43 constrained by a central repository.
  44
  45 ## Reproducible environments
  46
  47 The usual way to develop a project involves several steps, such as:
  48
  49 1. Installing a Lisp implementation
  50 2. Installing a package manager
  51 3. Installing the chosen libraries
  52
  53 This is not necessarily reproducible. It's unlikely to come back a
  54 year later and develop the project using the exact same versions of
  55 the dependencies.
  56
  57 Things can break between attempts at different points in time. The
  58 repository could have updated versions in the meantime. The source
  59 tarballs could become unreachable.
  60
  61 With `nix-cl` you can have your own binary cache for Lisp libraries
  62 and not be affected by downtime of other central repositories.
  63
  64 ## Testing across CL implementations
  65
  66 One can manually download different Lisp implementations and run tests
  67 of a package. This works well in most cases, but it is limited in how
  68 you can tweak the software. Some practical examples are:
  69
  70 - Statically compiling [zlib] into [SBCL]
  71 - Building SBCL with the `--fancy` flag
  72 - Compiling [ECL] as a static library
  73
  74 These are usually hard to do manually, unless you have the necessary
  75 compilers already configured. These combinations are usually not
  76 available from package managers as well.
  77
  78 With Nix it's easier, because it will set up the build environment
  79 automatically. It could be useful to, for example:
  80
  81 - Test against all possible compiler flag combinations
  82 - Libc versions (ECL)
  83 - JDK versions ([ABCL])
  84
  85 [zlib]: https://zlib.net
  86 [SBCL]: https://sbcl.org
  87 [ECL]: https://ecl.common-lisp.dev/
  88 [Ultralisp]: https://ultralisp.org/
  89 [jzon]: https://github.com/Zulu-Inuoe/jzon
  90 [cl-tar]: https://gitlab.common-lisp.net/cl-tar/cl-tar
  91 [bootstrap tools]: https://github.com/NixOS/nixpkgs/tree/master/pkgs/stdenv/linux/bootstrap-files
  92 [nixpkgs]: https://github.com/NixOS/nixpkgs
  93
  94 ## Windows note
  95
  96 Note that all of this still only applies to Unix systems - primarily because Nix doesn't work on Windows.
  97
  98 If you have an idea how to port some of the functionality to Windows, get in touch.