[asdf-devel] ASDF:OOS LOAD-OP :FORCE T and SBCL contribs

[Robert Goldman]

Nikodemus Siivola wrote:
> 2009/5/13 Robert Goldman <rpgoldman at 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