[Ecls-list] Further integration between quicklisp and ECL

[Anton Vodonosov]

To me ecl-quicklisp sounds like some kind of customized or branched quicklisp.

The package provides two function: automatic installation of quicklisp 
and hooking quicklisp into REQUIRE. Juan Jose, other functions you mention
are outside of quicklisp this package - monolitic fasls for libraries is more about asdf,
and switching between bytecode and lisp-to-c compiler is just ECL function; aren't they?

If so, the package is not a customization of quicklisp, but more like
services on top of quicklisp. Maybe quicklisp-integration whould be more precise name
for the package?

Zach, I share the concern about instructions divergence, but note that the official
quicklisp instructions are for manual execution, but here we have a separate
use case - programmatic installation of quicklisp. 

Quicklisp instructions are very simple, especially for developers who understands what
is starting REPL and execution of lisp forms. But in the case when we deliver a program
to end user, the program itself has some instructions and adding separate step
for installing quicklisp is a complication for the user. Automatic quicklisp installation
is also useful when we deploy a program to a server. Concrete examples are: 
Juan Jose wants to ask end user to perform some tests on ECL and wants to save
user from executing manual steps (as he described in one of previous ecls-list posts);
I automatically bootstrap quicklisp in cl-test-grid-agent; Mike Travers in his
heroku build pack (https://groups.google.com/d/topic/comp.lang.lisp/TKM3eFyObLw/discussion)
also uses automatic quicklisp installation.

So, to avoid instructions divergence for the automatic installation, 
it's probably good to have a ready to use recommenced solution?

The recommendation may be for example to commit quicklisp.lisp
file into the application sources, and then use

  (load (merge-pathnames "relative/path/to/quicklisp.lisp"
                         (or *load-truename* #.*compile-file-pathname*))

  (handler-bind ((error #'(lambda (err)
                            (declare (ignore err))
                            (when (find-restart 'quicklisp-quickstart::load-setup)
                              (invoke-restart 'quicklisp-quickstart::load-setup)))))
    (quicklisp-quickstart:install :path install-dir)))

Something like that. The implementation is portable, not specific to ECL.

In the use-cases described above it would also be useful to have
possibility to install some constant version of quicklisp distro, 
where the program was tested and known to work.

As for REQUIRE, I personally don't see a problem of having REQIRE integrated
with quicklisp, asdf or anything else. It is non-portable of course. I wish
there standard declare some *REQUIRE-HOOKS* variable - a list
of functions, each given a chance to load the module when user invokes
(REQUIRE "module"). Then user could plug-in any library loader into REQUIRE 
in a portable way.

BTW, Juan Jose what do you think of exposing such a functionality
from ECL instead of providing hardcoded integration only for quicklisp?

Best regards,
- Anton