[squeak-dev] Seaside, Squeak4.4, SqueakMap and Metacello, or Why Software Configuration Management is Important (war: Re: [Seaside] New catalog entry for Seaside 3.0.3)

Chris Muller asqueaker at gmail.com
Thu Mar 21 16:33:49 UTC 2013


Hi Tobias!

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

By declarative, I assume you mean a list of specific versions of
specific packages to run in a specific release of Squeak (a.k.a., a
"fixed-configuration").  I don't know how to be anymore declarative
than that.

My main requirement is for any newbie, or an archaeologist from the
future, to be able to figure out how to install a working piece of
software without having to ask questions on the mailing list.

Do Metacello configurations declare which specific release of Squeak
that configuration is for?  If so, then I think it is nearly
equivalent to what SqueakMap offers in terms of the promise of a
stable configuration that will work for years to come.  If not, then I
think that is a significant shortcoming to using Metacello to meet my
requirement.  One could make a fixed-configuration that works for
Squeak 4.4 today, but will someone remember that fixed-config is for
Squeak 4.4, 5 years from now when Squeak 5.5 is the current?  Or is it
back to trolling through the mailing lists to figure it out?

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

Installing and using a piece of software.

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

So, requirement #13 at:

  http://wiki.squeak.org/squeak/6183

is:

   "13.  Must be able to browse code before installing it, as a
security measure."

So it is not just about "knowing what I'm going to get" but also being
able to *easily* review and even debug the installation process.  I
suppose this would be possible with Metacello configs too, just not as
easy as a straight script which spells out the exact versions of every
package you'll get.


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

Ok, Seaside is classic, signature Squeak software so I hope we'll have
3.0.7 working again.

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

That requirement 3 is not met.

  "3. Installation must occur with one-click, including all
prerequisite packages."

Because there were two pre-req packages that needed to be manually
downloaded first.  As you said here:

http://forum.world.st/Making-seaside-load-in-Squeak-again-td4672155.html#a4672205

No newbie coming into the community to check out Seaside is going to
know this, it'll just be "broken" for him.


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

Nope.  The only things we can expect to work are fixed-configurations
that someone had put attention to in the past.  Whenever new version
of Seaside or Squeak comes out, same attention must be paid to create
another fixed-config for that version that will have longevity.

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

If there is sufficient interest in Seaside going forward, someone will
do it.  If not, they won't, but at least we will still always have
fixed-configurations working in older Squeak's.  If sufficient
interest materializes in teh future, those fixed-configs are a good
place to start to make a newer working version.

Best,
  Chris


More information about the Squeak-dev mailing list