On 10/21/11 Oct 21 -3:49 PM, Faré wrote:
On Fri, Oct 21, 2011 at 16:06, Robert Goldman rpgoldman@sift.info wrote:
Question: could we handle this problem with the new asdf contrib idea? Could we distribute an ASDF:RUN-SHELL-COMMAND based in the XCVB code base along with ASDF using a contrib system?
Probably. Or it could remain packaged separately.
I think it's a bad idea to duplicate code between XCVB and ASDF-CONTRIB. XCVB just *needs* that code in its driver and cannot import it: the XCVB driver, like ASDF, has this "everything in one file" restriction. XCVB might as well export this functionality.
Maybe I should detach xcvb-driver from the rest of xcvb, or define a package that just imports and exports select parts of XCVB-DRIVER and insulates users from change there, possibly adding value not strictly necessary in the driver. We'll see.
With Quicklisp, it shouldn't matter where exactly the code is coming from, as long as it is good quality software.
I am reluctant to see RUN-SHELL-COMMAND no longer be distributed with ASDF, since it seems to make a hash of our claims that ASDF can manage systems that mix other code with common lisp code.
ASDF cannot manage such code out of the box. It needs extensions, anyway. Deprecating R-S-C is just a way to acknowledge that it is the WRONG tool to write robust portable such extensions, and that better tools are available.
I don't agree with the claim "better tools are available" yet. ASDF is the standard for the community. Making people use a different tool is like insisting that C programmers use something other than `make`. It raises the bar too high.
I don't believe that invoking external facilities should rely on additional ASDF system dependencies. But I am sympathetic to the idea that RUN-SHELL-COMMAND is too big to fit in asdf.lisp, if done properly.
Why can't ASDF extensions rely on basic CL libraries? The very point of making ASDF itself minimal yet extensible is to bootstrap functionality in such libraries and extensions.
I don't agree because the cost of adding these libraries is too high. To do this now for a system I want to rely on I must (1) locate the new run-shell-command library (2) blow that run-shell-command library into my revision control system (3) forevermore monitor the library for modifications.
[For many applications quicklisp may help, but for keeping our commercial stuff up and running, we need absolute control, and that means keeping stuff under revision control. I believe that just about any company developing software would be in the same position.]
This is especially true since the CL community does not yet have a good solution to (3).
Currently, the implementations attempt to keep good working versions of ASDF out there. There is no corresponding crutch for arbitrary libraries (which would include our hypothetical RUN-SHELL-COMMAND).
For software that does not intend to be fully portable, for one or two calls to RUN-SHELL-COMMAND, it is far easier to do your own #+allegro, #+sbcl, #+ccl (or whatever) than it is to import and track a new library. For one thing, I am confident that if I get the small number of individual calls right, they will be truly right and will stay right.
In fact, in the original two applications that got me started finding problems with ASDF:RUN-SHELL-COMMAND, I did just that. They will probably only ever run on ACL, SBCL and maybe CCL. The conditional compilation alternatives seem far less rickety than trying to get RUN-SHELL-COMMAND to work properly, or to grok another portability library.
Of course, an end application case, such as I have in mind is a different use case from a core library such as, e.g., CFFI, where you want full portability, and the advantages of trusting someone else to get the shell commands right on all platforms pay off better.
Maybe I'm starting to agree with you --- ASDF:RUN-SHELL-COMMAND will never be good enough, and programmers are just better off avoiding it. Better not to have anything than to have something that does The Wrong Thing.
Cheers, r