On 9 March 2012 18:48, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
>
>>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.

I realise we're agreeing on the meat of the issue, so feel free to
ignore the following: the essential difference between writing a load
script and using Metacello is that if one of the packages I use - Bar
- upgrades something that _it_ uses (Baz) (and about which I don't
care), then without my doing anything more than saying "my package now
uses Bar 2", everything still Just Works. It delegates the
responsibility for building Bar to where it belongs, with the Bar
developers.

Your position is "my users rely on me to deliver something, and if
that means I must hunt down every transitive dependency, by hand, on
my knees, then so be it." That's fair enough, but it's asking a hell
of a lot of you. To which I can only say, given that in an Ideal World
this would Just Work, but in the Real World bad things happen, let's
do BOTH - define our ConfigurationOfFoo because it encapsulates things
properly, AND let's turn that nice recursive definition of things into
a flat load script, for those who want that.

But seriously, I haven't actually seen Metacello flake out. It does
pretty much the same job as Maven does in the Java land, right down to
getting the transitive dependencies, and while Maven might be pretty
heavy, it _works_, from tiny little projects to hulking great big
enterprise projects. The fundamental idea is sound.

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

Yep, agreed!

frank