Thank you for the good and helpful discussion in this thread. And in
particular Tobias for taking the time to write a long initial mail
which explains the issues well.

I'd like to summarize:

- SqueakMap entries should makes use fo Metacello (i.e. loading
ConfigurationOfABC classes) as much as possible.
- There might be several SqueakMap entries, e.g. SeasideDevelopment
and SeasideBase.

Is this correct? Which points should be added?

--Hannes


On 3/6/13, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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.
>
> (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
>
>