[Seaside-dev] Detecting installed Seaside versions?

[Colin Putney]

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