It seems that, at the moment, the "Common Lisp Community" (no, there isn't really such a cohesive thing, but it sounds kinda good, doesn't it?) seems to have a deep love of source code packaging for projects being "check the latest code out of VCOC (version control system of choice)" and that makes it hard for semi-interested bystanders.
It is especially hard when you're looking at multiple dependencies who all subscribe to packaging as "check the latest code out of VCOC". It only gets better once you find yourself with a third-party packaging effort, bundling things up in actual, version-tagged, software bundles and things start interacting in highly amusing (read: "rather flippin' annoying") ways.
This has several benefits, in that stuff gets developed in a more natural and organic way and you don't have to worry too much about deciding what is a major, minor or point release. All good, you can say "no, use something from after August" or similar.
There's also the (possibly idle) hope that some testing has been done of a packaged version of a library (this is, however, not always true, as I know I occasionally conveniently forget to do this).
Ideally, what I'd like is something like ASDF-Install, only aware of version dependencies (so I could say "I want the Blahonga library, at version 0.2 or later" and "I want the Zorbinator library, no later than 0.9.2") and package installation magically happens and keeps everything in sync, as it were.
In addition, I want it to not have a "single point of failure" (ASDF-Install as-is lives and dies by CLiki.net. I could, possibly, live with a URL that lists one or more base sites to look for things, though. Especially if this site was suitably funded by, I don't know, a foundation or something.
Oh, yes, even further, I would NOT mind having the ability for the software library managery thingy to keep tracks of things to the point where I can say "install library BLAHONGA and keep it up-to-date" and it does this for me, one way or another. It'd also be good having a difefrentiation between "stable" and "experimental", with the "stable" version staying put in times of rapid releases (and "experimental" tracking as close to the bleeding edge as possible) and eventually catching up, as some sort of concensus by maintainer(s) (eiter of the library or by whoever(s) run the more central repository of stuffs-to-install) is reached that it is, indeed, stable.
I am, to be honest, less fussed if this an entirely in-lisp thing or relies on external code. However, having it all in-image has a neatness to it that is hard to deny.
This is one of Ingvar's essays
By: Leslie P. Polzer
2009-01-30 09:06
I've been worried a bit about this too, but in a bit different way: We at Weblocks don't release tarballs either right now, but we offer a stable repository that gets updated only with well-tested changesets of our development repository. I think this is a good compromise between static fixed-version tarballs (where you can't add a "quick fix" to a version except by bumping it and releasing a new tarball altogether) and runaway bleeding edge repositories. Unfortunately most if not all other projects that don't offer stable tarballs do not offer a stable repository either.
By: Henrik Hjelte
2009-01-30 14:06
Let me make an ad for my vaporware, I am working on something I might call lispmix that I hope will solve this. The idea is to force every dependency to be in darcs (or imported to darcs), then keeping track of all dependencies on a patch level. You can call (darcs-describe-and-save 'project), and it will make a file that keeps track of all the patches of all dependencies you have. This file can then be used to get an exact copy of your systems as it was in a point in time. I indent to combine this with an infrastructure("buildbot" like) for automatic testing, so each time you can get a known-good version of a project, or a latest version that might have dependency problems. You can also compare your local versions with the latest versions, and see the exact new updates on a patch level. Also, I have a installer that imports everything to darcs, last time I checked (import :hunchentooth) worked perfectly. It will be vaporware probaby for some months, I want to add some features before making a release.
By: ibor
2009-01-31 17:29
Many revision controll systems can generate archives on the fly (check out 'git tar-tree', 'hg archive' or 'darcs dist'). It's even simpler to directly link to the webinterface's download button. Gitweb automatically generates tarballs for tags, branch heads or commit ids (e.g. http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.28.y.git;a=snapshot;h=v2.6.28.2). For Bitbucket you currently need the commit id (e.g. http://bitbucket.org/skypher/weblocks-stable/get/7b1fea8d1d6f.zip).
By: Ingvar
2009-03-26 10:05
All excellent points. I suspect I'll be needing to update this essay in the not-too-distant future.
By: schaueho
2009-08-10 10:34
If you look beyond your own plate, it's quite easy to see that Lisp community is far behind other communities in this regard. Take for instance the infamous CPAN which is basically there since ages. The python community has pypi, setuptools and buildout being the de-facto standards, whereby versioned dependencies are supported as well as having separate ways ("recipes") to track software from other places (say, VCS checkouts). They do have a central server but it's not too difficult to set up a personal mirror. The interesting thing, though, is that they are facing several problems on their own (the mirror facility isn't too old, for instance), which the lisp community is likely to rediscover sooner or later. I think it's pretty sad that for this particular theme lisp is going to be greenspunning others technology, but I hope at least someday something will come out of it that avoids their baby mistakes.