[asdf-devel] Detecting non-defsystem dependencies
Some system files look like this: ;;;; myproject.asd (asdf:load-system "some-prerequisite") (defsystem "myproject" ...) Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward? Zach
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
Zach
I suppose one could do something scary like loading the system definition through a process that would cause invocation of ASDF operations to be trapped and logged instead of executed. This would be a sort of sandbox, and results of loading the .asd file into the sandbox could be used to infer the presence of such loading events. This still seems pretty nasty compared to fixing the system definition files. Best, r
"Robert P. Goldman" <rpgoldman@sift.info> writes:
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
Zach
I suppose one could do something scary like loading the system definition through a process that would cause invocation of ASDF operations to be trapped and logged instead of executed. This would be a sort of sandbox, and results of loading the .asd file into the sandbox could be used to infer the presence of such loading events.
I don't need a sandboxing effect, either, I'm happy to fully load things and inspect the state of the world afterwards.
This still seems pretty nasty compared to fixing the system definition files.
I don't mind getting scary and nasty so other people don't have to. Zach
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
Zach
I don't believe that this can actually be computable. There's no way to ask ASDF what would happen when it loads an asd file, nor really could there be. One could attempt to infer this by looking around for system-loading forms, but that would be prone to both false positives and false negatives. If these calls to LOAD-SYSTEM are reducible to DEFSYSTEM-DEPENDS-ON, it might be better to modify the system definition to eliminate the calls to LOAD-SYSTEM, instead of working hard to infer them. In my experience, many of these hang around because system definers don't understand that they can/must use keywords in their system definition to name symbols that have not yet been defined...
Robert Goldman <rpgoldman@sift.net> writes:
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
Zach
I don't believe that this can actually be computable. There's no way to ask ASDF what would happen when it loads an asd file, nor really could there be.
I don't care about knowing in advance; I mean more instrumenting the ASDF process somehow to detect what *has* happened after the fact. I've already done this in a hacky way by adding methods to internal functions and (ab)using *macroexpand-hook*. I'm looking for nicer, possibly even supported/encouraged ways. Zach
On Wed, Nov 6, 2013 at 2:48 PM, Zach Beane <xach@xach.com> wrote:
Robert Goldman <rpgoldman@sift.net> writes:
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
I don't believe that this can actually be computable. There's no way to ask ASDF what would happen when it loads an asd file, nor really could there be.
I don't care about knowing in advance; I mean more instrumenting the ASDF process somehow to detect what *has* happened after the fact. I've already done this in a hacky way by adding methods to internal functions and (ab)using *macroexpand-hook*. I'm looking for nicer, possibly even supported/encouraged ways.
You could open a bug against ASDF if you feel there should be support for it builtin. A "userspace" implementation of that can currently be done by having a hook :before asdf:operate, that pushes the current operation to a list associated to the (uiop:load-pathname) when said file is a .asd. PS: it looks like GCL 2.6 is mostly dead, and GCL 2.7 will support *load-pathname* correctly, and soon ASDF 3 — so maybe we can use *load-pathname* instead of (uiop:load-pathname). —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Your "solution" to avoid a few free riders in one industry is making everyone a free rider of a nationwide joint monopoly on all industries?
Faré <fahree@gmail.com> writes:
On Wed, Nov 6, 2013 at 2:48 PM, Zach Beane <xach@xach.com> wrote:
Robert Goldman <rpgoldman@sift.net> writes:
Zach Beane wrote:
Some system files look like this:
;;;; myproject.asd
(asdf:load-system "some-prerequisite")
(defsystem "myproject" ...)
Can you recommend a good way to detect that system "myproject" depends on system "some-prerequisite"? Are there any hooks or other features of ASDF that might make it straightforward?
I don't believe that this can actually be computable. There's no way to ask ASDF what would happen when it loads an asd file, nor really could there be.
I don't care about knowing in advance; I mean more instrumenting the ASDF process somehow to detect what *has* happened after the fact. I've already done this in a hacky way by adding methods to internal functions and (ab)using *macroexpand-hook*. I'm looking for nicer, possibly even supported/encouraged ways.
You could open a bug against ASDF if you feel there should be support for it builtin.
A "userspace" implementation of that can currently be done by having a hook :before asdf:operate, that pushes the current operation to a list associated to the (uiop:load-pathname) when said file is a .asd.
Hmm. If I have a setup like this: ;;;; a.asd (asdf:load-system "b") (asdf:defsystem "a" ...) And: ;;;; b.asd (asdf:defsystem "b" :depends-on ("c") ...) What will be the load pathname associated with the load operation of "c" when loading "a"? Zach
On Thu, Nov 7, 2013 at 9:05 AM, Zach Beane <xach@xach.com> wrote:
A "userspace" implementation of that can currently be done by having a hook :before asdf:operate, that pushes the current operation to a list associated to the (uiop:load-pathname) when said file is a .asd.
Hmm. If I have a setup like this:
;;;; a.asd
(asdf:load-system "b")
(asdf:defsystem "a" ...)
And:
;;;; b.asd
(asdf:defsystem "b" :depends-on ("c") ...)
What will be the load pathname associated with the load operation of "c" when loading "a"?
There will be no direct loading of c via (operate 'load-op "c"); rather, loading c will be part of the plan performed during the (operate 'load-op "b") evaluated in a.asd. So if you hook :before operate, you still need to look at the regular dependencies of the systems that you detect were loaded. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Our love was a supernova, bursting with an immense light only to wane quickly, leaving behind a black hole.
Faré <fahree@gmail.com> writes:
On Thu, Nov 7, 2013 at 9:05 AM, Zach Beane <xach@xach.com> wrote:
A "userspace" implementation of that can currently be done by having a hook :before asdf:operate, that pushes the current operation to a list associated to the (uiop:load-pathname) when said file is a .asd.
Hmm. If I have a setup like this:
;;;; a.asd
(asdf:load-system "b")
(asdf:defsystem "a" ...)
And:
;;;; b.asd
(asdf:defsystem "b" :depends-on ("c") ...)
What will be the load pathname associated with the load operation of "c" when loading "a"?
There will be no direct loading of c via (operate 'load-op "c"); rather, loading c will be part of the plan performed during the (operate 'load-op "b") evaluated in a.asd. So if you hook :before operate, you still need to look at the regular dependencies of the systems that you detect were loaded.
Thanks. I started to implement this idea, but I'm concerned because ASDF already defines an unspecialized :before method on OPERATE. Is it safe to clobber it? If not, what should I do instead? Zach
On Thu, Nov 7, 2013 at 9:35 AM, Zach Beane <xach@xach.com> wrote:
Thanks. I started to implement this idea, but I'm concerned because ASDF already defines an unspecialized :before method on OPERATE. Is it safe to clobber it? If not, what should I do instead?
Well, I would use a :before method with slightly different specializers than (operation component), e.g. (operation system), since you're only interested in systems. (beware: poiu does that, too, on (operation t)) —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org We have actually contrived to invent a new kind of hypocrite. The old hypocrite, Tartuffe or Pecksniff, was a man whose aims were really worldly and practical, while he pretended that they were religious. The new hypocrite is one whose aims are really religious, while he pretends that they are worldly and practical. — G. K. Chesterton
Faré wrote:
On Thu, Nov 7, 2013 at 9:35 AM, Zach Beane <xach@xach.com> wrote:
Thanks. I started to implement this idea, but I'm concerned because ASDF already defines an unspecialized :before method on OPERATE. Is it safe to clobber it? If not, what should I do instead?
Well, I would use a :before method with slightly different specializers than (operation component), e.g. (operation system), since you're only interested in systems. (beware: poiu does that, too, on (operation t))
Didn't we once upon a time have method specialization internal to ASDF done by an alternate set of method combination keywords to avoid clashes with extensions like Xach's? I have a vague memory of this, but an even vaguer one that you had ripped this out because of inconsistencies in different implementations' handling of the extended form of method combination.... Cheers, r
On Thu, Nov 7, 2013 at 12:32 PM, Robert Goldman <rpgoldman@sift.net> wrote:
Faré wrote:
On Thu, Nov 7, 2013 at 9:35 AM, Zach Beane <xach@xach.com> wrote:
Thanks. I started to implement this idea, but I'm concerned because ASDF already defines an unspecialized :before method on OPERATE. Is it safe to clobber it? If not, what should I do instead?
Well, I would use a :before method with slightly different specializers than (operation component), e.g. (operation system), since you're only interested in systems. (beware: poiu does that, too, on (operation t))
Didn't we once upon a time have method specialization internal to ASDF done by an alternate set of method combination keywords to avoid clashes with extensions like Xach's?
I have a vague memory of this, but an even vaguer one that you had ripped this out because of inconsistencies in different implementations' handling of the extended form of method combination....
Yes, I removed it before 2.000, because it was causing non-portability on many platforms (including earlier versions of CLISP and ABCL), and because frankly it didn't bring much that couldn't be done better by splitting a gf in two (e.g. perform-with-restarts). I don't believe in this "clash" theory too much, or in the theory that the convoluted method combination helped. You still have just as much and as little clash when defining new methods, and still need to be somewhat careful not to step on anyone else's toes. It's one more of these fancy experiments that the original ASDF authors did, that doesn't amount to much in the end. Of course, if they hadn't experimented, they wouldn't have discovered the *good* things about ASDF. In retrospect, my job with ASDF2 & ASDF3 will have been to distill the good stuff, complete and fix it, and throw away or deprecate the bad stuff. —♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org To converse at the distance of the Indes by means of sympathetic contrivances may be as natural to future times as to us is a literary correspondence. — Joseph Glanvill, 1661
participants (4)
-
Faré -
Robert Goldman -
Robert P. Goldman -
Zach Beane