If a kind soul can get one working, I'll make sure it stays working with the magic of CI on build.squeak.org. Er, that means that I'm not sure whether Chris reported _working_ configurations.

Hi, that Seaside configuration should "work". I did not run the tests (don't know how) but I was able to start a server and build a rudimentary page using one of the ajax frameworks that rendered and accepted input..

My question was geared more toward the future of Seaside with Squeak. Tobias produced a working Metacello script but it required two .mcz's to be loaded first. But what repository are those available from so they can be installed directly into the image? Those links he provided are not a MC Repository so, to install Seaside, my understanding is someone must manually download them to their local computer, install them one by one, _then_ execute the Metacello script. Clearly, the Consume use-case is not satisfied but how can we rectify that? I don't have access to the Seaside repositories to copy those mcz's into it, so do we need a separate repository for them and future Squeak-specific packages?

For now, I just published the stable-baseline I have for a Seaside 3.0. My curiosity about what caused some of the previously-working Metacello scripts to stop working is for a root-cause analysis to know whether we could normally meet that "working baseline" requirement on-going or whether it was just a one-off issue?

I think acting on Dales's suggestion will force these questions too, so a great place to start.

Hello On 3/1/13, Chris Muller ma.chris.m@gmail.com wrote:

...

If a kind soul can get one working, I'll make sure it stays working with the magic of CI on build.squeak.org. Er, that means that I'm not sure whether Chris reported _working_ configurations.

Hi, that Seaside configuration should "work". I did not run the tests (don't know how) but I was able to start a server and build a rudimentary page using one of the ajax frameworks that rendered and accepted input..

Thank you Tobias for coming up with a Seaside configuration which loads fine and Chris for the SqueakMap entry.

I loaded Seaside from SqueakMap into a pristing Squeak4.4 image. One click on the Seaside entry. I did not load any prerequisites.

Now my question: How do I start it?

It used to be something of the following

(Smalltalk at: #WAServerAdaptorBrowser) open. (Smalltalk at: #WAPharoServerAdaptorBrowser) open. (Smalltalk at: #WAServerAdaptor) open.

However none works. A note in the SqueakMap entry would be appreciated.

The note says: 'Seaside requires a web server; the most commonly used is KomHttpServer'.

But there is no SqueakMap entry for that.

Then later let's move on to a SqueakCI job for this.

Regards Hannes

On Tue, Mar 5, 2013 at 2:30 PM, Chris Muller asqueaker@gmail.com wrote:

...

(Smalltalk at: #WAServerAdaptorBrowser) open. (Smalltalk at: #WAPharoServerAdaptorBrowser) open. (Smalltalk at: #WAServerAdaptor) open.

It may be you can't use that browser without OB which requires OCompletion. For a web-framework to require a fat-client UI framework seems nutty to me. :)

Well, to be fair, Seaside's browser doesn't require all that. It just requires the main OB framework, plus a few platform-specific packages. If it wants to install OCompletion, it's a fault of the load-script, not Seaside or OmniBrowser.

Colin

Nutty or not, the default installation of Seaside includes a dependency upon OmniBrowser (for starting and stopping the seaside server), plus a web server (used to be Kom and recently has moved to Zinc) ... the configuration describes all of the dependencies. The default configuration load includes just about everything that a developer might need to get up and running Seaside ...

If you want to duplicate the information from the configuration in SqueakMap, then I suggest you take a look at the configuration itself....

Ok, I have not kept up with Seaside, I don't even know what a ServerAdaptorBrowser is. I thought if it is server-console UI, then whether the dependency could be reversed to be more conventional where the UI stuff depends on the core web engine.

In any case Squeak needs Seaside in its catalog and I would just like to get a working one-click script recorded there that can do it.

Dale

----- Original Message ----- | From: "Chris Muller" asqueaker@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Cc: "Seaside - general discussion" seaside@lists.squeakfoundation.org | Sent: Tuesday, March 5, 2013 2:30:02 PM | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3 | | > (Smalltalk at: #WAServerAdaptorBrowser) open. | > (Smalltalk at: #WAPharoServerAdaptorBrowser) open. | > (Smalltalk at: #WAServerAdaptor) open. | | It may be you can't use that browser without OB which requires | OCompletion. For a web-framework to require a fat-client UI framework | seems nutty to me. :) | | But did you try working with Seaside itself, starting a server and | opening a browser on it? | | > However none works. A note in the SqueakMap entry would be appreciated. | > | > The note says: 'Seaside requires a web server; the most commonly used | > is KomHttpServer'. | > | > But there is no SqueakMap entry for that. | | Hm, check again, it's there. Maybe you need to update your SM Cache | (via the "Update" button). | _______________________________________________ | seaside mailing list | seaside@lists.squeakfoundation.org | http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |

Chris,

I think that the officially correct script is the configuration ....

Dale

----- Original Message ----- | From: "Chris Muller" ma.chris.m@gmail.com | To: "Dale Henrichs" dhenrich@vmware.com | Cc: "Seaside - general discussion" seaside@lists.squeakfoundation.org, "The general-purpose Squeak developers list" | squeak-dev@lists.squeakfoundation.org | Sent: Tuesday, March 5, 2013 7:24:56 PM | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3 | | > to get a working one-click script recorded there that can do it. | | Not only just working, but the officially-correct script |

Sorry for not replying,

I was quite busy lately, alas, not with Squeak/Seaside.

Am 07.03.2013 um 03:00 schrieb Chris Muller ma.chris.m@gmail.com:

Yes, I completely agree. After Tobias' configurations are committed to the Seaside repository we'll be able to have the official version in SM.

The configurations I had done concern Seaside 3.1, not 3.0.7 (iirc it it the latest release). I would have to adapt the 3.0 Configuration of the main repository. Please give me some time for that.

Best -Tobias

On Wed, Mar 6, 2013 at 6:21 PM, Dale Henrichs dhenrich@vmware.com wrote:

...

Chris,

I think that the officially correct script is the configuration ....

Dale

----- Original Message ----- | From: "Chris Muller" ma.chris.m@gmail.com | To: "Dale Henrichs" dhenrich@vmware.com | Cc: "Seaside - general discussion" seaside@lists.squeakfoundation.org, "The general-purpose Squeak developers list" | squeak-dev@lists.squeakfoundation.org | Sent: Tuesday, March 5, 2013 7:24:56 PM | Subject: Re: [squeak-dev] [Seaside] New catalog entry for Seaside 3.0.3 | | > to get a working one-click script recorded there that can do it. | | Not only just working, but the officially-correct script |

Am 20.03.2013 um 10:46 schrieb "H. Hirzel" hannes.hirzel@gmail.com:

Hello Tobias,

On 3/20/13, Tobias Pape Das.Linux@gmx.de wrote:

...

Sorry for not replying,

I was quite busy lately, alas, not with Squeak/Seaside.

As I am concerned I do not mind at all. You worked on this 3 weeks ago and what you are doing is very helpful for my work. As this is all volunteer work this is not so much an issue if something is not being worked on for three weeks. What counts is that work _is_ done and that it is quality work.

thanks.

...

Am 07.03.2013 um 03:00 schrieb Chris Muller ma.chris.m@gmail.com:

...

Yes, I completely agree. After Tobias' configurations are committed to the Seaside repository we'll be able to have the official version in SM.

The configurations I had done concern Seaside 3.1,

You mean you have done an entry for Seaside 3.1 on Squeak 4.4?

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: 36A5BA15-D00F-4C7C-A1CD-3B9382D927BC@gmx.de

Dear Hannes

Am 20.03.2013 um 11:55 schrieb "H. Hirzel" hannes.hirzel@gmail.com:

Tobias

I could not follow the link you have given

[1] Message-Id: 36A5BA15-D00F-4C7C-A1CD-3B9382D927BC@gmx.de

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

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

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

Best -Tobias

On 6 March 2013 09:30, Tobias Pape Das.Linux@gmx.de wrote:

Hi All,

as this thread continues, and I have some cross-post replies, I reply to the initial post here, hope you don't mind.

• For SqueakMap things goto [SQMP] • Seaside-Developers, please read [SEAS] • For Metacello-stuff please goto [MTCL]

Am 27.02.2013 um 03:50 schrieb Chris Muller asqueaker@gmail.com:

...

Hi Tobias, I made new Community-Supported catalog entries for:

DynamicBindings ("4.4" and "head") KomHttpServer ("4.4") Grease ("1.1.0" and "head") Sport (already up-to-date, no action taken) Seaside ("3.0.3")

These each consume with single-click (necessary pre-reqs are loaded automatically for each package). Installing the head versions always perform a merge, similar to updating trunk packages.

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

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.

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.

There's nothing stopping a package maintainer using Metacello. Perhaps when Chris & I nag people to make an SM catalog entry we should nag them to add a ConfigurationOf.

(I used to have a ConfigurationOfControl; I changed it to an Installer script because the time it took to load Metacello and friends completely dwarfed the time it took to load Control. Control is tiny and has no dependencies outside a standard image.)

Or do you mean that SM should expose more of what Metacello does, say by allowing a _user_ (as opposed to my previous multiple-special-versions) to say "I want Seaside 3.0.3, and I see it has multiple profiles; I'd like the release one please"?

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

You (the package maintainer, not necessarily you, Tobias) could always have multiple releases - (4.4 development), (4.4 release), etc. - for a package. Each of these would have a load script calling ConfigurationOfFoo

frank

Am 06.03.2013 um 11:09 schrieb Frank Shearar frank.shearar@gmail.com:

On 6 March 2013 09:30, Tobias Pape Das.Linux@gmx.de wrote:

...

Hi All,

as this thread continues, and I have some cross-post replies, I reply to the initial post here, hope you don't mind.

• For SqueakMap things goto [SQMP] • Seaside-Developers, please read [SEAS] • For Metacello-stuff please goto [MTCL]

Am 27.02.2013 um 03:50 schrieb Chris Muller asqueaker@gmail.com:

...

Hi Tobias, I made new Community-Supported catalog entries for:

DynamicBindings ("4.4" and "head") KomHttpServer ("4.4") Grease ("1.1.0" and "head") Sport (already up-to-date, no action taken) Seaside ("3.0.3")

These each consume with single-click (necessary pre-reqs are loaded automatically for each package). Installing the head versions always perform a merge, similar to updating trunk packages.

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

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.

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.

There's nothing stopping a package maintainer using Metacello. Perhaps when Chris & I nag people to make an SM catalog entry we should nag them to add a ConfigurationOf.

Yes, I think this would be great.

(I used to have a ConfigurationOfControl; I changed it to an Installer script because the time it took to load Metacello and friends completely dwarfed the time it took to load Control. Control is tiny and has no dependencies outside a standard image.)

Did you happen to have Metacello installed before loading the Config? Other than that, I would like to see the config :)

Or do you mean that SM should expose more of what Metacello does, say by allowing a _user_ (as opposed to my previous multiple-special-versions) to say "I want Seaside 3.0.3, and I see it has multiple profiles; I'd like the release one please"?

Kind of like that. I could expose the versions and groups. There is even the possibility to collect the #stable, #development and #bleedingEdge markings.

...

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

You (the package maintainer, not necessarily you, Tobias) could always have multiple releases - (4.4 development), (4.4 release), etc. - for a package. Each of these would have a load script calling ConfigurationOfFoo

Yes this would be possible. I have two major problems with such an approach:

1) It is still imperative and you have to manually synchronize the SqueakMap releases with the Metacello configurations. Say, Seaside in 3.0.3 with all its glory is on SqueakMap as about 61 releases. (why so much? see 2) ) When you want to have a 3.0.4 release you have to make 12 new release for 3.0.4. Really?

2) It is not the simple case that there are just 2 releases, say development and deployment, it is more like Feature selection, however this leads to release explosion. I will now, just from memory try to recall possible combination that in this scenario would qualify as an independent release:

• Seaside 3.0.3 Base • Seaside 3.0.3 Base, Comanche • Seaside 3.0.3 Base, Fcgi • Seaside 3.0.3 Base, RSS • Seaside 3.0.3 Base, Email • Seaside 3.0.3 Base, Scriptatcoulus • Seaside 3.0.3 Base, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi • Seaside 3.0.3 Base, Comanche, RSS • Seaside 3.0.3 Base, Comanche, Email • Seaside 3.0.3 Base, Comanche, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS • Seaside 3.0.3 Base, Comanche, Fcgi, Email • Seaside 3.0.3 Base, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Base, Fcgi, RSS • Seaside 3.0.3 Base, Fcgi, Email • Seaside 3.0.3 Base, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email • Seaside 3.0.3 Base, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development • Seaside 3.0.3 Development, Comanche • Seaside 3.0.3 Development, Fcgi • Seaside 3.0.3 Development, RSS • Seaside 3.0.3 Development, Email • Seaside 3.0.3 Development, Scriptatcoulus • Seaside 3.0.3 Development, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi • Seaside 3.0.3 Development, Comanche, RSS • Seaside 3.0.3 Development, Comanche, Email • Seaside 3.0.3 Development, Comanche, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS • Seaside 3.0.3 Development, Comanche, Fcgi, Email • Seaside 3.0.3 Development, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development, Fcgi, RSS • Seaside 3.0.3 Development, Fcgi, Email • Seaside 3.0.3 Development, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email • Seaside 3.0.3 Development, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 One-click

[this is not exhaustive …]

I hope you understand that I do not want to make 61+ individual releases.

We should avoid double implementation effort here.

Can’t we make a SMMetacelloPackage?

Best -Tobias

Am 06.03.2013 um 11:45 schrieb H. Hirzel hannes.hirzel@gmail.com:

...

[…] We should avoid double implementation effort here.

Can’t we make a SMMetacelloPackage?

Sounds good. What would that imply?

Work and testing, I would say ;)

Best -Tobias

On 6 March 2013 10:39, Tobias Pape Das.Linux@gmx.de wrote:

Am 06.03.2013 um 11:09 schrieb Frank Shearar frank.shearar@gmail.com:

...

On 6 March 2013 09:30, Tobias Pape Das.Linux@gmx.de wrote:

...

Hi All,

as this thread continues, and I have some cross-post replies, I reply to the initial post here, hope you don't mind.

• For SqueakMap things goto [SQMP] • Seaside-Developers, please read [SEAS] • For Metacello-stuff please goto [MTCL]

Am 27.02.2013 um 03:50 schrieb Chris Muller asqueaker@gmail.com:

...

Hi Tobias, I made new Community-Supported catalog entries for:

DynamicBindings ("4.4" and "head") KomHttpServer ("4.4") Grease ("1.1.0" and "head") Sport (already up-to-date, no action taken) Seaside ("3.0.3")

These each consume with single-click (necessary pre-reqs are loaded automatically for each package). Installing the head versions always perform a merge, similar to updating trunk packages.

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

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.

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.

There's nothing stopping a package maintainer using Metacello. Perhaps when Chris & I nag people to make an SM catalog entry we should nag them to add a ConfigurationOf.

Yes, I think this would be great.

...

(I used to have a ConfigurationOfControl; I changed it to an Installer script because the time it took to load Metacello and friends completely dwarfed the time it took to load Control. Control is tiny and has no dependencies outside a standard image.)

Did you happen to have Metacello installed before loading the Config? Other than that, I would like to see the config :)

...

Or do you mean that SM should expose more of what Metacello does, say by allowing a _user_ (as opposed to my previous multiple-special-versions) to say "I want Seaside 3.0.3, and I see it has multiple profiles; I'd like the release one please"?

Kind of like that. I could expose the versions and groups. There is even the possibility to collect the #stable, #development and #bleedingEdge markings.

...

...

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

You (the package maintainer, not necessarily you, Tobias) could always have multiple releases - (4.4 development), (4.4 release), etc. - for a package. Each of these would have a load script calling ConfigurationOfFoo

Yes this would be possible. I have two major problems with such an approach:

1. It is still imperative and you have to manually synchronize the

SqueakMap releases with the Metacello configurations. Say, Seaside in 3.0.3 with all its glory is on SqueakMap as about 61 releases. (why so much? see 2) ) When you want to have a 3.0.4 release you have to make 12 new release for 3.0.4. Really?

Well, leaving aside Seaside, which is a very complicated example, "imperative" seems a bit of a misnomer. Let's say I reverse my decision and use a ConfigurationOf in my Control load script. There's no difference between

Installer squeakmap update; install: 'Control (head)'

and

Installer ss3 project: 'Control'; install: 'ConfigurationOfControl'.

(Smalltalk at: #ConfigurationOfControl) loadDevelopment

There is a crucial difference in the general sense, which is that a ConfigurationOf allows you to track dependencies, including transitive ones. That is a massive win, and swamps the relatively minor issues I have with Metacello (like hard-coding where to get one's mcz files).

2. It is not the simple case that there are just 2 releases, say development

and deployment, it is more like Feature selection, however this leads to release explosion. I will now, just from memory try to recall possible combination that in this scenario would qualify as an independent release:

• Seaside 3.0.3 Base • Seaside 3.0.3 Base, Comanche • Seaside 3.0.3 Base, Fcgi • Seaside 3.0.3 Base, RSS • Seaside 3.0.3 Base, Email • Seaside 3.0.3 Base, Scriptatcoulus • Seaside 3.0.3 Base, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi • Seaside 3.0.3 Base, Comanche, RSS • Seaside 3.0.3 Base, Comanche, Email • Seaside 3.0.3 Base, Comanche, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS • Seaside 3.0.3 Base, Comanche, Fcgi, Email • Seaside 3.0.3 Base, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Base, Fcgi, RSS • Seaside 3.0.3 Base, Fcgi, Email • Seaside 3.0.3 Base, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email • Seaside 3.0.3 Base, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development • Seaside 3.0.3 Development, Comanche • Seaside 3.0.3 Development, Fcgi • Seaside 3.0.3 Development, RSS • Seaside 3.0.3 Development, Email • Seaside 3.0.3 Development, Scriptatcoulus • Seaside 3.0.3 Development, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi • Seaside 3.0.3 Development, Comanche, RSS • Seaside 3.0.3 Development, Comanche, Email • Seaside 3.0.3 Development, Comanche, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS • Seaside 3.0.3 Development, Comanche, Fcgi, Email • Seaside 3.0.3 Development, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development, Fcgi, RSS • Seaside 3.0.3 Development, Fcgi, Email • Seaside 3.0.3 Development, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email • Seaside 3.0.3 Development, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 One-click

[this is not exhaustive …]

I hope you understand that I do not want to make 61+ individual releases.

Well, we should expose in SM precisely the same number of releases as Seaside does. It sounds like what you're saying is that when I say "I have Seaside 3.0.3" you don't actually have any idea what I actually have - do I have RSS loaded? Do I use Comanche or Zinc or KomHttpServer? Do I have Email loaded? And so on.

We should avoid double implementation effort here.

Can’t we make a SMMetacelloPackage?

I'm not sure what this would be?

frank

Best -Tobias

On 6 March 2013 15:26, Tobias Pape Das.Linux@gmx.de wrote:

Am 06.03.2013 um 13:31 schrieb Frank Shearar frank.shearar@gmail.com:

...

On 6 March 2013 10:39, Tobias Pape Das.Linux@gmx.de wrote:

...

Am 06.03.2013 um 11:09 schrieb Frank Shearar frank.shearar@gmail.com:

...

On 6 March 2013 09:30, Tobias Pape Das.Linux@gmx.de wrote:

There's nothing stopping a package maintainer using Metacello. Perhaps when Chris & I nag people to make an SM catalog entry we should nag them to add a ConfigurationOf.

Yes, I think this would be great.

...

(I used to have a ConfigurationOfControl; I changed it to an Installer script because the time it took to load Metacello and friends completely dwarfed the time it took to load Control. Control is tiny and has no dependencies outside a standard image.)

Did you happen to have Metacello installed before loading the Config? Other than that, I would like to see the config :)

...

Or do you mean that SM should expose more of what Metacello does, say by allowing a _user_ (as opposed to my previous multiple-special-versions) to say "I want Seaside 3.0.3, and I see it has multiple profiles; I'd like the release one please"?

Kind of like that. I could expose the versions and groups. There is even the possibility to collect the #stable, #development and #bleedingEdge markings.

...

You (the package maintainer, not necessarily you, Tobias) could always have multiple releases - (4.4 development), (4.4 release), etc. - for a package. Each of these would have a load script calling ConfigurationOfFoo

Yes this would be possible. I have two major problems with such an approach:

1. It is still imperative and you have to manually synchronize the

SqueakMap releases with the Metacello configurations. Say, Seaside in 3.0.3 with all its glory is on SqueakMap as about 61 releases. (why so much? see 2) ) When you want to have a 3.0.4 release you have to make 12 new release for 3.0.4. Really?

Well, leaving aside Seaside, which is a very complicated example, "imperative" seems a bit of a misnomer. Let's say I reverse my decision and use a ConfigurationOf in my Control load script. There's no difference between

Installer squeakmap update; install: 'Control (head)'

and

Installer ss3 project: 'Control'; install: 'ConfigurationOfControl'.

(Smalltalk at: #ConfigurationOfControl) loadDevelopment

Well, undoubtedly, the invocation of the installation is an “imperative” thing whenever code is involved :)

But the script behind 'Control (head)' is imperative while the specification in ConfigurationOfControl is declarative.

...

There is a crucial difference in the general sense, which is that a ConfigurationOf allows you to track dependencies, including transitive ones. That is a massive win, and swamps the relatively minor issues I have with Metacello (like hard-coding where to get one's mcz files).

At a certain point you have to ay where the code is to be found :) In your install script, it is also hardcoded:

Installer ss3 project: 'Control'; addPackage: 'Control-fbs.19'; addPackage: 'ControlTests-fbs.15'; install.

In Metacello, you could specify multiple (possibly backup) repositories.

But other than that, I agree with you :)

Yes, but I don't expect Installer to do anything more: it's brain-dead. Whereas with Metacello I did expect to have that clean separation like you do with Maven, where your profile - configuration - says where to get artifacts.

frank

best -tobias

On 6 March 2013 16:53, Tobias Pape Das.Linux@gmx.de wrote:

Am 06.03.2013 um 17:46 schrieb Frank Shearar frank.shearar@gmail.com:

...

...

[…]

At a certain point you have to ay where the code is to be found :) In your install script, it is also hardcoded:

Installer ss3 project: 'Control'; addPackage: 'Control-fbs.19'; addPackage: 'ControlTests-fbs.15'; install.

In Metacello, you could specify multiple (possibly backup) repositories.

But other than that, I agree with you :)

Yes, but I don't expect Installer to do anything more: it's brain-dead.

The point with installer in the Metacello-case is just to _retrieve_ the configuration. There is an upcoming Metacello Scripting api [1], that turns the Metacello thing into:

Metacello new configuration: 'Control'; squeaksource: 'Control'; version: '1.0'; load.

which would not depend on you fetching the configuration.

Well, "which would fetch the configuration for you", sure.

...

Whereas with Metacello I did expect to have that clean separation like you do with Maven, where your profile - configuration

• says where to get artifacts.

Doesn’t it? It’s just the same with metacello, no?

Well, it depends on what the #squeaksource: send does. The ConfigurationOf should define the dependencies (including versions), but _should not_ tell you where to get the artifacts. So if #squeaksource: (and presumably similar messages) are how you say to Metacello "get these locally or, failing that, get these from A or, failing that, from B", then I'm happy.

frank

Best -Tobias [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScri...

On 7 March 2013 21:20, Dale Henrichs dhenrich@vmware.com wrote:

----- Original Message ----- | From: "Frank Shearar" frank.shearar@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Sent: Thursday, March 7, 2013 2:26:45 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) | | | Well, it depends on what the #squeaksource: send does. The | ConfigurationOf should define the dependencies (including versions), | but _should not_ tell you where to get the artifacts. So if | #squeaksource: (and presumably similar messages) are how you say to | Metacello "get these locally or, failing that, get these from A or, | failing that, from B", then I'm happy.

Frank,

There are some basic rules that Metacello follows for loading packages:

1. If the specified package version is already loaded in the image, nothing is done
2. If a later version of the package version is already loaded in the image, nothing is done
3. If the specified package version is present in the package-cache, the package is loaded from the package-cache
4. If the specified package version is found in one of the repositories listed for the package or project (multiple repositories may be specified) the package is loaded from the first repository it is found in (search order of repositories is not guaranteed)
5. throw an error

If one doesn't specify an explicit package version then the "latest version of the package" is loaded. The Gofer sort order for packages is used to determine "latest version". In this case, all of the associated repositories are unconditionally searched for the "latest version", but once the "latest version" is determined, the above listed rules are applied.

If a package is dirty, a notification is raised and if handled one can choose to override the dirty package. The default action is to skip loading over dirty pacakages.

The rules for loading configurations is similar to packages except for a couple of exceptions:

1. If the version being loaded is blessed as #development, then a new copy of the configuration is loaded from the repository.
2. If you request a version that is not present in the loaded configuration, then an attempt is made to load the latest version of the configuration package from the repositories associated with the configuration and then the version lookup is tried again.

I'm not exactly sure whether this covers your: "get these locally or, failing that, get these from A or, failing that, from B", but I at least you should have a better idea of what Metacello does do ...

How does one specify the repositories in step 4? I know that a ConfigurationOf can say "find these in this project on SS3", which is... problematic. Well, it's fine as a _default_, but you need to be able to override that. And I know there's #overrideRepositories: but I thought that wasn't quite the thing that I was looking for?

I realise I should know all this stuff already. My apologies for forgetting.

frank

Dale

On 7 March 2013 22:43, Dale Henrichs dhenrich@vmware.com wrote:

----- Original Message ----- | From: "Frank Shearar" frank.shearar@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | Sent: Thursday, March 7, 2013 1:51:48 PM | 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) | | On 7 March 2013 21:20, Dale Henrichs dhenrich@vmware.com wrote: | | > There are some basic rules that Metacello follows for loading packages: | > | > 1. If the specified package version is already loaded in the | > image, nothing is done | > 2. If a later version of the package version is already loaded | > in the image, nothing is done | > 3. If the specified package version is present in the package-cache, | > the package is loaded from the package-cache | > 4. If the specified package version is found in one of the repositories | > listed for the package or project (multiple repositories may be | > specified) the package is loaded from the first repository it is found | > in (search order of repositories is not guaranteed) | > 5. throw an error | > | > If one doesn't specify an explicit package version then the "latest version | > of the package" is loaded. The Gofer sort order for packages is used to | > determine "latest version". In this case, all of the associated | > repositories are unconditionally searched for the "latest version", but | > once the "latest version" is determined, the above listed rules are | > applied. | > | > If a package is dirty, a notification is raised and if handled one can | > choose to override the dirty package. The default action is to skip | > loading over dirty pacakages. | > | > The rules for loading configurations is similar to packages except for a | > couple of exceptions: | > | > 1. If the version being loaded is blessed as #development, then a new | > copy | > of the configuration is loaded from the repository. | > 2. If you request a version that is not present in the loaded | > configuration, | > then an attempt is made to load the latest version of the | > configuration | > package from the repositories associated with the configuration and | > then | > the version lookup is tried again. | | How does one specify the repositories in step 4? I know that a | ConfigurationOf can say "find these in this project on SS3", which | is... problematic. Well, it's fine as a _default_, but you need to be | able to override that. And I know there's #overrideRepositories: but I | thought that wasn't quite the thing that I was looking for? | | I realise I should know all this stuff already. My apologies for forgetting.

Frank,

I kinda figured that would be where you were going, but covering the basics is important ...

I agree that "it's fine as a _default_", but to do so requires that one provide a means for managing the mapping between repositories and packages independent of the configuration. Without being present in a base image by default it is hard to provide such a mechanism:)

The Metacello Scripting API has an independent project registry, where you can identify which repository should be used with which project. I'm still working through some issues so I haven't released the Scripting API into the wild, but I am looking at the next major release of Metacello to directly address your needs ...

That's awesome, because I know this guy who can get code into Trunk? *cough*

We seem to have a bit of a chicken & egg here with the Metacello Scripting API, where you want feedback before putting it into Squeak trunk, and I can appreciate you not wanting your hands tied by everyone scrambling to use your half-baked API. I wouldn't mind it baking in trunk now just because it's nice & early in our release cycle.

frank

Dale

Hi Tobias,

2. It is not the simple case that there are just 2 releases, say development

and deployment, it is more like Feature selection, however this leads to release explosion. I will now, just from memory try to recall possible combination that in this scenario would qualify as an independent release:

• Seaside 3.0.3 Base • Seaside 3.0.3 Base, Comanche • Seaside 3.0.3 Base, Fcgi • Seaside 3.0.3 Base, RSS • Seaside 3.0.3 Base, Email • Seaside 3.0.3 Base, Scriptatcoulus • Seaside 3.0.3 Base, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi • Seaside 3.0.3 Base, Comanche, RSS • Seaside 3.0.3 Base, Comanche, Email • Seaside 3.0.3 Base, Comanche, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS • Seaside 3.0.3 Base, Comanche, Fcgi, Email • Seaside 3.0.3 Base, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Base, Fcgi, RSS • Seaside 3.0.3 Base, Fcgi, Email • Seaside 3.0.3 Base, Fcgi, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email • Seaside 3.0.3 Base, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, jQuery • Seaside 3.0.3 Base, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Base, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development • Seaside 3.0.3 Development, Comanche • Seaside 3.0.3 Development, Fcgi • Seaside 3.0.3 Development, RSS • Seaside 3.0.3 Development, Email • Seaside 3.0.3 Development, Scriptatcoulus • Seaside 3.0.3 Development, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi • Seaside 3.0.3 Development, Comanche, RSS • Seaside 3.0.3 Development, Comanche, Email • Seaside 3.0.3 Development, Comanche, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS • Seaside 3.0.3 Development, Comanche, Fcgi, Email • Seaside 3.0.3 Development, Comanche, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Comanche, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 Development, Fcgi, RSS • Seaside 3.0.3 Development, Fcgi, Email • Seaside 3.0.3 Development, Fcgi, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email • Seaside 3.0.3 Development, Fcgi, RSS, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, jQuery • Seaside 3.0.3 Development, Fcgi, RSS, Email, Scriptatcoulus • Seaside 3.0.3 Development, Fcgi, RSS, Email, jQuery • Seaside 3.0.3 One-click

Instead of having so many "releases" of Seaside, would it be possible to just have one SM entry for Seaside Base and then, as separate SM entries, Seaside Development, Fcgi, RSS, Email, jQuery, etc? Each which would be smart enough to load Seaside Base automatically if it wasn't already. Metacello is declarative so the users "feature selections" should be able to be made any time, regardless of the pre-state of the image.

I understand a new release of "Seaside" may usually include changes to all of those "feature" packages but there is no way around that -- it's just a few minutes of work per package.

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

Hi again,

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

Am 06.03.2013 um 19:50 schrieb Chris Muller asqueaker@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

----- Original Message ----- | From: "Chris Muller" asqueaker@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org | 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 19:23, Chris Muller ma.chris.m@gmail.com wrote:

...

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

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.

...

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.

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 asqueaker@gmail.com:

Hi Tobias!

...

...

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

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

...

...

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

[footnote]

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.

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.

...

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.

I am on that path. :)

...

...

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

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

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.

...

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 like that we aregee.

...

...

(I wrote:)

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.

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

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