New catalog entry for Seaside 3.0.3

Am 20.03.2013 um 10:46 schrieb "H. Hirzel" <[hidden email]>:

thanks.


Not an catalog entry but an updated Metacello-Configuration.
As I orignially laid out[1], I have not yet 3.0 loading in
4.4 but while chasing for the latest config, I saw that
the config seaside 3.1 is being updated and refactored,
and I noticed that it was easy to adapt.


Best
        -Tobias

[1] Message-Id: <[hidden email]>

Tobias

I could not follow the link you have given

[1] Message-Id: <[hidden email]>

Is it the following one?

Seaside, Squeak4.4, SqueakMap and Metacello, or Why Software
Configuration Management is Important (war: Re: [Seaside] New catalog
entry for Seaside 3.0.3)
http://lists.squeakfoundation.org/pipermail/seaside/2013-March/029511.html

--Hannes

On 3/20/13, Tobias Pape <[hidden email]> wrote:

Dear Hannes

Am 20.03.2013 um 11:55 schrieb "H. Hirzel" <[hidden email]>:

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

sorry, I, naïvely, thought message Ids would make searching
for Mails easy. That is not the case, apparently :/

Best
        -Tobias

Hi Tobias!

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?

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

----- Original Message -----
| From: "Chris Muller" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Thursday, March 21, 2013 9:33:49 AM
| Subject: Re: [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)
|
|
| 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?


Chris,

In Metacello you define versions of a project. For each version you specify the list of mcz files that make up the version and that list is qualified by platform.

So each version includes a specification of which platform versions are supported.

When you load version 3.0.7 of a project, you should get the same functionality without regard which platform you are using ....

A configuration contains the entire version history for a project ... so 5 years from now, if you try to load version 3.0.7 into Squeak4.4 it will load correctly (assuming that version 3.0.7 works in Squeak4.4 today) ...

The GLASS configuration that I use for Metacello allows me to use a single configuration that loads the correct code in GemStone/S 2.4.4.1 (from 3 years ago ... I started the Metacello project only 4 years ago) and GemStone/S 3.2 (a version that will be released this summer).

Metacello configurations are self-contained (and distributed). Metacello doesn't rely on a centralized data base of dependencies.

Metacello configurations are cross-platform: the same configuration can be used to load a particular version of a project on any platform that supports Metacello/Monticello...

Metacello is not magical. If developers don't maintain a configuration so that it works on all of the "supported" platforms then it will not work ... Maintenance activities for Squeak and Seaside has fallen off and the configuration for Squeak has degraded ...

Tobias has picked up the ball and is getting Seaside running on the newer versions of Squeak and as he figures out the formula, he records the information in the configuration ... this is how Metacello is _supposed_ to work:

  Developers with expertise on how things get loaded specify the dependencies
  and load order in a configuration for others to use.

Dale

On 21 March 2013 16:33, Chris Muller <[hidden email]> wrote:
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.

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

> In Metacello you define versions of a project. For each version you specify the list of mcz files that make up the version and that list is qualified by platform.

Good.  Now, if only binary resources (files) could also be included in
the package then there would be a basis for Metacello to be a serve as
a medium of app delivery..

> So each version includes a specification of which platform versions are supported.

Ok, that's good, just one clarification though:  Are the declared
platforms just #squeak, #pharo and #gemstone or actually specific
releases of those platforms such as #squeak4dot4, #pharo1dot4,
#pharo2dot0, etc.?

The Platforms evolve just like the Packages and, as you know, bit-rot
is one of the issues we want the catalog to avoid.  That's why the
catalog is designed to remember the valid *combinations* of
(Platform-Release) + (App-Release).

> When you load version 3.0.7 of a project, you should get the same functionality without regard which platform you are using ....
>
> A configuration contains the entire version history for a project ... so 5 years from now, if you try to load version 3.0.7 into Squeak4.4 it will load correctly (assuming that version 3.0.7 works in Squeak4.4 today) ...

So it's a fixed-configuration, that's good.  The primary catalog
requirement is to tell the newbie:

   which versions of which software packages will work on my shiny
newly-installed Squeak 4.1?
   (or Squeak4.4, or whatever release of Squeak he's running).

I don't know whether Metacello can do that but that's why we can just
document it in an external catalog to know.

> Metacello is not magical. If developers don't maintain a configuration so that it works on all of the "supported" platforms then it will not work ... Maintenance activities for Squeak and Seaside has fallen off and the configuration for Squeak has degraded ...

This is confusing language for me..  When you say "the configuration
for Squeak has degraded" you just mean Squeak has advanced to 4.4 but
the Seaside configuration remained fixed for Squeak 4.3 (or 4.2
whichever), is that right?  IOW, a fixed-configuration will never
"degrade" in terms of a legacy release of Squeak, right?  Once 3.0.7
config works in Squeak 4.4, it will forever work in Squeak 4.4 --
that's what you said above.  I hope so right because that's what I
want.

> Tobias has picked up the ball and is getting Seaside running on the newer versions of Squeak and as he figures out the formula, he records the information in the configuration ... this is how Metacello is _supposed_ to work:
>
>   Developers with expertise on how things get loaded specify the dependencies
>   and load order in a configuration for others to use.

Great, so Tobias please let me know when it's ready to go one-click in
the catalog without needing those two orphan versions manually loaded
first.

On 21 March 2013 19:23, Chris Muller <[hidden email]> wrote:
Yes, and yes. Metacello has platforms like #squeak but also has
platforms like #'squeak4.4'. But of course if you only say #squeak
then your users have a problem.

I think what Dale's talking about is that there's nothing stopping
someone monkeying around with an old configuration. Specifically, your
ConfigurationOf will typically have methods like #version11:.,
#version12: and so on. These pull in baselines - abstract dependency
graphs - and add versioning info. Baselines are often shared, because
the rate of change of the dependency graph is usually very much lower
than the rate of change in version numbers. But there's nothing
stopping someone writing a ConfigurationOf that's not pinned to a
platform version - Squeak 4.4, rather than "generic Squeak" - or from
altering #version11: while ostensibly preparing #version13:. You
really, really shouldn't do that kind of thing, but it's possible, so
people do make these kinds of changes (whether intended or by
accident).

>> Tobias has picked up the ball and is getting Seaside running on the newer versions of Squeak and as he figures out the formula, he records the information in the configuration ... this is how Metacello is _supposed_ to work:
>>
>>   Developers with expertise on how things get loaded specify the dependencies
>>   and load order in a configuration for others to use.
>
> Great, so Tobias please let me know when it's ready to go one-click in
> the catalog without needing those two orphan versions manually loaded
> first.

frank

Am 21.03.2013 um 17:33 schrieb Chris Muller <[hidden email]>:

Pretty much, yes.

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

My main requirement is to allow for the complexity of
Software Configuration Management and to not make it and its maintenance
more complex than necessary. Let's go for the overlapping part :)

> Do Metacello configurations declare which specific release of Squeak
> that configuration is for?  […answered by Dale, I hope]
 
>
>>>
>>> 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.
Ok. But you won't detect the case of the two projects requiring
conflicting versions of Grease, either. :/

[footnote]
The metacello versions do just that; please see, for example,
version 3.0-rc.2 of SqueakSource which I put at the end of that mail.
Every version is spelled out.

I am on that path. :)

Yes, but that email was not intended for newbies or even as an announcement
that software would be released.
  That email just said that I got an _unreleased_ version of Seaside
to work on Squeak and that the Interested Reader can try that out.

In the default—release—case, Metacello is one-click in the sense of
requirement 3. That is one of the cornerstones of Metacello, actually.

What I presented was development work, just a progress report.

I like that we aregee.

Exactly.
And following up http://forum.world.st/Seaside-on-Squeak-td4677482.html
I will go on and make a 3.0.7.2 (which will be fixed forever when released)
of seaside that works with Squeak 4.4.

Best
        -Tobias

[footnote]
> http://wiki.squeak.org/squeak/6183
can we have easy-to-read urls for the swiki, please?

[Appendix]
version30rc2: spec
        <version: '3.0-rc.2' imports: #( '3.0-rc.1.1-baseline')>

        spec for: #'common' do: [
                spec blessing: #'development'.
                spec description: 'open 3.0-rc.2 for development
3.0-rc.2 (dkh.77):
- pick up latest from tobias
- edits to allow image save before creating an installation'.
                spec author: 'dkh'.
                spec timestamp: '12/23/2011 16:13'.
                spec
                        project: 'Seaside-REST' with: '0.22';
                        project: 'Seaside Extras' with: '3.0.6.2';
                        project: 'Magritte2 Seaside' with: '2.0.6.2';
                        project: 'Gravatar' with: '1.0'.
                spec
                        package: 'SqueakSource-Core' with: 'SqueakSource-Core-dkh.78';
                        package: 'SqueakSource-Monticello-Core' with: 'SqueakSource-Monticello-Core-topa.5';
                        package: 'SqueakSource-Issues' with: 'SqueakSource-Issues-topa.10';
                        package: 'SqueakSource-Statistics' with: 'SqueakSource-Statistics-dkh.11';
                        package: 'SqueakSource-Storage-Core' with: 'SqueakSource-Storage-Core-topa.6';
                        package: 'SqueakSource-Storage-Dictionary' with: 'SqueakSource-Storage-Dictionary-topa.10';
                        package: 'SqueakSource-Storage-FileSystem' with: 'SqueakSource-Storage-FileSystem-topa.10';
                        package: 'SqueakSource-Subscription-Core' with: 'SqueakSource-Subscription-Core-topa.9';
                        package: 'SqueakSource-Subscription-Email' with: 'SqueakSource-Subscription-Email-topa.11';
                        package: 'SqueakSource-Tests' with: 'SqueakSource-Tests-topa.14';
                        package: 'SqueakSource-Gravatar' with: 'SqueakSource-Gravatar-topa.4';
                        package: 'TinyWiki' with: 'TinyWiki-lr.18'. ].

        spec for: #'squeakCommon' do: [
                spec project: 'SmaCC' with: '0.1'.
                spec
                        package: 'SqueakSource-SqueakPharo-Core' with: 'SqueakSource-SqueakPharo-Core-topa.5';
                        package: 'SqueakSource-SqueakPharo-Monticello' with: 'SqueakSource-SqueakPharo-Monticello-topa.3';
                        package: 'SqueakSource-SqueakPharo-Statistics' with: 'SqueakSource-SqueakPharo-Statistics-dkh.3';
                        package: 'SqueakSource-SqueakPharo-Storage-Core' with: 'SqueakSource-SqueakPharo-Storage-Core-topa.4';
                        package: 'SqueakSource-SqueakPharo-Subscription-Core' with: 'SqueakSource-SqueakPharo-Subscription-Core-dkh.6'. ].

        spec for: #'gemstone' do: [
                spec
                        project: 'Seaside Service Task' with: '3.0.6.2';
                        project: 'GsCore' with: '0.245';
                        project: 'Monticello' with: '0.241';
                        project: 'SmaCC' with: '0.239.1'.
                spec
                        package: 'SqueakSource-GemStone-Core' with: 'SqueakSource-GemStone-Core-topa.10';
                        package: 'SqueakSource-GemStone-Monticello' with: 'SqueakSource-GemStone-Monticello-topa.1';
                        package: 'SqueakSource-GemStone-Storage-Core' with: 'SqueakSource-GemStone-Storage-Core-topa.6';
                        package: 'SqueakSource-GemStone-Statistics' with: 'SqueakSource-GemStone-Statistics-dkh.6';
                        package: 'SqueakSource-GemStone-Subscription-Core' with: 'SqueakSource-GemStone-Subscription-Core-topa.2';
                        package: 'MonticelloConfigurations' with: 'MonticelloConfigurations.g-dkh.48'. ].

[…]
[Appendix]
> version30rc2: spec
> <version: '3.0-rc.2' imports: #( '3.0-rc.1.1-baseline')>
>
> spec for: #'common' do: [
> spec blessing: #'development'.

side note: this #development blessing
essentially asserts that this version might change.

a blessing of #release asserts that this method
should not be changed ever after.

Best
        -tobias

Good post.  Just one or two more comments (see below).

>> 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.
>
> My main requirement is to allow for the complexity of
> Software Configuration Management and to not make it and its maintenance
> more complex than necessary. Let's go for the overlapping part :)

Yes agree.  Publishing should be easy as much as Consume should.

>>>> 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.
> Ok. But you won't detect the case of the two projects requiring
> conflicting versions of Grease, either. :/

My thought is, an application that requires two projects both
requiring Grease, all running in one image is going to be a
complex-enough situation to warrant human attention in any case.  An
imperative script could certainly check for specific versions but I
question whether producing an eager error about that is useful.  Why
not just "merge" and let it go.  Perhaps a method conflict will force
an alert to the human configurator about the discrepency but, even if
not, such a complex image is not going to get very far without some
setup and testing, so "discovery" about the Grease situation in short
course seems inevitable.

That could even be turned around 180 and still say, maybe the
differences in the two Grease versions were just one little method
comment and so, no effective difference.  So the happy-go-lucky newbie
is no worse off and was not stopped by a message that was essentially
not necessary in that particular case.

I think my positions are motivated by late-binding philosophy and so
maybe that's why I tend to be skeptical about declarative things.  I
certainly agree the declarative nature of Monticello code is a
very-good-thing; and it feels logical to extend that into
larger-grained configuration declarations.  I just want to make sure
it serves us more than we have to serve it.

Thanks for the fun discussion, it makes me think.

 - Chris