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:
- install quicklisp in a custom directory,
- (ql:quickload :my-application)
- 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?