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

> 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.
>

> 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 <[hidden email]>:
>
>> 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.
>>
>
> [SQMP]
> 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
> Metacello.
>
> 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?
>>
>
> [SEAS]
> 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]
>>>        http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
>>>        http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
>>> […]
> ===========>
>>> To any Seaside dev, please consider merging my versions :)
> <==========
>
> [MTCL]
> 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?
>
> Best
> -Tobias
>
>
>
> [1] Message-Id: <[hidden email]>
> [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: <[hidden email]>
>