ASDF should be able to upgrade itself
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ASDF |
Fix Released
|
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-
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.
Changed in asdf: | |
status: | In Progress → Fix Committed |
Changed in asdf: | |
status: | Fix Committed → Fix Released |
Changed in asdf: | |
importance: | Undecided → Medium |
milestone: | none → version2 |
See my rant http:// fare.livejourna l.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 lisp/asdf. conf
/etc/common-
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.