From a look at http://www.quicklisp.org/beta/, it looks like another single-language tool for smuggling code onto a box while failing to set up any interdependencies with the system's package manager. I don't like being so harsh, but "every language has its own packages and none of them interop at all" is a growing antipattern that eventually leads to horrible messes.
And every system has their own package manager and none of them interop at all.
If I'm writing a CL package, a Python package, or a Ruby package, then I'd rather spend my time getting them to work in their respective language eco-system instead of working in the Ubuntu, Debian, Red Hat, Windows, OS X, FreeBSD, etc. eco-system.
Which is all good, because system package managers usually adds six months to two years latency to feature updates.
I'd rather that the development environment have a tool for managing its libraries than I have to install them all by hand. It's a horribly broken system to have the same cadence for vital system parts and development frameworks. Running a stable system while having bleeding edge tools and applications shouldn't need to be an unattainable edge case.
Seen complaints about startups which are obviously saving passwords in plaintext? Imagine how much worse it would be if all the "why you shouldn't it that way" criticism was consigned to obscure blogs rather than here. I regard this as that kind of problem--huge long-term drawbacks that people don't proactively go looking into and don't immediately deter implementing the idea.
If you want something done then you need to start on it yourself. Disregarding what QuickLisp has accomplished because you have to deal with more than one package management system is trollish. You'll probably want to start by designing a plugin framework that can support multiple versions of any given language. Also need to be able to bundle dependencies per application, on any operating system, so that you don't pollute the global package space for any one given application under developement. kthx
That seems better reasoned - you could expand on it and explain why this is a problem, how it should be avoided, how language packages should be integrated with system packages, etc. That would make for very interesting reading.
I'm wondering if a 'new' age of sysadmin is coming along that will basically build a vm-image of an application node, with the OS built using chef/puppet/etc, so that the host packages are as few as possible. Just a thought.
> it looks like another single-language tool for smuggling code onto a box while failing to set up any interdependencies with the system's package manager. I don't like being so harsh, but "every language has its own packages and none of them interop at all" is a growing antipattern that eventually leads to horrible messes.
I like that Quicklisp doesn't interoperate with the system package manager (I use Debian and Debian derivatives mostly). Quicklisp sets up repositories per-user, which means I can easily have different versions of libraries running for different users. This is handy because the Unix user facility is the original "virtual machine." All Common Lisp implementations are also very easy to set up to run from your home directory, which is great. I never use apt for installing CL implementations.
System packaging is great for command-line and GUI applications, and certain services like databases. But I don't think it works for development, and I don't even think that having machine-wide library installation (like npm and RubyGems) is a good idea. I've used npm and RubyGems and the way Quicklisp does things is much better in my experience (although one thing it doesn't provide is library versioning for individual projects).
Why should I bother? I have many projects on my box, each of them lives in virtualenv, each has it's own packages and all the projects are separated from themselves and the system (meaning my global, system-level python can not use any of the packages in virtualenv).
So why should tell system pkg manager about something which is not system-wide?
