New Worlds And Lispy Solutions
Lispy
DISCLAIMER: I've just looked very briefly at the code of Lispy!
Matthew Kennedy's Lispy aims to be simple and easy to use and is based on concepts which are proven to work for Linux distributions. Lispy is not really centrally organized, but it doesn't seem to emphasize distributed facilities very much. It seems to be quite easy though to setup a Lispy repository - all you need is some web space and a mapping file which stores metadata about all provided packages. As far as I understood it, versions are handled as chronological markers and there is a distinction between versions which come from package authors and versions which are managed by the Lispy system. There are MD5 sums of the asdf-system tarballs to enable efficient ways for verification of integrity and authentication. Matthew's design is based on his experience from managing Lisp packages for the Gentoo portage project and it actually is designed as a system to manage package distributions. In regard to my find/acquire/verify/authenticate quadruple he decided not to conflate loading of packages and installation of packages into one operation (acquire); this is maybe indeed the better thing to do. I didn't understand really who is responsible for the creation of the mapping-files; particularly where the :depends-on information is coming from. My opinion about Lispy is, that it looks very well designed. On the first sight it seems to be more suited for package maintainers than for developers. That may sound a bit weird, what I actually mean is that it seems to be more suited to manage released versions of a package. What should I do if I need a particular (perhaps locally patched) version of a package for only a particular project? If I understand Lispy right, then I would define a repository (mapping-file) for each such project. It also doesn't seem to support fetching packages out of scm repositories (cvs, darcs, svn...) and defines asdf-packages as tarballs. I still think the MD5/SHA digest should be computed from a defined order of the files of a source package and not from a tarball. Perhaps there could be an ASDF operation which computes the digest instead of compiling the files - so the digest would be defined only by the files relevant to the ASDF-System.
Worlds Apart
To me a world in the common lisp system management
context is a logical bundle of systems used in a
particular project or setting. It defines the context
needed for development and deployment. A
system-version could be uniquely identified by its
system-name and a digest from the defined order of
the content files. This would also mean, that world
is actually defined by the a set of particular
versions of asdf-packages. If one changes one of the
packages it is not the same world anymore. This is
similar to the concept of identity in git (see e. g.
Nikodemus Siivola's explanation) Gary's command-set for
working with worlds (he called them
"environments") looks a bit to procedural to me. I
would prefer a more declarative syntax. So instead
of writing CREATE-WORLD and CLONE-WORLD as a user
I would rather use a DEFINE-WORLD macro which
defines the dependencies of a world. A world
should know anything needed to upgrade the systems
if needed. So if a system in my world is defined
to track the changes of a particular branch in a
scm system - so be it. I think worlds could be
quite similar to the shelfs of cl-librarian. The main difference
between "worlds" and "mapping repositories" (like
in lispy) is that the first is a set of
asdf-systems from the standpoint of a asdf-package
user and the latter is from the standpoint of a
package-publisher. The only reason to publish a
world definition is actually to readily deployable
(batteries included) projects. So the packages
within a world should in some way depend on each
other while the packages within a mapping
repository (a "distribution") may have the only
common point that they are maintained by the same
person.
