On 21 March 2013 16:33, Chris Muller <asqueaker at gmail.com> wrote:
> 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.

Metacello asserts that a package consists of a number of versioned
subparts. An Installer script is an imperative do-this-then-that
script.

Ideally Metacello could say "oh you already have Foo-fbs.22 installed,
I'll skip loading that", and thus be idempotent. (It might actually do
this, to be honest.) "Idempotent" as in your class initializers will
not rerun.

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

Yes... if properly written.

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

Sort've. An Installer script gives you no assurance that your
configuration will work, because you need to pin versions. Or, if you
_don't_ write your Installer script with pinned versions, SM neither
knows nor cares.

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

This is probably the main problem. ReleaseBuilder suffers from the
same problem. The specs aren't immutable, and can't be, since they're
just code carried around in the ConfigurationOf.

However, there is a solution: git. In particular, the ConfigurationOf
only ever carries the current package specification. If you want a
particular ConfigurationOf, you say (blow own horn here)

    (Installer github
        user: 'frankshearar' repository: 'Zippers' commitId: '1.2') install

where the repo has a tag '1.2' marking a particular commit. In other
words, you drive the versioning of scripts right out of the code into
the version control system.

frank

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