Seaside, Squeak4.4, SqueakMap and Metacello, or Why Software Configuration Management is Important (war: Re: [Seaside] New catalog entry for Seaside 3.0.3)

Tobias Pape Das.Linux at
Wed Mar 6 09:30:58 UTC 2013

Hi All,

as this thread continues, and I have some cross-post replies, I reply to the initial 
post here, hope you don't mind.

• For SqueakMap things goto [SQMP]
• Seaside-Developers, please read [SEAS]
• For Metacello-stuff please goto [MTCL]

Am 27.02.2013 um 03:50 schrieb Chris Muller <asqueaker at>:

> Hi Tobias, I made new Community-Supported catalog entries for:
>  DynamicBindings ("4.4" and "head")
>  KomHttpServer ("4.4")
>  Grease ("1.1.0" and "head")
>  Sport (already up-to-date, no action taken)
>  Seaside ("3.0.3")
> These each consume with single-click (necessary pre-reqs are loaded
> automatically for each package).  Installing the head versions always
> perform a merge, similar to updating trunk packages.

I have read the SqueakMap entries. 

From my point of view, they pose a quite big problem.

Please consider this Scenario:

For one reason or another, I happen to have the Class `GRPlaform` 
in my image but not actually Grease installed. Now suppose I
use the SqueakMap entry for Seaside. It installs but fails with
—seemingly random—errors.
  What happens here? The install _script_ for Seaside tries to
determine whether Grease is installed by checking whether the
class `GRPlatform` is in the System. Yes, this is a pathological 
case but I chose it to illustrate the underlying problem:

The SqueakMap install scripts are _imperative_ load scripts.
That is one of the key points of Metacello. To quote 
the web site:
	Declarative modeling. A Metacello project has named versions 
consisting of lists of explicit Monticello package versions. Dependencies 
are explicitly expressed in terms of named versions of required projects. 
A required project is a reference to another Metacello project.

In the given case, when I install Seaside via the Metacello configuration,
the Seaside config specifies a dependency on Grease declaratively and
Metacello resolves this. In turn, Grease comes with a Metacello config
and Metacello then can determine whether Grease is already installed
via Metacello.
  In our case, it would determine that Grease is not installed and
would try to install it. _This_ certainly would fail, as our `GRPlatform`
class would conflict the one of Grease, but at least we would _know_
that this is the problem: Monticello would notify us that we are trying
to overwrite an  existing class.

What I wanted to depict is that there is a problem with the “install script”
driven approach to SqueakMap. I do not argue that SqueakMap is obsolete
nor a bad idea. I, however, want to argue that SqueakMap should embrace

Another point I have seen is that SqueakMap has to invest double effort
to “synchronize” versions.
  See, Metacello configurations already contain all versions available for
the given configuration.
  Moreover, using the current way of SqueakMap to install software conflicts
with the idea of optional software components. This can be seen by the 
problems Hannes has with installing Seaside [1]. The SqueakMap entry
cannot disambiguate between a “Development” installation and a “Deployment”
installation; the Metacello config for Seaside already allows for this:
   When you load the 'Development' group, you get OB, Ocompletion, the
server adaptor browser, Seaside development tools, some predefined adaptors
etc. When you load the “default” group (alias for the “Base” group), you 
get the bare minimum to make Seaside run, even without any adaptor, which 
is intentional. You choose the “Base” group and, say, the “Comanche” group
and you get what is necessary to run. I don’t see a way to do this with 
SqeuakMap currently. 
  However, this workflow is crucial to me. I maintain SqueakSource3[2] which
also has optional packages. With SqueakMap, I currently cannot provide
an installation with such optional packages. Likewise with SwaLint.

> I didn't know what version to make for DynamicBindings and
> KomHttpServer so I just made them the same as the Squeak version
> they're for.

There is an ConfigurationOfKomHttpServer that could be used..

> I didn't make head versions of KomHttpServer or Seaside because I
> wanted to ask your (and others') opinions about it.  If Seaside
> Development Team is still putting out Squeak versions and using
> Metacello to keep that managed, our catalog entries should definitely
> reflect that.

Yes:) Where I could help, I would like to.

>  Otherwise, it's worth asking, what is the best way for
> us as a community to keep up a dependably working version of Seaside
> for Squeak?
> Do you know why the Metacello scripts keep failing for stuff that was
> once working?

As dale said in [3]

	“If I'm not mistaken the "Metacello failures" are due to the fact 
that new configurations created for Seaside but are not actually tested 
against Squeak until someone (like Tobias) comes along and gives them a try 
... there hasn't been an official squeak maintainer for Seaside for 
several years now...”

I am currently looking into making Seaside loadable again by
taking care that the ConfigruationOfSeaside30 has the right
dependencies for Squeak 4.4

To repeaat myself:

>> You load  [1]
>> […] 
>> To any Seaside dev, please consider merging my versions :)

Side-Note: Metacello does not yet know of 4.3, 4.4 and 4.5 (as 
our current trunk) as Platform Identifiers. How shall we proceed?
Who can add these?

Sorry for this being so long, but this is rather important to me.
I am open for discussion and directions. What about an IRC chat, 
eg, on freenode?


[1] Message-Id: <CAGQxfViuK97mApjNX+ANQo3FieoXJ749ebF6wp+Rt2r890LC8A at>
[2] PS: I tried searching the SqueakMap Catalogue for “Squeaksource”, however, nearly
    every package matched. Shouldn’t the search box only match the name and, optionally,
    the description but _not_ the installation source?
[3] Message-ID: <454120174.8769768.1362164125368.JavaMail.root at>

More information about the seaside mailing list