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

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?

Best
	-Tobias