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.

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

Yes you can, with multiple releases.  See Magma on SqueakMap for an
example.  Magma-Server is optional.

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

Look, I have nothing against Metacello, I just want the basic Consume
and Publish requirements to be met.  My perception is that this is a
ongoing problem when new "How do I load XYZ?" discussions keep popping
up.

>> 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:
>
>>>
>>> You load  [1]
>>>        http://netshed.de/seaside/ConfigurationOfGrease-topa.191.mcz
>>>        http://netshed.de/seaside/ConfigurationOfSeaside30-topa.415.mcz
>>> […]

This is unacceptable because it is too high a barrier for newbies.
The "Consume" requirement demands it should just-work(tm) with
one-click.

> ===========>
>>> To any Seaside dev, please consider merging my versions :)
> <==========

Hence we're back to the original question -- we're begging "any
Seaside dev" (who is that?  Philip?) without knowing whether Squeak
needs to take its own initiative.  To repeat myself:

(I wrote:)
>>  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?

Thanks for engaging this discussion.

 - Chris