On Wed, 2013-11-20 at 18:54 +0100, Pascal Costanza wrote:
Just to chime in in the middle: There is no known solution to the so-called "DLL hell" problem. Libraries interact badly because of their interactions, not because one or the other is "bad." Even with the best of intentions, a library author cannot predict what changes will break existing clients and what changes won't, because that author doesn't know about all possible interactions. When APIs change, telling clients that they are now incompatible may be a lie, because they may not depend on the specific change. (For example, is the addition of a keyword argument an incompatible change or not? It may, or it may not be...)
Given the flexibility of CL, there are innocuous changes that might break dependent code. For example, adding a new return value to a function is backwards-compatible if the latter is used via multiple-value-bind not if the user employs multiple-value-list plus destructuring-bind. That's perfectly legal CL and, in some cases, might be justifiable as the best solution; even simply adding a function is not backwards-compatible if the dependent code uses boundp at runtime.
If you want to give control to developers, you could provide a way that depends-on specifications are list designators, with some form of declarative way of precisely specifying which versions are compatible and which aren't. (Then you could describe situations like, compatible with everything up to and including 0.9.x, and everything above 1.0.0, but excluding 1.0.0 - a situation that actually occurred when Closer to MOP was incompatible with SBCL 1.0.0 for a brief moment in history... ;)
The Haskell people tried that with cabal but their experience was that too stringent dependency specs make upgrades a hell. Example:
FOO 1.5 depends on BAR <= 1.2 && >= 1.0 QUUX 0.7 depends on FOO <= 1.5 && >= 1.0 and BAR <= 1.2 && >= 1.0
FOO 1.6 is released with dependency on BAR <= 1.5 && >= 1.3
Now one cannot install QUUX any more because its dependencies cannot be met. It directly depends on BAR <= 1.2 and indirectly on BAR >= 1.3 Users of QUUX will have to modify it locally and contact its developer to update the definition of QUUX or fix it.
In practice it seems that the best thing to do is have relaxed dependencies and rely on an integrator/distributor to put together packages and developers have to make sure that when they make a release, their library works with the most recent release of its dependencies. In other words, work with snapshots of the development "world" and never try to mix libraries from different ages.