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

[Mark Evenson]

On 4/4/13 12:44 AM, Anton Vodonosov wrote:
[…]
> 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.
>
> 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

In my opinion of "the right way", system definitions should contain a
comprehensive listing of all the resources in the DEFSYSTEM form.
Anything referenced by ASDF:SYSTEM-RELATIVE-PATHNAME or as a target of a
CL:SHARPSIGN-DOT reader macro should be declared as a STATIC-FILE ASDF
component.  If this were somehow universally the case, then we could
reliably use the machinery of ASDF3 to transverse its components, and
determine both the "source" and the "compiled" components.

But because "universal distribution" (i.e. for the majority of users of
a given system) has more-or-less subsumed by Quicklisp, there is no real
constraint on the developers of system definitions to ensure that all
components are so enumerated:  loading the system from Quicklisp works
so nothing is broken, right?

After Xach, Anton probably has the most practical experience with
packaging ASDF definitions for deployment due to his pioneering work on
CL-TEST-GRID.  I find Anton comments to be a succinct summary of the
issues involved in packaging a given ASDF system in Quicklisp.  But when
facing deployment for an ASDF system that is not in Quicklisp, but has
dependencies on Quicklisp systems, Anton's approach won't work so well.
 One would have to find the .asd definition on the filesystem, then
transverse its sub-directories to find the source files.  This has the
problem that there is no guarantee that the components of an asd
definition exist in subdirectories, as theoretically the PATHNAME could
point to an ancestor.  And even if one discarded this possiblity, often
directory hierarchies share multiple ASDF definitions, so one would
package "source" components that aren't really source components.

So, assuming that "deployment outside of Quicklisp from an ASDF
definition" would be a greater good for the community, we seem to be
stuck at a bootstrap problem.  I can't think of a way to force ASDF
authors to enumerate their static components, but until such enumeration
is widespread, I can't demonstrate its utility by developing an
ASDF/BUNDLE operation.

Any ideas?


-- 

"A screaming comes across the sky.  It has happened before, but there is
nothing to compare it to now."