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 <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
--—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
