[squeak-dev] Re: About Configurations
andreas.raab at gmx.de
Tue Jul 13 06:24:27 UTC 2010
On 7/12/2010 10:17 PM, Casey Ransberger wrote:
> I thought this was a bang-up idea. Any particular reason the
> Configurations package hasn't made it into the Trunk? Anything I can do
> to help?
Mostly because I've been second-guessing myself. After playing with it
for a while it felt like bad fit for the job. Perhaps others have an
insight on this, but my feeling of what this is supposed to be doing is
to provide an easy and straightforward way to install "new stuff". As
such, I would expect it to look more like a Windows (or Mac) installer
that is listing features for example:
[x] Code (required)
[x] Tests (optional)
[x] Documentation (optional)
instead of something like apt or rpm (i.e., even in the Ubuntu Software
Center it's virtually impossible to figure out what the name of the
package with the necessary headers for X11 is). Unfortunately, Metacello
resembles more the latter than the former and I'm not sure it's a good
idea to try to transform from one into the other.
In addition, Metacello's heavyweight nature keeps bothering me. It may
be fine to load Metacello for something complex like Seaside, but *lots*
of good things (say the games) are single MCZ package installs where the
overhead of installing Metacello completely dominates everything else.
And given that in such a case Metacello does nothing that Installer
can't do in a single line it leaves me wondering why we'd use such a
So I've been thinking if it isn't better to regroup things and define
that the stuff that comes with the image is more light-weight than
Metacello by default - it may *use* Metacello for installing it where
that's desirable but it wouldn't require Metacello for simple things.
Instead, it would focus more on those "installer options" that say from
a user perspective here are the things that you may want to install and
they boil down into some packages.
Basically, it would boil down to a "configuration" (needs a different
name to avoid confusion) being a container of information about a piece
of software. It contains the authore, description, and other meta info,
has a set of installable options, and knows what further code to run
when any such option is selected. So that, for example, in Seaside your
options might be something along the lines of:
Seaside 3.0 options:
[x] Seaside (required)
[x] Pier (optional)
[x] Extras (optional)
which then map into installing particular targets from the associated
The other advantage of this approach would be that it can introduce a
form of "late-binding" in the installation process. For people who want
to maintain their package(s) elsewhere (Seaside or OB) it introduces an
indirection where the "in-image" configuration simply defers to the
"ex-image" configuration. We had talked about this in the past and this
would make that pattern explicit.
And of course, for the simple packages we'd literally just use the
one-line Installer loading mechanism.
More information about the Squeak-dev