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 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.
A second question: can we provide something like autoload for RUN-SHELL-COMMAND, based on ASDF:LOAD-SYSTEM, to minimize dislocation?
That's actually quite a neat idea! Whenever I gut out R-S-C (not until known users have been fixed), I'll leave this instead:
(defun run-shell-command (fmt &rest args) "This function is badly designed and deprecated. This thin wrapper provides a compatibility layer for legacy code. Please do not use in your code; instead, directly use xcvb-driver or some other well-designed, robustly implemented, ported and supported interface" (asdf:load-system :xcvb-driver) (funcall (find-symbol (string :run-program/for-side-effects) :xcvb-driver) (apply 'format nil fmt args)))
And maybe a define-compiler-macro to emit a style-warning at compile-time?
If we have something like autoload, then people won't have to rejigger their system structures if we deprecate R-S-C away. Indeed, if we give them a better version, then they would just be a step ahead.
That's a great suggestion.
Finally, if we provide a better R-S-C, how do users differentiate? #+asdf2 is simply too coarse a tool now. #+asdf-run-shell-command ?
One more reason to direct users to a better interface. Using format will never provide a robust interface to escaping characters for the shell, much less portably between Windows and Unix. Leaky abstractions SUCK. R-S-C has wet its pants and made a puddle already.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org