[asdf-devel] run-shell-command

[Robert Goldman]

On 10/21/11 Oct 21 -3:49 PM, Faré wrote:
> On Fri, Oct 21, 2011 at 16:06, Robert Goldman <rpgoldman at 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