Implementation Specific Images
These images contain a single Common Lisp implementation. They should all follow best practices for Docker and be designed so that if upstream wanted, the image could be submitted to Docker's Official Image Program (aka the Docker standard library).
We currently publish images for the following implementations:
- ABCL: Source at https://gitlab.common-lisp.net/cl-docker-images/abcl. This has been submitted to Docker's Official Images program.
- CCL: Source at https://gitlab.common-lisp.net/cl-docker-images/ccl
- ECL: Source at https://gitlab.common-lisp.net/cl-docker-images/ecl
- SBCL: Source at https://gitlab.common-lisp.net/cl-docker-images/sbcl
If you would like to request or offer to support a new implementation specific image, please reach out.
For every supported version of an implementation, the default tag should be a
"fat" image that contains libraries equivalent to those found
in buildpack-deps, the CL
implementation itself, the source code for the implementation, a specialized
entrypoint, and the Quicklisp installer. The entrypoint should invoke the the
implemtation if no command is specified or the first element of the command
list is an option (starts with a
Only the Quicklisp installer is included as an installed Quicklisp is not particularly amenable to Dockerization for two reasons. First there is no real system-wide install option, the user has to have write bits to the entire Quicklisp hierarchy. Second, installing fetches the package lists, pinning them to the point in time the image was made.
In addition to the fat images, there should be a set of tags for a "slim" variant that includes only the implementation, the dependencies needed to start the implementation, and the same specialized entrypoint as above.
For implementations that support it, there should also be a set of
windowsservercore based tags and Alpine based tags (useful for space
constraints or creating static executables).
We try to bump versions within a week of a new version of the implementation being released. In addition to building images for released versions, we attempt to build nightly images directly from the implementation's source control. However, these nightly images should be considered "best effort" and may get scaled back or stopped altogether at some point in the future.