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

H. Hirzel hannes.hirzel at gmail.com
Wed Mar 6 10:45:05 UTC 2013


On 3/6/13, Tobias Pape <Das.Linux at gmx.de> wrote:
> Am 06.03.2013 um 11:09 schrieb Frank Shearar <frank.shearar at gmail.com>:
>
>> On 6 March 2013 09:30, Tobias Pape <Das.Linux at gmx.de> wrote:
>>> 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 gmail.com>:
>>>
>>>> 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.
>>
>> There's nothing stopping a package maintainer using Metacello. Perhaps
>> when Chris & I nag people to make an SM catalog entry we should nag
>> them to add a ConfigurationOf.
>
> Yes, I think this would be great.
>
>>
>> (I used to have a ConfigurationOfControl; I changed it to an Installer
>> script because the time it took to load Metacello and friends
>> completely dwarfed the time it took to load Control. Control is tiny
>> and has no dependencies outside a standard image.)
>
> Did you happen to have Metacello installed before loading the Config?
> Other than that, I would like to see the config :)
>
>>
>> Or do you mean that SM should expose more of what Metacello does, say
>> by allowing a _user_ (as opposed to my previous
>> multiple-special-versions) to say "I want Seaside 3.0.3, and I see it
>> has multiple profiles; I'd like the release one please"?
>
> Kind of like that. I could expose the versions and groups.
> There is even the possibility to collect the #stable, #development and
> #bleedingEdge markings.
>
>>
>>> 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.
>>
>> You (the package maintainer, not necessarily you, Tobias) could always
>> have multiple releases - (4.4 development), (4.4 release), etc. - for
>> a package. Each of these would have a load script calling
>> ConfigurationOfFoo
>
> Yes this would be possible.
> I have two major problems with such an approach:
>
> 1) It is still imperative and you have to manually synchronize the
> SqueakMap releases with the Metacello configurations. Say,
> Seaside in 3.0.3 with all its glory is on SqueakMap as about 61 releases.
> (why so much? see 2) ) When you want to have a 3.0.4 release you have
> to make 12 new release for 3.0.4. Really?
>
> 2) It is not the simple case that there are just 2 releases, say
> development
> and deployment, it is more like Feature selection, however this leads to
> release explosion. I will now, just from memory try to recall possible
> combination
> that in this scenario would qualify as an independent release:
>
> • Seaside 3.0.3 Base
> • Seaside 3.0.3 Base, Comanche
> • Seaside 3.0.3 Base, Fcgi
> • Seaside 3.0.3 Base, RSS
> • Seaside 3.0.3 Base, Email
> • Seaside 3.0.3 Base, Scriptatcoulus
> • Seaside 3.0.3 Base, jQuery
> • Seaside 3.0.3 Base, Comanche, Fcgi
> • Seaside 3.0.3 Base, Comanche, RSS
> • Seaside 3.0.3 Base, Comanche, Email
> • Seaside 3.0.3 Base, Comanche, Scriptatcoulus
> • Seaside 3.0.3 Base, Comanche, jQuery
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS
> • Seaside 3.0.3 Base, Comanche, Fcgi, Email
> • Seaside 3.0.3 Base, Comanche, Fcgi, Scriptatcoulus
> • Seaside 3.0.3 Base, Comanche, Fcgi, jQuery
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Scriptatcoulus
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, jQuery
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, Scriptatcoulus
> • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, jQuery
> • Seaside 3.0.3 Base, Fcgi, RSS
> • Seaside 3.0.3 Base, Fcgi, Email
> • Seaside 3.0.3 Base, Fcgi, Scriptatcoulus
> • Seaside 3.0.3 Base, Fcgi, jQuery
> • Seaside 3.0.3 Base, Fcgi, RSS, Email
> • Seaside 3.0.3 Base, Fcgi, RSS, Scriptatcoulus
> • Seaside 3.0.3 Base, Fcgi, RSS, jQuery
> • Seaside 3.0.3 Base, Fcgi, RSS, Email, Scriptatcoulus
> • Seaside 3.0.3 Base, Fcgi, RSS, Email, jQuery
> • Seaside 3.0.3 Development
> • Seaside 3.0.3 Development, Comanche
> • Seaside 3.0.3 Development, Fcgi
> • Seaside 3.0.3 Development, RSS
> • Seaside 3.0.3 Development, Email
> • Seaside 3.0.3 Development, Scriptatcoulus
> • Seaside 3.0.3 Development, jQuery
> • Seaside 3.0.3 Development, Comanche, Fcgi
> • Seaside 3.0.3 Development, Comanche, RSS
> • Seaside 3.0.3 Development, Comanche, Email
> • Seaside 3.0.3 Development, Comanche, Scriptatcoulus
> • Seaside 3.0.3 Development, Comanche, jQuery
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS
> • Seaside 3.0.3 Development, Comanche, Fcgi, Email
> • Seaside 3.0.3 Development, Comanche, Fcgi, Scriptatcoulus
> • Seaside 3.0.3 Development, Comanche, Fcgi, jQuery
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Scriptatcoulus
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, jQuery
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, Scriptatcoulus
> • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, jQuery
> • Seaside 3.0.3 Development, Fcgi, RSS
> • Seaside 3.0.3 Development, Fcgi, Email
> • Seaside 3.0.3 Development, Fcgi, Scriptatcoulus
> • Seaside 3.0.3 Development, Fcgi, jQuery
> • Seaside 3.0.3 Development, Fcgi, RSS, Email
> • Seaside 3.0.3 Development, Fcgi, RSS, Scriptatcoulus
> • Seaside 3.0.3 Development, Fcgi, RSS, jQuery
> • Seaside 3.0.3 Development, Fcgi, RSS, Email, Scriptatcoulus
> • Seaside 3.0.3 Development, Fcgi, RSS, Email, jQuery
> • Seaside 3.0.3 One-click
>
> [this is not exhaustive …]
>
> I hope you understand that I do not want to make 61+ individual releases.
>
> We should avoid double implementation effort here.
>
> Can’t we make a SMMetacelloPackage?

Sounds good. What would that imply?
--HH

> Best
> 	-Tobias
>
>
>
>


More information about the Squeak-dev mailing list