<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
<i><br>
</i>>The above does not _sufficiently_ specify the dependencies:<br>
>* no version info (but you can trivially adjust it to do so by
adding<br>
>the version - 'KomHttpServer-foo.23'), and more importantly,<br>
>* only direct dependencies.<br>
<br>
Yea, you'd have to add the version info. <br>
<br>
"Only direct dependencies" I guess that's the nut, isn't it. I
suppose this is why people have a mystical appreciation of
dependencies. Yea, what I'm suggesting would be "only direct
dependencies". Correct. The developer creates an Installer script
that a person knowing-nothing-about-the-application executes with a
button. If Metacello wants to go on a Jungian quest for "indirect
dependencies" (whatever they are) then, perhaps that's why it's so
brittle and often fails. Try loading ConfigurationOfMetacelloBrowser
in Pharo. <br>
<br>
A developer should be able to make a list of what their app needs.
The consumer should know nothing. A script can facilitate that for
three packages or for MetacelloRepository. <br>
<br>
>If KomHttpServer depends on Quux, you're hosed, because your
error<br>
>message is something like "You can't proceed without definitions
for<br>
>QXWidget". Metacello _will_ (be recursing on the configurations)
pull<br>
>in transitive/indirect dependencies.<br>
<i><br>
</i>And who's fault would that be? That's my point. The developer's
fault. Period. They've lost track of their dependencies, whether
direct or indrect. <br>
<br>
I suppose you're "indirect dependencies" means you load an
application, which knows it needs to load an application, which
knows it needs to load an application. So that, instead of listing
fifty lines of "direct dependencies", you can do it in two lines.
That kind of cleverness is likely why I find Metacello often fails.
Try loading ConfigurationOfSeasideHarbour in Pharo. And the worst
thing about it is that SOMEWHERE in the process something failed.
And since the whole thing is so monolithic, you can't debug it. And
the person who was responsible, the developer, has failed.
Honestly... <br>
<br>
>ConfigurationOfFoos built using MetacelloToolbox will
automatically<br>
>bootstrap Metacello. Look at ConfigurationOfQuaternion or<br>
>ConfigurationOfSqueakCheck and you'll see that all you need to
do is<br>
>load the configuration package, and then run it. Yes, sure, you
need<br>
>to have those two lines in an file that you run, but that's
hardly an<br>
>issue.<br>
<br>
And you can put that in a Foo.st script and SM will do all of that
quite happily. I keep saying a script is a script is a script,
whether it is direct dependency, three line and using Installer or
Metacello. My conception for SM is still solid. I think we're
arguing about Metacello somehow. If you people want to load ten
layers of programs with two lines, great. But to think that is the
only way is incorrect. First, you could struggle through writing 100
lines of direct dependencies. Or Colin was talking not so long ago
(it may have been on the SOB mailing list) you could have a Codex
shorthand for your release that compiles to a 200 line, direct
dependency Installer script. At least with that you could see what's
going on. When Metacello fails, you are alone in the dark on the
Nostromo waiting for the acid-for-blood Alien to get you. <br>
<br>
>Then name your SM entry Foo. Who cares that some internal
thing's<br>
>named ConfigurationOfFoo? That's exactly what it is. It
_describes_<br>
>Foo's parts; it is not Foo itself!<br>
<br>
Yea, that's exactly the point. Add a new form field to SM web site,
as I said yesterday. Abstract over for a name for the script. And
make that form field default to "anonymous", which the developer
will see in the image GUI widget window, so they know they need to
go back to the SM web site and change it. <br>
<br>
Tim and Frank, we are all in agreement. SM could be a vector for
MetacelloRepository. And I aim to first add the programs in Squeak's
Extending The System window pane, then MetacelloRepository, and then
the fifty most canonical applications on SqueakSource. You two like
Metacello and I don't. But let's not lose sight of the point of
agreement here: SM could be a decent enough vector for
MetacelloRepository. On that, I think we're agreeing. Should be fun.
<br>
<br>
Chris <br>
<br>
<br>
<br>
</body>
</html>