[Seaside-dev] Detecting installed Seaside versions?
Colin Putney
cputney at wiresong.ca
Wed Nov 25 22:34:57 UTC 2009
On 25-Nov-09, at 9:45 AM, Dale Henrichs wrote:
> Colin,
>
> The down-side to having a constant in the image that records the
> "last version loaded" is that users are free to load packages
> independently, without ensuring that the "last version loaded" is
> updated appropriately.
>
> It is certainly a good enough solution.
>
> The point of Metacello is to create a specification for a particular
> version, so that no matter how that particular version got loaded
> the current image can be compared to the spec and the "current
> version" can be calculated.
>
> It's one of the fundamental problems with "Package management" -
> when the package data base does not match the installed system.
> Metacello is not immune to the problem, but since it dynamically
> calculates the version based on a spec and the existing image, it
> has a chance of getting a good answer.
>
> Ad hoc solutions start breaking down when a particular user is
> interested in reasoning about cross project dependencies, based on
> versions ... a problem that every current Smalltalk programmer has:)
>
> I'm not going to say that Metacello is the last word in package
> management for Smalltalk, but it _is_ an attempt to address some of
> the larger problems that the consumers of multiple software projects
> have to deal with...
I think one of the biggest problems Squeak (and Gemstone, to the
extent that it participates in the Squeak ecosystem) has today is that
there aren't any good mechanisms for distributing code for deployment.
Monticello makes a reasonably good versioning tool for development,
but it was not designed for *distributing* software. It does have the
nifty property that a package version is contained in a single file,
and so we've been using Monticello's internal repository format as a
distribution format. Just download an mcz file and load it into your
image!
That wasn't great, but it worked OK in the early days of Monticello
when most projects were single, monolithic packages. These days,
though, we've got large, multi-platform projects being developed with
Monticello, and configuration management at the level of packages gets
really difficult. OmniBrowser has over a dozen, Monticello 2.0 has
over two dozen, and Seaside has about 5 dozen! So we've had a little
cottage industry of scripts to pull down all those packages and get
them installed.
This is bad for many reasons, but I think the worst effect is to
introduce coupling between the users' installation process and the
developers' development process. All these scripts rely on knowing how
the source code of the project is organized, where it's stored, and
perhaps even the social dynamics of the development team. If I decide
to start using Monticello 2 to develop OmniBrowser, or even move my
repository to another host, it's going to break all those installation
scripts that people have put together.
I'd like to find a better way to distribute Squeak applications, and
for my own projects I'm trying to break that coupling between
installation and development. For example, I've started releasing OB,
MC2 and Filesystem using SAR archives rather than mcz files. This
removes the need for users to have Monticello installed, and if my
FSReleaseInfo experiment pans out, will make it possible to upgrade to
future SAR-based releases easily, again without using Monticello.
Now, it's true, this scheme only works if you install and upgrade
using my SAR releases, but I don't think that's an unreasonable
requirement. If all you want to do is *use* my application, as opposed
to hacking on it, you don't need to install things manually anyway.
Folks who want to participate in development, on the other hand, will
need to know where the repositories are, what the packages are and
their relationships etc, but that's to be expected.
The problem I have with Metacello is that it's really just a cleaner,
more managable version of the install scripts I'm trying to get rid
of. On top of that, it introduces a new dependency for installation -
now users have to have Metacello installed as well as Monticello.
Where I find Metacello valuable is as a development tool, for managing
the metadata I need to reliably build development images and SAR
archives. Unfortunately Metacello wasn't designed for that role, and
I'm not terribly comfortable twisting it to my purposes, because
that's what got us in this mess in the first place. :-)
Colin
More information about the seaside-dev
mailing list