<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 4, 2013 at 10:50 AM, Mark Evenson <span dir="ltr"><<a href="mailto:evenson@panix.com" target="_blank">evenson@panix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 4/4/13 12:44 AM, Anton Vodonosov wrote:<br>
[…]<br>
<div class="im">> General note about deployment CL systems.<br>
><br>
> Often the deployment package should contain not only compiled code,<br>
> but also resources: web libraries and frameworks often contain .css,<br>
> .html, .javascript; bordeaux-threads uses version.lisp-sexp files,<br>
> and so on.<br>
><br>
> In addition to the #. reader macro as used in bordeaux-threads,<br>
> applications/libraries access their resources during run-time using<br>
> asdf:system-relative-pathname or similar functions. In other words,<br>
> such libraries assume presence during run-time of their full source<br>
> control checkout .<br></div></blockquote><div><br></div><div style>Well, systems should declare the resources they want packaged into their applications in their system files. That's a requirement both ECL and ABCL now put forward, but I think other implementations which are able to deliver more or less stand alone programs would want the same.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
><br>
> A general purpose deployment solutions should account this aspect.<br>
><br>
</div><div class="im">> One way to deploy applications with full content of the dependencies<br>
> code and resources:<br>
>  1. install quicklisp in a custom directory,<br>
>  2.  (ql:quickload :my-application)<br>
>  3. copy the directory of my-application, the custom quicklisp<br>
>     directory and probably prebuild .fals files to server.<br>
><br>
> A little bit more docs and example of this approach is here:<br>
> <a href="https://github.com/avodonosov/heroku-buildpack-cl2" target="_blank">https://github.com/avodonosov/heroku-buildpack-cl2</a><br>
<br>
</div> [ ... ]<br>
<br>
But because "universal distribution" (i.e. for the majority of users of<br>
a given system) has more-or-less subsumed by Quicklisp, there is no real<br>
constraint on the developers of system definitions to ensure that all<br>
components are so enumerated:  loading the system from Quicklisp works<br>
so nothing is broken, right?<br></blockquote><div><br></div><div style>Surely we can add tests for that in cl-test-grid as well?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

After Xach, Anton probably has the most practical experience with<br>
packaging ASDF definitions for deployment due to his pioneering work on<br>
CL-TEST-GRID.  I find Anton comments to be a succinct summary of the<br>
issues involved in packaging a given ASDF system in Quicklisp.  But when<br>
facing deployment for an ASDF system that is not in Quicklisp, but has<br>
dependencies on Quicklisp systems, Anton's approach won't work so well.<br>
 One would have to find the .asd definition on the filesystem, then<br>
transverse its sub-directories to find the source files.</blockquote><div><br></div><div style>The above is no longer true: with MONOLITHIC-FASL-OP you can build a fasl which holds a system and all its depedencies, including QL provided dependencies. This means you only need a working quicklisp setup on the development machine.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  This has the<br>
problem that there is no guarantee that the components of an asd<br>
definition exist in subdirectories, as theoretically the PATHNAME could<br>
point to an ancestor.</blockquote><div><br></div><div style>True, but with the above, they don't need to anymore: they'll be included in the monolithic fasl. Even better: the monolithic fasl really doesn't require ASDF at all: you can simply load the FASL with a normal LOAD call and it will load all the embedded FASLs in the right (ASDF derived) order.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  And even if one discarded this possiblity, often<br>
directory hierarchies share multiple ASDF definitions, so one would<br>
package "source" components that aren't really source components.<br></blockquote><div><br></div><div style>I'm sorry, I don't understand this bit. Could you try to explain your concern with different words? </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, assuming that "deployment outside of Quicklisp from an ASDF<br>
definition" would be a greater good for the community, we seem to be<br>
stuck at a bootstrap problem.  I can't think of a way to force ASDF<br>
authors to enumerate their static components, but until such enumeration<br>
is widespread, I can't demonstrate its utility by developing an<br>
ASDF/BUNDLE operation.<br></blockquote><div><br></div><div style>Well, there is no need to develop the ASDF/BUNDLE operation: Fare did. Buth other than that, the fact that I can now succesfully package bordeaux-threads which we couldn't with ASDF-JAR, I think this is really a step ahead? </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any ideas?<br></blockquote><div><br></div><div style>[I actually started writing this mail bottom to top, so what's below may be a reiteration...]</div><div><br></div><div style>Well, the great thing about the solution that Fare has now rolled out is that I was able to package and load Bordeax-threads even though it is problematic because it uses the #. reader macro and does not include the version.lisp-sexp in the ASDF definition...</div>
<div style><br></div><div style>The infrastructure I've added to ABCL has been hooked up into ASDF with his new release. Much more doesn't seem to be required to get it all correctly packaged. Package providers can simply use #. reader macros to inject the list of :static-files they need to be distributed with their code and asdf will pick it up.  We'll need to work and test ASDF + ABCL to see if everything works as intened though.<br>
</div><div style><br></div><div style><br></div><div style>Bye,</div><div style><br></div><div style><br></div><div style>Erik.</div></div></div></div>