New catalog entry for Seaside 3.0.3

> Am 06.03.2013 um 11:09 schrieb Frank Shearar <[hidden email]>:
>
>> On 6 March 2013 09:30, Tobias Pape <[hidden email]> 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 <[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.
>>
>> 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.

> On 6 March 2013 10:39, Tobias Pape <[hidden email]> wrote:
>> Am 06.03.2013 um 11:09 schrieb Frank Shearar <[hidden email]>:
>>
>>> On 6 March 2013 09:30, Tobias Pape <[hidden email]> 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

> Am 06.03.2013 um 13:31 schrieb Frank Shearar <[hidden email]>:
>
>> On 6 March 2013 10:39, Tobias Pape <[hidden email]> wrote:
>>> Am 06.03.2013 um 11:09 schrieb Frank Shearar <[hidden email]>:
>>>
>>>> On 6 March 2013 09:30, Tobias Pape <[hidden email]> 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 :)

>> […]
>>
>> 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.

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

> [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
>>> […]

> Chris,
>
> I think that the officially correct script is the configuration ....
>
> Dale
>
> ----- Original Message -----
> | From: "Chris Muller" <[hidden email]>
> | To: "Dale Henrichs" <[hidden email]>
> | Cc: "Seaside - general discussion" <[hidden email]>, "The general-purpose Squeak developers list"
> | <[hidden email]>
> | Sent: Tuesday, March 5, 2013 7:24:56 PM
> | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3
> |
> | > to get a working one-click script recorded there that can do it.
> |
> | Not only just working, but the officially-correct script
> |

> Am 06.03.2013 um 17:46 schrieb Frank Shearar <[hidden email]>:
>>> […]
>>>
>>> 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.
>
> The point with installer in the Metacello-case is
> just to _retrieve_ the configuration. There is an upcoming
> Metacello Scripting api [1], that turns the Metacello thing into:
>
> Metacello new
>         configuration: 'Control';
>         squeaksource: 'Control';
>         version: '1.0';
>         load.
>
> which would not depend on you fetching the configuration.

>
>
> ----- Original Message -----
> | From: "Frank Shearar" <[hidden email]>
> | To: "The general-purpose Squeak developers list" <[hidden email]>
> | Sent: Thursday, March 7, 2013 2:26:45 AM
> | Subject: Re: [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)
> |
> |
> | Well, it depends on what the #squeaksource: send does. The
> | ConfigurationOf should define the dependencies (including versions),
> | but _should not_ tell you where to get the artifacts. So if
> | #squeaksource: (and presumably similar messages) are how you say to
> | Metacello "get these locally or, failing that, get these from A or,
> | failing that, from B", then I'm happy.
>
> Frank,
>
> There are some basic rules that Metacello follows for loading packages:
>
>   1. If the specified package version is already loaded in the
>      image, nothing is done
>   2. If a later version of the package version is already loaded
>      in the image, nothing is done
>   3. If the specified package version is present in the package-cache,
>      the package is loaded from the package-cache
>   4. If the specified package version is found in one of the repositories
>      listed for the package or project (multiple repositories may be
>      specified) the package is loaded from the first repository it is found
>      in (search order of repositories is not guaranteed)
>   5. throw an error
>
> If one doesn't specify an explicit package version then the "latest version of the package" is loaded. The Gofer sort order for packages is used to determine "latest version". In this case, all of the associated repositories are unconditionally searched for the "latest version", but once the "latest version" is determined, the above listed rules are applied.
>
> If a package is dirty, a notification is raised and if handled one can choose to override the dirty package. The default action is to skip loading over dirty pacakages.
>
> The rules for loading configurations is similar to packages except for a couple of exceptions:
>
>   1. If the version being loaded is blessed as #development, then a new copy
>      of the configuration is loaded from the repository.
>   2. If you request a version that is not present in the loaded configuration,
>      then an attempt is made to load the latest version of the configuration
>      package from the repositories associated with the configuration and then
>      the version lookup is tried again.
>
> I'm not exactly sure whether this covers your: "get these locally or, failing that, get these from A or, failing that, from B", but I at least you should have a better idea of what Metacello does do ...

> 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

> Hi Tobias,
>
>> 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
>
> Instead of having so many "releases" of Seaside, would it be possible
> to just have one SM entry for Seaside Base and then, as separate SM
> entries, Seaside Development, Fcgi, RSS, Email, jQuery, etc?  Each
> which would be smart enough to load Seaside Base automatically if it
> wasn't already.  Metacello is declarative so the users "feature
> selections" should be able to be made any time, regardless of the
> pre-state of the image.
>
> I understand a new release of "Seaside" may usually include changes to
> all of those "feature" packages but there is no way around that --
> it's just a few minutes of work per package.

>
>
> ----- Original Message -----
> | From: "Frank Shearar" <[hidden email]>
> | To: "The general-purpose Squeak developers list" <[hidden email]>
> | Sent: Thursday, March 7, 2013 1:51:48 PM
> | Subject: Re: [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)
> |
> | On 7 March 2013 21:20, Dale Henrichs <[hidden email]> wrote:
> |
> | > There are some basic rules that Metacello follows for loading packages:
> | >
> | >   1. If the specified package version is already loaded in the
> | >      image, nothing is done
> | >   2. If a later version of the package version is already loaded
> | >      in the image, nothing is done
> | >   3. If the specified package version is present in the package-cache,
> | >      the package is loaded from the package-cache
> | >   4. If the specified package version is found in one of the repositories
> | >      listed for the package or project (multiple repositories may be
> | >      specified) the package is loaded from the first repository it is found
> | >      in (search order of repositories is not guaranteed)
> | >   5. throw an error
> | >
> | > If one doesn't specify an explicit package version then the "latest version
> | > of the package" is loaded. The Gofer sort order for packages is used to
> | > determine "latest version". In this case, all of the associated
> | > repositories are unconditionally searched for the "latest version", but
> | > once the "latest version" is determined, the above listed rules are
> | > applied.
> | >
> | > If a package is dirty, a notification is raised and if handled one can
> | > choose to override the dirty package. The default action is to skip
> | > loading over dirty pacakages.
> | >
> | > The rules for loading configurations is similar to packages except for a
> | > couple of exceptions:
> | >
> | >   1. If the version being loaded is blessed as #development, then a new
> | >   copy
> | >      of the configuration is loaded from the repository.
> | >   2. If you request a version that is not present in the loaded
> | >   configuration,
> | >      then an attempt is made to load the latest version of the
> | >      configuration
> | >      package from the repositories associated with the configuration and
> | >      then
> | >      the version lookup is tried again.
> |
> | How does one specify the repositories in step 4? I know that a
> | ConfigurationOf can say "find these in this project on SS3", which
> | is... problematic. Well, it's fine as a _default_, but you need to be
> | able to override that. And I know there's #overrideRepositories: but I
> | thought that wasn't quite the thing that I was looking for?
> |
> | I realise I should know all this stuff already. My apologies for forgetting.
>
> Frank,
>
> I kinda figured that would be where you were going, but covering the basics is important ...
>
> I agree that "it's fine as a _default_", but to do so requires that one provide a means for managing the mapping between repositories and packages independent of the configuration. Without being present in a base image by default it is hard to provide such a mechanism:)
>
> The Metacello Scripting API has an independent project registry, where you can identify which repository should be used with which project. I'm still working through some issues so I haven't released the Scripting API into the wild, but I am looking at the next major release of Metacello to directly address your needs ...

>
> On Wed, Mar 6, 2013 at 6:21 PM, Dale Henrichs <[hidden email]> wrote:
>> Chris,
>>
>> I think that the officially correct script is the configuration ....
>>
>> Dale
>>
>> ----- Original Message -----
>> | From: "Chris Muller" <[hidden email]>
>> | To: "Dale Henrichs" <[hidden email]>
>> | Cc: "Seaside - general discussion" <[hidden email]>, "The general-purpose Squeak developers list"
>> | <[hidden email]>
>> | Sent: Tuesday, March 5, 2013 7:24:56 PM
>> | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3
>> |
>> | > to get a working one-click script recorded there that can do it.
>> |
>> | Not only just working, but the officially-correct script
>> |

> Hi Tobias, as I said before, I would like to replace my script with a
> proper Metacello script, but we just need one working.  But I do need
> to address some of your other points:
>
>> [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.
>
> "Declarative" is not a requirement.  The requirement is simply for
> fixed-configurations to _work_ in legacy releases of Squeak (and for
> head-configurations to support collaboration).  The SM entry does load
> explicit versions of required packages and projects, so I see no
> difference here in terms of a fixed-config consumption.

>
>> 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.
>
> Sure, the SM script could easily be changed to also fail, but that
> does not allow two independent projects that both require Grease to be
> easily consumed.

>
>> 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.
>
> *Code* is where the rubber meets the road, not an object model -- the
> install-script approach to SM is what allows a
> catalog-of-doing-anything, not just "installing packages".  Also the
> reality is that not everyone is going to bring Metacello into their
> life but they still need an outlet for Publishing their projects.  So
> we need something that is 1) simplistic, 2) tool-independent, and 3)
> totally flexible (can do things that Metacello hasn't even thought
> of).
>
> For projects that want to use Metacello, the load-script approach
> supports them too, of course.
>
>> 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:
>
> No, that is incorrect.  SM supports multiple different Releases for
> any package.  Any Release of one Package can depend on any other
> specific Release of any other Package defined within SqueakMap.
>
> For packages that choose to use Metacello, that structure could be
> defined there.
>
>>   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.
>
> One way to do it is with multiple Releases, where each "richer"
> release depends on the "blander" releases.
>
> Incidentally, one problem I have with Metacello is its opaqueness -- I
> can't easily look at a config and know what I'm going to get -- the
> word "Development" is not meaningful to me, I want to know what
> packages will be loaded.

>
>>> 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..
>
> But will it still work in 6 months?  One thing I've been trying to
> understand is why Metacello scripts not having longevity -- begin to
> fail after a short period of time.  If they "declare" explicit
> versions of every package this should not happen should it?

>
>>> 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.
>
> Great, thanks, so we just need a *one-click* script that doesn't
> require any manual downloading of other packages first.  The Seaside
> catalog entry is tagged Community Supported so even you or anyone
> could post it up there.
>
> I think if we could get SM entries tested by CI server, that would be
> a really great step.
>
>> [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:
>>
>
> This is unacceptable because it is too high a barrier for newbies.
> The "Consume" requirement demands it should just-work(tm) with
> one-click.