2012-08-15

Library problems and a partial fix

If you upgraded to the latest Quicklisp dist and tried to load certain libraries, you might find yourself staring at an infinite loop of "Loading asdf..."

This was caused by how Quicklisp handles missing libraries. The general process is something like this:

  1. Try to load library "foo"
  2. Handle a asdf:missing-dependency error specifying library "bar"
  3. Load library "bar"
  4. Go back to step 1
The problem in this case was that the missing library in question was ASDF, but it wasn't a plain old missing dependency; certain libraries now depend on a specific (and very recent) version of ASDF. The condition was in fact of type asdf:missing-dependency-of-version (a subtype of asdf:missing-dependency), and Quicklisp didn't handle it specially. So it would get the error, load ASDF, try again, get the error, load ASDF, try again...forever.

I've just updated the Quicklisp client code to deal with this specific situation properly, and more generally avoid trying to load the same library multiple times. It fixes the problem of the infinite looping (now you get a clear error related to a version dependency problem), and you can get the updated version by calling (ql:update-client) and restarting your session.

Problems remain, though. The required version of ASDF is extremely new, only a month old. It is not available through Quicklisp, and even if your implementation has bundled it, you must make sure to update to the most recent version of your implementation to get it.

Why isn't it available through Quicklisp? ASDF is not a normal library. I can't point Quicklisp at a tarball or git repo and just keep it up to date like other libraries. It's a fundamental part of what Quicklisp does, and I would rather provide (as a last resort) an old, apparently-stable version and let implementations provide newer versions if they are needed for critical bug fixes. I do not want to see projects depend on ASDF as an evolving bucket of utility functions. In fact, I'd like to see ASDF go away, replaced by something better, and anything that makes libraries and applications depend on ASDF more rather than less is, to me, a bad thing. (This includes like asdf:system-relative-pathname in your Lisp source code. There are plenty of ways to avoid it.)

Unfortunately, some libraries do use ASDF as a utility library, and they require a very recent version of ASDF. For some people, code that worked in July will stop working until they jump through some unpleasant hoops. I hate to see that. Quicklisp is about eliminating those hoops.

I'll try to figure out the best way forward. I hope it will involve changes to how ASDF is used by some libraries, but it might also involve changes to how Quicklisp provides ASDF updates. I'll keep you posted.

4 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. > Unfortunately, some libraries do use ASDF as
    > a utility library, and they require a
    > very recent version of ASDF.

    Probably these libraries should use asdf-utils instead, as this asdf-devel post advices: http://lists.common-lisp.net/pipermail/asdf-devel/2012-August/002571.html

    Although currently asdf-utils is implemented just as a package which reexports symbols from asdf, so to access the new utils it needs new asdf. But I guess it may (planned to?) be replaced by real implementation, so that asdf-utils will be true utility library, as any other library in quicklisp.

    P.S. as a user I would prefer to always use a single, the latest, ASDF version instead of different ASDFs in different CL implementations.

    ReplyDelete
    Replies
    1. Unfortunately, doing it halfway (making asdf-utils just re-export stuff from asdf) doesn't really help. Things will only be workable when ASDF is out of the loop.

      Delete
  3. Yes, reexport doesnt' help. Actually, in the current situation asdf-utils is affected by this asdf:missing-dependency-of-version problem.

    ReplyDelete