<html><head><meta content="text/html; charset=iso-8859-1" http-equiv="Content-Type"></head><body><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">I agree in all points with Frank. Metacello offers a system to do it, SM a system to run the DoIt. If we just standardize on Metacello ( at least for the default case) you don't even need to specify versions and install scripts in SM anymore. Just point to a ConfigurationOf package. SM can strip the prefix to get the name, parse the data to get the versions, generate the install script for each version. Couldn't be easier to add sth to the map.<br></div></div><hr><span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Von: </span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">Frank Shearar</span><br><span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Gesendet: </span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">09.03.2012 17:22</span><br><span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">An: </span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">The general-purpose Squeak developers list</span><br><span style="font-family: Tahoma,sans-serif; font-size: 10pt; font-weight: bold;">Betreff: </span><span style="font-family: Tahoma,sans-serif; font-size: 10pt;">Re: [squeak-dev] SM, scripts, and application names</span><br><br>On 9 March 2012 15:54, Chris Cunnington <smalltalktelevision@gmail.com> wrote:<br>> -inter-project dependencies<br>> -names<br>> -why Metacello configurations shouldn't be the underlying mechanism to put<br>> projects up on SM?<br>><br>><br>> Thank you for the feedback. I'd like to try something that may show my point<br>> of view. I may be misinformed on some things. Let's combine two ideas, one<br>> yours and one mine. We'll take two postulates and combine them. That should<br>> make it clearer in my mind and perhaps answer your question. Or at least<br>> you'll see where I'm coming from.<br>><br>> Your postulate will be the one above. I'll reduce that down to "only use<br>> Metacello". That's my interpretation of the question above.<br>><br>> My postulate will be "install with a button". To combine the two, then, is<br>> to ask "how do I install a Metacello configuration with a button"?<br>><br>> I haven't used Metacello Browser, because I tried to load it into Pharo with<br>> a Metacello configuration and it wouldn't. The idea sounds great, and I'm<br>> not sure why Pharo doesn't use it. Who doesn't like buttons?<br>><br>> Well, Pharo and Squeak have been doing without buttons just fine. The<br>> standard is to cut and paste a script. Maybe you get it from a mailing list.<br>> Maybe you get it from SqueakSource to download Moose with a Metacello<br>> configuration. It's a poor solution only supported by social proof and<br>> precedent. Installing with a button is better.<br>><br>> Take a Metacello configuration like this:<br>><br>> Installer ss<br>> project: 'MetacelloRepository';<br>> install: 'FooFooFoo';<br>> ((Smalltalk at: #FooFooFoo) project version: #stable) load.<br>><br>> We have that in a Workspace. In SM we put that in a file called, say,<br>> Foo.st. We save that on the SM server. Then we have a URL that installs with<br>> a button. And if you don't like files, you can't really be for SM, because<br>> it is only a storehouse of URLs with files at the end (mcz, sar, st).<br>><br>> So, from the point of view of things in a Workspace that become URL<br>> accessible files, Metacello is a subset of the tools we use to capture the<br>> context -- the file. You can't install Metacello without either Gofer or<br>> Installer. If we have a file at the end of a URL, then you can have<br>> Installer or Gofer install MC configuration files (like this one<br>> http://www.squeaksource.com/VMMaker/update-dtl.mcm), or package names, or<br>> Metacello Repository configurations. They can all go in a file. The only<br>> difference is whether the dependencies information is in the Metacello<br>> configuration or in the file itself like this:<br>><br>> Installer ss<br>> project: 'KomHttpServer';<br>> install: 'DynamicBindings';<br>> install: 'KomServices';<br>> install: 'KomHttpServer'.<br>><br>> That is a load script with the dependencies specified. In the Metacello<br>> related script above the dependency resolution is delegated from the script<br>> to Metacello.<br><br>The above does not _sufficiently_ specify the dependencies:<br>* no version info (but you can trivially adjust it to do so by adding<br>the version - 'KomHttpServer-foo.23'), and more importantly,<br>* only direct dependencies.<br><br>If KomHttpServer depends on Quux, you're hosed, because your error<br>message is something like "You can't proceed without definitions for<br>QXWidget". Metacello _will_ (be recursing on the configurations) pull<br>in transitive/indirect dependencies.<br><br>> So, I don't really understand your question, because you cannot make<br>> Metacello the underlying mechanism, because the underlying mechanism is<br>> taking something that is executed in a Workspace and making it a script, a<br>> file, that goes at the end of a URL. What you put into a Workspace is never<br>> confined to Metacello, and neither would any install need to be.<br><br>ConfigurationOfFoos built using MetacelloToolbox will automatically<br>bootstrap Metacello. Look at ConfigurationOfQuaternion or<br>ConfigurationOfSqueakCheck and you'll see that all you need to do is<br>load the configuration package, and then run it. Yes, sure, you need<br>to have those two lines in an file that you run, but that's hardly an<br>issue.<br><br>> Oh yea, one more thing. I was advocating application names yesterday. I<br>> don't see anything in Metacello that does what I'm talking about. It has<br>> names for configurations like ConfigurationOfFoo. I just want Foo. Give me<br>> Foo. If I'm SmalltalkDirectons and someone gives me a tip on a great<br>> application called Foo, then I want to look for Foo. I don't want a<br>> "ConfigurationOfFoo" and I don't want to guess that the package name MCFoo<br>> or FFFoo or QSQuasiFoo is the package that may be the root. I want to see a<br>> list. I want to see Foo. And I want to press a button.<br><br>Then name your SM entry Foo. Who cares that some internal thing's<br>named ConfigurationOfFoo? That's exactly what it is. It _describes_<br>Foo's parts; it is not Foo itself!<br><br>frank<br><br>> Thanks,<br>> Chris<br>><br>><br>><br><br></body></html>