On Sat, Dec 19, 2015 at 5:52 PM, Robert Goldman <rpgold...@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
