[armedbear-devel] ASDF-JAR vs ASDF3 deployment support

[Anton Vodonosov]

01.04.2013, 16:28, "Erik Huelsmann" <ehuels at gmail.com>:
> Hi all,
>
> Some years ago, Mark wrote ASDF-JAR; a solution to package ASDF systems and their dependencies in JARs.
>
> As it turns out, the solution chosen has some problems with correctly packaging ASDs for systems which use the #. reader macro. As an example: bordeaux-threads uses a version.lisp-sexp file to canonically define the version number and the system definition reads that file in a #. form. However, this file isn't packaged because it's not part of the file listing in the system definition. This means asdf can't load the definition after deployment.
>
> With the advent of ASDF3, its developers have created infrastructure to combine fasls of a single system and even fasls of a  system and all its dependencies into a single large combined FASL. Among others, this new infrastructure does not run into the issue ASDF-JAR is running into. While not completely equivalent to the JAR solution, using this infrastructure would help us a huge step along that way of getting better deployment. My current thinking is that if the single-packed-FASL needs to end up as a jar, we can work on that as a next step.
>
> The first step to take would be to create "concatenate fasls" functionality, which would do the following:
>
>  * Detect all the file entries in all the passed-in fasls
>  * Create a new output zip file with directories for each fasl being packed, populated with the files and directories of that fasl
>  * create a toplevel ._ file which loads the sub-fasls' ._ files
>
> Comments?
>
> Bye,
>
> Erik.

General note about deployment CL systems.

Often the deployment package should contain not only compiled code,
but also resources: web libraries and frameworks often contain .css, .html, .javascript;
bordeaux-threads uses version.lisp-sexp files, and so on.

In addition to the #. reader macro as used in bordeaux-threads, applications/libraries
access their resources during run-time using asdf:system-relative-pathname or
similar functions. In other words, such libraries assume presence during run-time
of their full source control checkout .

A general purpose deployment solutions should account this aspect.

Of course, if an application is free from such problems, one can use concatenated fasls,
lisp images or similar ways. 

One way to deploy applications with full content of the dependencies code and resources:
1. install quicklisp in a custom directory, 
2. (ql:quickload :my-application)
3. copy the directory of my-application, the custom quicklisp directory and probably prebuild .fals files to server.

A little bit more docs and example of this approach is here: https://github.com/avodonosov/heroku-buildpack-cl2

Best regards,
- Anton