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 ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
