> On Apr 2, 2018, at 18:23, Robert Goldman <rpgold...@sift.info> wrote:
> On 1 Apr 2018, at 7:57, Mark Evenson wrote:
> On Apr 1, 2018, at 14:20, Attila Lendvai att...@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


(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")))


(in-package :cl-user)
(prove:plan 1)
(prove:pass "A test that always passes")


(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

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 

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

Reply via email to