[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)

Frank Shearar frank.shearar at gmail.com
Wed Mar 6 16:46:42 UTC 2013


On 6 March 2013 15:26, Tobias Pape <Das.Linux at gmx.de> wrote:
> Am 06.03.2013 um 13:31 schrieb Frank Shearar <frank.shearar at gmail.com>:
>
>> On 6 March 2013 10:39, 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:
>>>>
>>>> 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.
>>>
>>>>
>>>>
>>>> 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?
>>
>> Well, leaving aside Seaside, which is a very complicated example,
>> "imperative" seems a bit of a misnomer. Let's say I reverse my
>> decision and use a ConfigurationOf in my Control load script. There's
>> no difference between
>>
>>    Installer squeakmap
>>        update;
>>        install: 'Control (head)'
>>
>> and
>>
>>    Installer ss3
>>        project: 'Control';
>>        install: 'ConfigurationOfControl'.
>>
>>    (Smalltalk at: #ConfigurationOfControl) loadDevelopment
>
> Well, undoubtedly, the invocation of the installation is an
> “imperative” thing whenever code is involved :)
>
> But the script behind  'Control (head)' is imperative
> while the specification in ConfigurationOfControl is
> declarative.
>
>>
>> There is a crucial difference in the general sense, which is that a
>> ConfigurationOf allows you to track dependencies, including transitive
>> ones. That is a massive win, and swamps the relatively minor issues I
>> have with Metacello (like hard-coding where to get one's mcz files).
>
>
> At a certain point you have to ay where the code is to be found :)
> In your install script, it is also hardcoded:
>
> Installer ss3
>         project: 'Control';
>         addPackage: 'Control-fbs.19';
>         addPackage: 'ControlTests-fbs.15';
>         install.
>
> In Metacello, you could specify multiple (possibly backup) repositories.
>
> But other than that, I agree with you :)

Yes, but I don't expect Installer to do anything more: it's
brain-dead. Whereas with Metacello I did expect to have that clean
separation like you do with Maven, where your profile - configuration
- says where to get artifacts.

frank

> best
>         -tobias


More information about the Squeak-dev mailing list