2009/5/13 Robert Goldman rpgoldman@sift.info:
I guess that this is a matter of aesthetics, about which we'll have to agree to disagree. I think small snippets of code that are located close to the things that they are supposed to configure are easier to track, understand, and even test than stuff that's squirreled away non-locally (e.g., in /usr/local/etc/sbclrc).
To a degree, yes. However, "X doesn't work on my system" is made a lot harder to reproduce / debug remotely the more sources of code there are. Also, ASFD just deprecated preference files some time back -- and I'm not sure how configuration files would differ from preference files.
I think there are a a couple of facts about what I'm doing, and how it differs from what you are doing that may make for this difference of opinion.
I'm concerned with delivering applications, rather than delivering a lisp implementation, which seems more like your concern.
This means that I'm typically not messing with a site's global lisp configuration, but rather local configurations.
I would have imagined that most lisp applications would be delivered independently of the lisp development framework possibly at place. (Which in my books includes all the .lisp, .asd and .fasl files: the application either delivers all it's own ancilliary files or is a single executable.) Maybe this is not so.
Can you describe your typical delivery scenario?
I'm also often working with multiple lisp implementations concurrently, which also leads me to see this as an issue of configuring the individual libraries.
For that matter, I'm typically working with > 1 different lisp project, in different lisp configurations (the projects have different source repositories, assume different libraries, etc.). So I typically work with multiple different asdf:*central-registry* configurations.
This is something I have almost no experience in. Can you outline the major issues as you see them?
Cheers,
-- Nikodemus