Issues with new testing scripts

[Faré]

On Sat, Dec 19, 2015 at 5:52 PM, Robert Goldman <rpgoldman at sift.net> wrote:
> I'm having two issues with the new testing scripts:
>
> 1.  The testing code is bleeding quicklisp into context:
>
>  make test
> ./make.sh l='' L='' u='' U='' v='' s='' t='' test
>> Error: System "cl-scripting" not found
>> While executing: (:INTERNAL QUICKLISP-CLIENT::RECURSE
> QUICKLISP-CLIENT::COMPUTE-LOAD-STRATEGY), in process listener(1).
>> Type :GO to continue, :POP to abort, :R for a list of available restarts.
>> If continued: Try again
>> Type :? for other options.
> 1 >
>
> I *definitely* did not ask to be using quicklisp when testing.
>
> This error arises inside (LOAD-SYS "asdf-tools"), which is redirected to
> use quicklisp:
>
>  (defun load-sys (system)
>     (if (featurep :quicklisp)
>         (let ((*standard-output* (make-broadcast-stream))) ;; be quiet
>           (symbol-call :ql :quickload system))
>         (load-system system :verbose nil)))
>
> This is done by tools/load-asdf.lisp
>
> AFAICT, this is done UNCONDITIONALLY BY LOAD-AND-CONFIGURE-ASDF
>
> This should not be.  The user should get quicklisp only upon request: we
> added the dependencies to ext/ in order to make the ASDF distribution
> free-standing and avoid the quicklisp requirement.
>
> In my case, I use quicklisp only sometimes, and never yet with CCL, so
> having the ASDF test script go poking around for a QL installation and
> firing it up without asking me was problematic.  Particularly
> problematic was that there's no (apparent) way to STOP the ASDF scripts
> from doing this.
>
> For now I am going to push a modification that comments out
> TRY-LOAD-QUICKLISP from LOAD-AND-CONFIGURE-ASDF.
>
Yeah, asdf-tools was unconditionally loading quicklisp if found in
~/quicklisp/ or ~/.quicklisp/, with the understanding that the asdf
configuration is having ext/ take precedence over quicklisp, so
quicklisp auto-installation should only be invoked if you decided not
to make ext.

I see that you commented out the loading of quicklisp. That's a valid
stance. Either way, the behavior and requirements should probably be
better documented in the README.md.

> I have no objection to a patch that provides an *explicit option* to
> load from QL, but it must be an option, and it must not be the default.
>
> Frankly, even then I'm not excited about it.  I don't want to have
> bugreports to ASDF that are caused by issues in Quicklisp.  I'd rather
> people stick to using the dependencies in our submodules.
>
> 2.  This was just a nuisance:  three new submodules have been added, and
> "git submodule init" must be re-run when that happens.
>
> I have no idea why the git maintainers thought that a call to git
> submodule update should quietly fail to update un-initialized submodules
> (fail to update yes, QUIETLY fail to update, no).  But going forward we
> need to trumpet any changes to the submodules because of this attribute
> of git....
>
The git UI is deficient in many subtle ways.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
The urge to save humanity is almost always a false front for the urge to rule.
        — H. L. Mencken