"JM" == John Morrison jm@mak.com writes:
JM> On Wednesday 15 March 2006 09:00 am, rpgoldman@real-time.com JM> wrote: >> More difficult (but possibly conjectural) what happens if >> *another* system you want loads cl-fad or spatial-trees and the >> version that other system needs is not congruent with McCLIM's >> requirements? I know I always get a little nervous when >> asdf-install loads its private copy of cl-ppcre...
JM> I am using McCLIM to graph cl-graph based graphs, and cl-graph JM> requires cl-fad. So, basically, this problem is not JM> conjectural for me.
I should have been more clear. The problem is conjectural in the sense that we don't have a case (yet, AFAIK) where version conflict arises. E.g., where someone refactors cl-FAD, changing its API, and cl-graph adopts the bleeding-edge version of cl-fad, but McCLIM stays with cl-fad classic.
A counterargument to my claim would be "you should just always use the latest released version." I think in the large this approach is losing. But it's not clear that the CL community IS large enough for it to be a problem.
This is a problem that McCLIM experiences, because it uses ASDF, but it's really an ASDF problem, not a McCLIM problem.
We (the CL community) are using ASDF as the equivalent of make + a dynamic library loading system + something akin to rpm. It's clearly very good as a make substitute. It's not clear to me that it's all we need for the latter two functions.
best, Robert