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