Ewww! Dependencies.

My project uses a couple of routines from local-time, and I was horrified to find it had so many dependencies

• FiveAm
• cl-ppcre
• cl-ppcre-unicode
• cl-unicode
• arnesi
• flexi-streams
• trivial-gray-streams
• cl-fad.

So I modified my ebuild (Gentoo) to not require FiveAM (the testing framework local-time can use) --- and it (thankfully) all went away.

Whats a test framework doing with 2 stream implementations, a file abstraction layer, 2 regex libraries and a box of utilities?

Yea, this is an old problem. I blogged about my similar experience a while ago:
http://www.findinglisp.com/blog/2009/10 ... atman.html

The short of it is, people grab one little utility routine out of a larger library and then that library pulls in another dependency, and so on...

I never understood why that is a problem. Lisp libraries are very small downloads, you only download them once, and these days installing things with quicklisp is trivial. Code reuse is a good thing.

Warren Wilkinson wrote:Whats a test framework doing with 2 stream implementations, a file abstraction layer, 2 regex libraries and a box of utilities?

Those are not two stream implementation, it's an implementation compatibility library for extensible streams, since unfortunately those are not in the standard, used to implement bivalent and in memory streams, and one regex library with a separate unicode extension. All those are more or less valid for a testing framework.

Ramarren wrote:I never understood why that is a problem. Lisp libraries are very small downloads, you only download them once, and these days installing things with quicklisp is trivial. Code reuse is a good thing.

Dependencies tend to be fragile, so it's a good idea to minimise them as far as possible. Specifically, they can develop into a problem when libraries are changed incompatibly or bugs are introduced. For instance, if library A depends on version 1 of library C, and library B depends on some incompatible version 2 of the same library, conflicts ensue. If library B happens to have been based on version 1 of library C in the past, such that there was no conflict, then this can all of a sudden break lots and lots of dependency chains that depend on libraries A and B simultaneously.

These things happen. I know they have happened to me at least...

These code churn and bitrot issues are not unique to CL. Programmers in other languages manage to work the same issues. Unless the library is nearly trivial, its generally better to share and reuse code than to reimplement it from scratch.

FiveAM uses Arnesi, which is a "library" that comes with dozens of unrelated things you don't really want or need (including its own version of SWANK...), and a bunch of implementation-specific dependencies (it won't work on newer versions of Lispworks for example).

Fortunately there's EOS, which is a drop-in replacement for FiveAM, in portable CL without any dependencies. I switched all my FiveAM-using projects to that, and I recommend others do the same.