/
/>The above does not _sufficiently_ specify the dependencies:
 >* no version info (but you can trivially adjust it to do so by adding
 >the version - 'KomHttpServer-foo.23'), and more importantly,
 >* only direct dependencies.

Yea, you'd have to add the version info.

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

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.

 >If KomHttpServer depends on Quux, you're hosed, because your error
 >message is something like "You can't proceed without definitions for
 >QXWidget". Metacello _will_ (be recursing on the configurations) pull
 >in transitive/indirect dependencies.
/
/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.

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

 >ConfigurationOfFoos built using MetacelloToolbox will automatically
 >bootstrap Metacello. Look at ConfigurationOfQuaternion or
 >ConfigurationOfSqueakCheck and you'll see that all you need to do is
 >load the configuration package, and then run it. Yes, sure, you need
 >to have those two lines in an file that you run, but that's hardly an
 >issue.

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.

 >Then name your SM entry Foo. Who cares that some internal thing's
 >named ConfigurationOfFoo? That's exactly what it is. It _describes_
 >Foo's parts; it is not Foo itself!

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.

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.

Chris



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120309/f18a482a/attachment.htm