[squeak-dev] SM, scripts, and application names
Chris Cunnington
smalltalktelevision at gmail.com
Fri Mar 9 15:54:16 UTC 2012
-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
More information about the Squeak-dev
mailing list
|