SM, scripts, and application names

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

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.

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.

Thanks,
Chris

On 9 March 2012 15:54, Chris Cunnington <[hidden email]> 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.

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