Another System Definition Facility

ASDF should be able to upgrade itself

Reported by Faré on 2009-11-20
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ASDF
Medium
Faré

Bug Description

A big problem with ASDF is that you can't easily upgrade an ASDF present in a Lisp image, much less with ASDF itself.

Consequently, ASDF must be loaded specially, and sometimes unloaded specially first, if you want to use a specific version rather than whatever your Lisp distribution provides or fails to provide.

Hurdles to ASDF loading itself:
a- There isn't an asdf.asd
b- There isn't a supported protocol for forcing a new search for an existing system in the registry.
c- Some defun's have been changed to defmethod's which cause errors on load
d- classes have been changed without methods on update-instance-for-redefined-class so that dependency on a previously loaded systems breaks the build.

Proposed solutions:
a- create one such asdf.asd
b- implement such a protocol.
c- fmakunbound those symbols at the beginning of the file
d- provide such a method

Note that c and d require a little bit of software archeology to identify all that has changed in ASDF. Sigh.

Faré (fahree) wrote :

See my rant http://fare.livejournal.com/149264.html

But also, so that you may seamlessly upgrade ASDF and install stuff, there ought to be some standard location for configuration files:

~/.config/common-lisp/asdf.conf
/etc/common-lisp/asdf.conf

For simplicity, the configuration file can be a sexp, or even a Lisp file you load - though restricting the language is always a good idea when you can get away with it.

Or something. But anyway, there should be a well-defined way to configure things such that responsibilities are well-established as to who configures what how, and who doesn't have to. Implementers shouldn't have to worry how things are distributed, or distributors how they are implemented.

Robert P. Goldman (rpgoldman) wrote :

I by and large agree about configuration, but I think it should be moved to a separate launchpad record. Would that be OK?

Tobias C. Rittweiler (tcr) wrote :

Since 1.372, ASDF has some hot-upgrading support.

Changed in asdf:
status: New → In Progress
assignee: nobody → Faré (fahree)
Faré (fahree) on 2010-02-03
Changed in asdf:
status: In Progress → Fix Committed
Faré (fahree) wrote :

I believe the fixes committed in 1.596 in my repo provide a satisfactory solution.

http://common-lisp.net/gitweb?p=projects/xcvb/asdf.git

It still doesn't work perfectly with ECL (can load the new asdf, but not load-op it from the old one), but that will be good enough, especially as juanjo looks like he'll bundle the new ASDF when I release it. Other implementations tested (SBCL, CLISP, CCL) seem to like it either way.

Faré (fahree) wrote :

Upgradability means that if you solve another problem, you can easily deploy a fix wherever you need it, instead of having to rely on the fix being solved upstream.

However, I can see another interesting issue wrt SBCL distributing the new ASDF2, which with the current SBCL ASDF hack would shadow any ASDF upgrade you'd like to distribute to replace it. So you couldn't asdf:load-system :asdf, you'd have to load the new asdf.lisp. Same situation as ECL above, except the bug would persist from new to newer ASDF.

Shouldn't be a big deal. But hopefully we'll find a better way.

On 2/3/10 Feb 3 -11:22 AM, Faré wrote:
> I believe the fixes committed in 1.596 in my repo provide a satisfactory
> solution.
>
> http://common-lisp.net/gitweb?p=projects/xcvb/asdf.git
>
> It still doesn't work perfectly with ECL (can load the new asdf, but not
> load-op it from the old one), but that will be good enough, especially
> as juanjo looks like he'll bundle the new ASDF when I release it. Other
> implementations tested (SBCL, CLISP, CCL) seem to like it either way.
>

I have an ACL license. Would you like me to test this? Is there a test
I can run? Or, if there's something specific I should throw at the
repl, please let me know.

Faré (fahree) wrote :

First, you can
make test lisp=allegro
make test lisp=allegromodern

then you can start your alisp and/or mlisp and try each of these in a fresh image (changing the paths as appropriate):

(require :asdf) (pushnew "/home/fare/cl/asdf/" asdf:*central-registry*) (asdf:oos 'asdf:load-op :asdf)

(load "/home/fare/cl/asdf/asdf.lisp") (asdf:load-system :asdf)

(require :asdf) (load "/home/fare/cl/asdf/asdf.lisp") (asdf:load-system :asdf)

If you can also configure your ~/.common-lisp/source-registry.conf properly, that's fine.

Faré (fahree) on 2010-02-04
Changed in asdf:
status: Fix Committed → Fix Released
Robert P. Goldman (rpgoldman) wrote :

I have not tested this as thoroughly as it deserves to be tested (we should probably set up some automated tests), but as far as I can tell it works on Allegro.

Faré (fahree) on 2010-04-12
Changed in asdf:
importance: Undecided → Medium
milestone: none → version2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers