Nikodemus Siivola wrote:
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?
We often work in a distributed way, so there are really two different "delivery" scenarios:
1. To the user. This is very much along the lines that you have outlined above --- we try to be independent of the lisp environment (if any) on the site. Indeed, when we can manage it, we find the best delivery solution is often a live cd. This is because we often want to work with other software packages (e.g., ImageMagick, Grass GIS, etc.). In that case, even if one can manage all the across lisp oddities, there's still the question of how daemons are started, what libraries and other applications are installed, etc. A nightmare!
2. To different developers, often at different companies. In this case, we typically cannot control the lisp development environment (and we may be working in a team where some developers are using ACL, CCL, and SBCL). In this case, which is probably most relevant to our discussion here, we try to make sure that all libraries are in the revision control system (which means we typically mirror open source CL libraries into our own SVN), and we use a solution that we have developed that will populate the developer's asdf:*central-registry* in a way that creates a coherent development environment across different developers, machines, and sites.
For these cases, we typically do not try to hijack the developer's lisp init file, for two reasons --- first, the user typically has configurations that make things easy and familiar for him/her and second, we would have to provide multiple init files (for the different lisps).
We'd probably be happiest doing something that I've described above --- adding modifications that are proximal to the individual libraries, rather than putting them in a central configuration file --- because this allows us to share those modifications across multiple copies of the same library, in different svn repositories. When we move from one project to another, we'd rather have our configuration for a library with the library, instead of remote.
I hope that I haven't bored you with this long account...
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?
I think the discussion above should mostly explain things. One additional point I should probably make:
1. We have developed an 'asd-finder' in pure common-lisp that can be used to find all the .asd files in a directory subtree(s). This allows us to populate asdf:*central-registry* from an SVN repository working copy without fussing with symbolic links, etc. It also is robust to the addition of new libraries w/o fussing with configuration files.
2. We have a macro that defines a simple command that points the asd finder at a bunch of directories and populates the asdf:*central-registry*. This means at the start of a programming session, I can start my lisp, type a one-word command that will give me the right asdf context, and then can start work from there (typically, but not always, by loading the top-level asdf system).
The above routine, at the expense of a limited overhead at the start of a programming session, saves us from the muss and fuss of building symlink farms, and makes starting work on a new machine a mere matter of checking out an svn repository.
Best, Robert