Problems with DEFSYSTEM-DEPENDS-ON

Sat Apr 7 20:08:17 UTC 2018

OK, I think I understand now.  This happens when we need quicklisp not 
just to load, but to install and load, defsystem depends on systems.

I just looked at Robert Dodier's bug fix, 
https://github.com/quicklisp/quicklisp-client/pull/128/ and I'm a little 
concerned that it could raise an error if `asdf::missing-requires` isn't 
implemented on the error condition that is signaled by ASDF (and I don't 
see why it would be guaranteed to be implemented there).  Shouldn't this 
check the type of `(asdf::error-condition c)`? Or if there's something 
about the conditions under which this handler is invoked that guarantees 
that the call to `missing-requires` will not error out, I don't see it, 
so it's probably worthy of a comment.

My guess is that if you checked for the `error-condition` being a 
subtype of `missing-component` that would work in modern ASDF.  I have 
no idea whether it would work in ASDF 2 and I'm afraid that I don't have 
the time for the ASDF archaeology required to figure out how to 
"past-proof" this code.

HtH,
Best,
r

On 6 Apr 2018, at 4:20, Mark Evenson wrote:

>> On Apr 2, 2018, at 18:23, Robert Goldman <rpgoldman at sift.info> wrote:
>>
>> On 1 Apr 2018, at 7:57, Mark Evenson wrote:
>>
>> On Apr 1, 2018, at 14:20, Attila Lendvai attila at lendvai.name wrote:
>>
>> The usage of DEFSYSTEM-DEPENDS-ON to specify dependencies that will 
>> be
>> satisfied by QL:QUICKLOAD no longer seems to be working in 
>> asdf-3.3.1.
>>
>> FTR, here's the history of this issue:
>>
>> https://github.com/quicklisp/quicklisp-client/pull/122#issuecomment-160419822
>>
>> https://github.com/quicklisp/quicklisp-client/issues/108
>>
>> Wow! Holy stale complications, batman!
>>
>> Robert apparently suggested something (apparently) much simpler in
>>
>> https://github.com/quicklisp/quicklisp-client/pull/128
>>
>> but without any commentary from Zach on that approach.
>>
>> Given asdf-3.3 is out, and recent sbcl’s ship with it, which is the 
>> preferred way forward from ASDF’s perspective?
>>
>> "From ASDF's perspective," this is all new to me, since it was filed 
>> as a bug against Quicklisp, and as far as I know, never raised as an 
>> issue for ASDF. I could use some help here:
>>
>> 	• What's a minimal error case using quickload alone?
>> 	• What's a minimal case that arises with using ASDF as the entry 
>> point?
>> It seemed like there was one where if Quicklisp is up and running, 
>> and you use asdf:load-system to load a system, this can also happen.
>> Something I can type into a REPL verbatim is what I would like to 
>> see.
>
> Not sure how to distinguish between your two requests for quickload 
> alone versus ASDF as an entry point
>
> A minimal case would be the following ASDF definition
>
> --—depends.asd---
>
> (defsystem depends
>   :in-order-to ((test-op (test-op "depends/t"))))
>
> (defsystem depends/t
>   :defsystem-depends-on (prove-asdf)
>   :depends-on (prove)
>   :components ((:test-file "depends-test.lisp")))
>
> ——depends-test.lisp——
>
> (in-package :cl-user)
> (prove:plan 1)
> (prove:pass "A test that always passes")
> (prove:finalize)
>
> ----------------------
>
> (ql:quickload :depends) should pick up the depends/t secondary system 
> to install PROVE from the network, which is needed to provide a CLOS 
> for the TEST-FILE component.
>
> Component "prove-asdf" not found, required by NIL
>  0: (CONDITIONS::CONDITIONS-ERROR :INVISIBLEP T 
> ASDF/FIND-COMPONENT:MISSING-DEPENDENCY (:REQUIRED-BY NIL :REQUIRES 
> "prove-asdf"))
>   1: (ERROR ASDF/FIND-COMPONENT:MISSING-DEPENDENCY :REQUIRED-BY NIL 
> :REQUIRES "prove-asdf")
>   2: (ASDF/FIND-COMPONENT:RESOLVE-DEPENDENCY-NAME NIL "prove-asdf" 
> NIL)
>   3: ((SUBFUNCTION 1 ASDF/PARSE-DEFSYSTEM:REGISTER-SYSTEM-DEFINITION))
> …
>
> For ASDF3 alone, as long as PROVE is installed, there is no problem.
>

>
>> Also, sounds like though this is an issue on all lisps, not just ABCL 
>> as the first post suggested
>
> Yes, this issue effects all Common Lisp implementations.   I don’t 
> think I even mentioned ABCL in my first message, so other than being 
> an ABCL maintainer, I don’t see how you got that impression.
>
>
>> Communications between ASDF and QL have been difficult since Zach 
>> dropped off this list (and, to be fair, I have never joined up to 
>> read quicklisp-devel, if there is such a thing).
>
> Yes, we are certainly dealing with the resistance of Quicklisp to 
> deprecate ASDF2 in favor of ASDF3, for which I neither really know nor 
> want to go into the history thereof.  Rather than pointing fingers, 
> and spreading blame, I am trying to find some compromise that works 
> for both the ASDF and Quicklisp maintainers, as without getting 
> ql:quickload to somehow include :defsystem-depends-on declarations as 
> recognized load dependencies in the currently stable ASDF3, it means 
> this useful feature for ASDF extensiblity is effectively unusable for 
> inter-system cooperation within Quicklisp.
>
> In the January 2018 Quicklisp systems, there are 103 references to 
> prove-asdf, so this issue effects quite a bit of the current Quicklisp 
> distributed ecosystem for that use case alone.
>
> As I read the Quicklisp issues and pull-requests, Quicklisp would be 
> willing to accept a “minimally invasive” patch if it would support 
> asdf-2.26 as well as ASDF3.
>
>
> So, to put things more succintly, given the choice between Quicklisp 
> pulls [122][] or [128][], and given that we have advanced to 
> asdf-3.3.1 since these requests were issued, what would be the 
> preferred manner to patch Quicklisp that would be the most 
> forward-looking for future ASDF3 compatibility so that Quicklisp might 
> continue to work with :DEFSYSTEM-DEPENDS-ON clauses like it used to?
>
> [122]: https://github.com/quicklisp/quicklisp-client/pull/122
> [128]: https://github.com/quicklisp/quicklisp-client/pull/128
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20180407/214eb6c3/attachment.html>