ZeroInstall Assessment

Dave Abrahams — Sat, 04 Feb 2012 02:29:57 +0000

I’ve been looking into 0install (ZI) for the past few weeks, and asking lots of questions on their mailing list where they’ve been very patient and receptive. Yesterday I spent the better part of an all-day journey to Kona digesting the documentation.

As far as I can tell, this is a truly amazing system. If 0install fulfills its promise, it means that the Ryppl project hardly needs to develop any of its own technology.

There are only a few ways in which 0install is not a perfect match for the Ryppl vision:

LGPL. We’ve discussed this already.
- I think the benefits of using 0install far outweigh the “LGPL Fear and Loathing” cost
- Those who can’t even abide LGPL in their tools will not be forced to use ZI in order to use Boost; we should be able to produce installers for their native systems using CMake, near as I can tell
It lacks support for “trusted catalogs” of software. Each component has its own URI that is used for initial installation; there’s no way to say, “let me use anything from this large collection of software by using a short non-URI-ish name.” Such a capability is trivial to build into ZI, and their developers seem receptive to the idea, so I think they may be willing to do it. Failing that, we can easily produce the patch, and failing /that/ the fallback is to create a trivial layer over ZI, or decide we can do without it.
It is decentralized. This is one of ZI’s great strengths, but I think it could also be a serious weakness. In particular, without a central collection for people to “go to,” I don’t see Troy Straszheim’s original vision of a vibrant “CPAN for C++” coming into being. Ryppl aside, this lack of centrality could easily hurt ZI’s adoption too. Fortunately, though, the technology for solving this problem is basically the same as the technology for solving #2, and is straightforward.

Ryppl/cmake integration making progress

Eric Niebler — Wed, 25 Aug 2010 07:58:42 +0000

Lately, we’ve been working on getting ryppl to play nicely with CMake. That is, we want ryppl to automatically detect that a package is CMake-able and invoke appropriate cmake commands to do things like build and install. I’m happy to say that for simple projects, that now works. If you use CMake’s built-in install macro to install files, then ryppl will just do the right thing. What’s more, we can take the output of CMake’s install command to automatically generate the project’s manifest so that ryppl knows how to uninstall it. Neat and tidy.