wanted: asdf:who-depends-on

[Tobias C. Rittweiler]

I'd like to have said function which returns all the currently loaded system which depend
on a given system. (The function should possibly take some &key parameter so you
can ask either for direct or deep dependencies.)

[Tobias C. Rittweiler (tcr)]

In Slime's ASDF contrib, we currently use the following

(defun who-depends-on (system)
  (flet ((system-dependencies (op system)
           (mapcar #'(lambda (dep)
                       (asdf::coerce-name (if (consp dep) (second dep) dep)))
                   (cdr (assoc op (asdf:component-depends-on op system))))))
    (let ((system-name (asdf::coerce-name system))
          (result))
      (map-defined-systems
       #'(lambda (system)
           (when (member system-name
                         (system-dependencies 'asdf:load-op system)
                         :test #'string=)
             (push (asdf:component-name system) result))))
      result)))

[Faré (fahree)]

If you're willing to merge in the changes, I can help with improving the ASDF support.

However, one question remains to me: how old ASDF versions do you want to support?

Many things can be simplified by assuming ASDF 2.000 or newer, and even more things can be simplified if we can assume a relatively recent ASDF (quicklisp has 2.014.6, SBCL from 2011-08-22 or CCL from 2011-07-28 has 2.017, etc).

On the one hand, we should never assume that SLIME runs on super-recent software: debugging, by definition, may happen on software written long ago.

On the other hand, the very idea behind ASDF2 is that you can always upgrade an existing image to use the latest ASDF, even on top of an existing old ASDF.

On the first hand, when you upgrade ASDF, it invalidates previous defsystems in memory, because of potential incompatibilities.

On the second hand, after the defsystems have been invalidated, they can always be reloaded from disk.

On the first hand, you might not always have the exact source used to compile the image version you're debugging.

On the second hand, if you don't have the matching source, then you're not going to have much use for the original system definitions, anyway.

So there. I believe my conclusion is that we should NOT be worrying about ASDF versions that are too old, and that older than 2.000 is probably too old, considering that all maintained implementations have adopted ASDF 2 some time between 2010 and 2011. Hopefully, we can declare anything older than 2.011 obsolete (valid as per 2010-11-28). Actually, I'd really like to declare things before 2.015 obsolete, but that isn't realistic yet, considering that quicklisp still sports 2.014.6 (yikes).

[Faré (fahree)]

Final comment.

We at Google always check in a version of SLIME in our source control;
we build our code with precompiled support for swank,
and we debug with the matching version of SLIME.

This is the only reasonable way to be sure you can debug old versions of your servers: keep around a copy of as much of the toolchain as you need.

With this in mind, it really isn't necessary to support overly old versions of anything.

[Faré (fahree)]

DAMMIT. I WAS COMMENTING ON WRONG BUG!

The above two comments were meant for somewhat related SLIME bug 1077378
https://bugs.launchpad.net/slime/+bug/1077378

Regarding the bug at hand, note that because there are
1- things you load directly from a .asd
2- defsystem-depends-on
as well as depends-on,
your code above only gives part of the dependencies.

The only reliable way to detect dependencies is to do it the hard way like quicklisp: build each system from an empty image and see what was pulled when you're done. If your code is in quicklisp and its dependencies haven't changed, that's the best way to figure out dependencies. Otherwise, well, it sucks.

[Faré (fahree)]

This bug will be much easier to solve if we merge POIU into ASDF, or at least its correct explicit model of the action graph.