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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Tobias Pape
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 <[hidden email]>:

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

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.


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

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

>  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?
>
> Do you know why the Metacello scripts keep failing for stuff that was
> once working?
>

[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
>> […]
===========>
>> To any Seaside dev, please consider merging my versions :)
<==========

[MTCL]
Side-Note: Metacello does not yet know of 4.3, 4.4 and 4.5 (as
our current trunk) as Platform Identifiers. How shall we proceed?
Who can add these?

Sorry for this being so long, but this is rather important to me.
I am open for discussion and directions. What about an IRC chat,
eg, on freenode?

Best
        -Tobias



[1] Message-Id: <[hidden email]>
[2] PS: I tried searching the SqueakMap Catalogue for “Squeaksource”, however, nearly
    every package matched. Shouldn’t the search box only match the name and, optionally,
    the description but _not_ the installation source?
[3] Message-ID: <[hidden email]>_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

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)

Janko Mivšek
Yes, please please, start using Metacello for loading from SqueakMap
too. This way many hours will be spared to us maintainers while
preparing new releases, testing and publishing them an all those
Smalltalks...

Best regards
Janko

Dne 06. 03. 2013 10:30, piše Tobias Pape:

> 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 <[hidden email]>:
>
>> 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.
>
> 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.
>
>
>> 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..
>
>>
>> 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.
>
>>  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?
>>
>> Do you know why the Metacello scripts keep failing for stuff that was
>> once working?
>>
>
> [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
>>> […]
> ===========>
>>> To any Seaside dev, please consider merging my versions :)
> <==========
>
> [MTCL]
> Side-Note: Metacello does not yet know of 4.3, 4.4 and 4.5 (as
> our current trunk) as Platform Identifiers. How shall we proceed?
> Who can add these?
>
> Sorry for this being so long, but this is rather important to me.
> I am open for discussion and directions. What about an IRC chat,
> eg, on freenode?
>
> Best
> -Tobias
>
>
>
> [1] Message-Id: <[hidden email]>
> [2] PS: I tried searching the SqueakMap Catalogue for “Squeaksource”, however, nearly
>     every package matched. Shouldn’t the search box only match the name and, optionally,
>     the description but _not_ the installation source?
> [3] Message-ID: <[hidden email]>
>

--
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

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)

Dale Henrichs
In reply to this post by Tobias Pape


----- Original Message -----
| From: "Tobias Pape" <[hidden email]>
| To: "ma chris m" <[hidden email]>, "Seaside - general discussion" <[hidden email]>
| Cc: [hidden email], "The general-purpose Squeak developers list"
| <[hidden email]>
| Sent: Wednesday, March 6, 2013 1:30:58 AM
| Subject: [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)
|
| [MTCL]
| Side-Note: Metacello does not yet know of 4.3, 4.4 and 4.5 (as
| our current trunk) as Platform Identifiers. How shall we proceed?
| Who can add these?

Tobias,

I am in the process of adding 4.4 and 4.5 identifiers for Metacello ... the process is wrapped in a GLASS release process, but I have defined the identifiers and the release is in the pipeline ...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev