On 9 March 2012 15:54, Chris Cunnington <smalltalktelevision at gmail.com> wrote:
> -inter-project dependencies
> -names
> -why Metacello configurations shouldn't be the underlying mechanism to put
> projects up on SM?
>
>
> Thank you for the feedback. I'd like to try something that may show my point
> of view. I may be misinformed on some things. Let's combine two ideas, one
> yours and one mine. We'll take two postulates and combine them. That should
> make it clearer in my mind and perhaps answer your question. Or at least
>  you'll see where I'm coming from.
>
> Your postulate will be the one above. I'll reduce that down to "only use
> Metacello". That's my interpretation of the question above.
>
> My postulate will be "install with a button". To combine the two, then, is
> to ask "how do I install a Metacello configuration with a button"?
>
> I haven't used Metacello Browser, because I tried to load it into Pharo with
> a Metacello configuration and it wouldn't. The idea sounds great, and I'm
> not sure why Pharo doesn't use it. Who doesn't like buttons?
>
> Well, Pharo and Squeak have been doing without buttons just fine. The
> standard is to cut and paste a script. Maybe you get it from a mailing list.
> Maybe you get it from SqueakSource to download Moose with a Metacello
> configuration. It's a poor solution only supported by social proof and
> precedent. Installing with a button is better.
>
> Take a Metacello configuration like this:
>
> Installer ss
>    project: 'MetacelloRepository';
>    install: 'FooFooFoo';
> ((Smalltalk at: #FooFooFoo) project version: #stable) load.
>
> We have that in a Workspace. In SM we put that in a file called, say,
> Foo.st. We save that on the SM server. Then we have a URL that installs with
> a button. And if you don't like files, you can't really be for SM, because
> it is only a storehouse of URLs with files at the end (mcz, sar, st).
>
> So, from the point of view of things in a Workspace that become URL
> accessible files, Metacello is a subset of the tools we use to capture the
> context -- the file. You can't install Metacello without either Gofer or
> Installer. If we have a file at the end of a URL, then you can have
> Installer or Gofer install MC configuration files (like this one
> http://www.squeaksource.com/VMMaker/update-dtl.mcm), or package names, or
> Metacello Repository configurations. They can all go in a file. The only
> difference is whether the dependencies information is in the Metacello
> configuration or in the file itself like this:
>
> Installer ss
>    project: 'KomHttpServer';
>    install: 'DynamicBindings';
>    install: 'KomServices';
>    install: 'KomHttpServer'.
>
> That is a load script with the dependencies specified. In the Metacello
> related script above the dependency resolution is delegated from the script
> to Metacello.

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.

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.

> So, I don't really understand your question, because you cannot make
> Metacello the underlying mechanism, because the underlying mechanism is
> taking something that is executed in a Workspace and making it a script, a
> file, that goes at the end of a URL. What you put into a Workspace is never
> confined to Metacello, and neither would any install need to be.

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.

> Oh yea, one more thing. I was advocating application names yesterday. I
> don't see anything in Metacello that does what I'm talking about. It has
> names for configurations like ConfigurationOfFoo. I just want Foo. Give me
> Foo. If I'm SmalltalkDirectons and someone gives me a tip on a great
> application called Foo, then I want to look for Foo. I don't want a
> "ConfigurationOfFoo" and I don't want to guess that the package name MCFoo
> or FFFoo or QSQuasiFoo is the package that may be the root. I want to see a
> list. I want to see Foo. And I want to press a button.

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!

frank

> Thanks,
> Chris
>
>
>