New catalog entry for Seaside 3.0.3

> Hi again Seasiders
>
>
> Anfang der weitergeleiteten Nachricht:
>
>> Von: Tobias Pape <[hidden email]>
>> Betreff: [Seaside] Making seaside load in Squeak again.
>> Datum: 26. Februar 2013 09:42:56 MEZ
>> An: Seaside - general discussion <[hidden email]>
>> Kopie: The general-purpose Squeak developers list <[hidden email]>
>> Antwort an: Seaside - general discussion <[hidden email]>
>>
>> Hey Seasiders
>>
>> I am trying to prepare a stable Seaside Image for Squeak 4.4
>> and just tried loading via the Metacello configuration
>> (Like this:
>>
>> Installer ss
>>       project: 'MetacelloRepository';
>>       install: 'ConfigurationOfSeaside30'.
>> ((Smalltalk at: #ConfigurationOfSeaside30 project) version: #stable) load
>>
>> )
>>
>> This fails, as there is a dependency on Zinc #stable in
>> #squeakCommon. Also, I think it is worthwhile to add WebCilent
>> to the Adaptors for, at least, Squeak, if not Pharo, too.
>>
>> I have seen that there is progress for that in the Seaside31 repository,
>> especially for the 3.1 version of Seaside.
>
> In my effort to see what I can do I succeeded in
> Running Seaside 3.1 atop Squeak 4.4 (I needed to bring an interim Grease 1.1.1 version for that)
>
> You load  [1]
>         http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
>         http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
> and then you can DoIt
>
> ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.1.0') load: #(Development OmniBrowser Swazoo WebClient Welcome).
> (Smalltalk at: #WAServerAdaptorBrowser) open
>
> in a fresh Squeak4.4-12327.
> (Then rightclick in the Seaside Control Panel and 'Add adaptor', a WebServer Adaptor,
> which uses WebClient. Then go to localhost:8080 and be happy.)
>
> Now I will try to work on Seaside 3.0.
>
>>>
> To any Seaside dev, please consider merging my versions :)
> <<
>
> Best
>         -Tobias
>
> [1] this is no MC repo, I just don't have access to the Seaside Repos and didn't want to pollute
>     any MetacelloRepository.

> Chris,
>
> 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...
>
> Your best bet is to add a Seaside build (using the Seaside configuration) to your CI server...then if you get failures, you can report the issues to the seaside maintainers and get quick resolution.
>
> There used to be regular builds on the Pharo CI server for Seaside, but the old links are no longer valid and I couldn't find any reference to Seaside on the new CI pages ...
>
> Dale
>
>
> ----- Original Message -----
> | From: "Chris Muller" <[hidden email]>
> | To: "The general-purpose Squeak developers list" <[hidden email]>, "Das Linux"
> | <[hidden email]>
> | Cc: "Seaside - general discussion" <[hidden email]>
> | Sent: Tuesday, February 26, 2013 6:50:09 PM
> | Subject: [squeak-dev] [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.
> |
> | 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.
> |
> | 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.  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?
> |
> | Best,
> |   Chris
> |
> |
> |
> | On Tue, Feb 26, 2013 at 7:29 AM, Tobias Pape <[hidden email]> wrote:
> | > Hi again Seasiders
> | >
> | >
> | > Anfang der weitergeleiteten Nachricht:
> | >
> | >> Von: Tobias Pape <[hidden email]>
> | >> Betreff: [Seaside] Making seaside load in Squeak again.
> | >> Datum: 26. Februar 2013 09:42:56 MEZ
> | >> An: Seaside - general discussion <[hidden email]>
> | >> Kopie: The general-purpose Squeak developers list
> | >> <[hidden email]>
> | >> Antwort an: Seaside - general discussion
> | >> <[hidden email]>
> | >>
> | >> Hey Seasiders
> | >>
> | >> I am trying to prepare a stable Seaside Image for Squeak 4.4
> | >> and just tried loading via the Metacello configuration
> | >> (Like this:
> | >>
> | >> Installer ss
> | >>       project: 'MetacelloRepository';
> | >>       install: 'ConfigurationOfSeaside30'.
> | >> ((Smalltalk at: #ConfigurationOfSeaside30 project) version: #stable) load
> | >>
> | >> )
> | >>
> | >> This fails, as there is a dependency on Zinc #stable in
> | >> #squeakCommon. Also, I think it is worthwhile to add WebCilent
> | >> to the Adaptors for, at least, Squeak, if not Pharo, too.
> | >>
> | >> I have seen that there is progress for that in the Seaside31 repository,
> | >> especially for the 3.1 version of Seaside.
> | >
> | > In my effort to see what I can do I succeeded in
> | > Running Seaside 3.1 atop Squeak 4.4 (I needed to bring an interim Grease
> | > 1.1.1 version for that)
> | >
> | > You load  [1]
> | >         http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
> | >         http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
> | > and then you can DoIt
> | >
> | > ((Smalltalk at: #ConfigurationOfSeaside30) project version: '3.1.0') load:
> | > #(Development OmniBrowser Swazoo WebClient Welcome).
> | > (Smalltalk at: #WAServerAdaptorBrowser) open
> | >
> | > in a fresh Squeak4.4-12327.
> | > (Then rightclick in the Seaside Control Panel and 'Add adaptor', a
> | > WebServer Adaptor,
> | > which uses WebClient. Then go to localhost:8080 and be happy.)
> | >
> | > Now I will try to work on Seaside 3.0.
> | >
> | >>>
> | > To any Seaside dev, please consider merging my versions :)
> | > <<
> | >
> | > Best
> | >         -Tobias
> | >
> | > [1] this is no MC repo, I just don't have access to the Seaside Repos and
> | > didn't want to pollute
> | >     any MetacelloRepository.
> | _______________________________________________
> | seaside mailing list
> | [hidden email]
> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> |
>

>
> Dale
>
> ----- Original Message -----
> | From: "Chris Muller" <[hidden email]>
> | To: "The general-purpose Squeak developers list" <[hidden email]>
> | Cc: "Seaside - general discussion" <[hidden email]>
> | Sent: Tuesday, March 5, 2013 2:30:02 PM
> | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3
> |
> | > (Smalltalk at: #WAServerAdaptorBrowser) open.
> | > (Smalltalk at: #WAPharoServerAdaptorBrowser) open.
> | > (Smalltalk at: #WAServerAdaptor) open.
> |
> | It may be you can't use that browser without OB which requires
> | OCompletion.  For a web-framework to require a fat-client UI framework
> | seems nutty to me.   :)
> |
> | But did you try working with Seaside itself, starting a server and
> | opening a browser on it?
> |
> | > However none works. A note in the SqueakMap entry would be appreciated.
> | >
> | > The note says: 'Seaside requires a web server; the most commonly used
> | > is KomHttpServer'.
> | >
> | > But there is no SqueakMap entry for that.
> |
> | Hm, check again, it's there.  Maybe you need to update your SM Cache
> | (via the "Update" button).
> | _______________________________________________
> | seaside mailing list
> | [hidden email]
> | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> |

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

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

> 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.
>
> (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.)
>
> 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"?
>
>> 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
>
> frank
>
>

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

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

> 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.
>
> We should avoid double implementation effort here.
>
> Can’t we make a SMMetacelloPackage?

> Am 06.03.2013 um 11:45 schrieb H. Hirzel <[hidden email]>:
>>> […]
>>> We should avoid double implementation effort here.
>>>
>>> Can’t we make a SMMetacelloPackage?
>>
>> Sounds good. What would that imply?
>
> Work and testing, I would say ;)
>
> Best
> -Tobias
>
>
>