Hi again,

(late [again, I know, sorry] inline comments follow]

Am 06.03.2013 um 19:50 schrieb Chris Muller <asqueaker at gmail.com>:

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

Right. I am afraid I have to agree with this point. I, however, think
in terms of maintainability, a declarative way of specifying 
Software Configurations (what we are essentially talking about, no?)
clearly wins.

> 
>> 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 do you mean by 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.

It depends on perspective. I find a "description" of what will be loaded
more transparent than a code snippet that can do about just anything.
Other than that, this is just a tooling challenge. 
You can, for example, easily "simulate" an installation with Metacello.
If you #record instead of #load, you see which transitively required
Metacello projects would be loaded, and #fetch even gets all the
required Monticello versions for you without installing.
  I think this is even more transparent than an installation script;
you really know which versions you will end up with. :)

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

The releases I see in SqueakMap always seemed to me as individual, 
conceptually distinct "products" (though with inter-dependencies,
yes). I know it is possible to have multiple

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

Right. Dale intended the development model for Metacello Versions
quite open. The MetacelloRepository's out there (I think there are
3–4) are all world-writable. Not every developer is paying attention
to the quasi-rule that a released version of a Configuration
should not be touched. This had me bothering quite a few times, and this
is also the case why Seaside 3.0.7 isn't currently installing in Squeak 4.4
via the Configuration.

Dale, could you elaborate on stable versions?

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

> 
>>> 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:
>> 
> 
> This is unacceptable because it is too high a barrier for newbies.
> The "Consume" requirement demands it should just-work(tm) with
> one-click.

Sorry, I cannot follow. What is unacceptable to you here?

Since the last Squeak/Seaside one-click (that I built in
frustration, and wasn't fully functional, either, due
to a buggy OmniBrowser) both Seaside and Squeak evolved. 
How can we expect it to just work if nobody has a look at it?
Am I missing something fundamental here?


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

Well, my point here was to kind-of report an upstream fix, in this
case, the config for the yet unreleased Seaside 3.1 on Squeak 4.4.
I do think it is necessary to let the original Seaside developers
have a look at the configs. Also, I do not have write access
to the repository _these_ configurations belong to.

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

We need a person that constantly monitors the development of both?

> 
> Thanks for engaging this discussion.

The same goes to you.

Best
	-Tobias