[Vm-dev] Re: [squeak-dev] [ANN] VMMaker metacello config for Squeak and Pharo

keith keith_hodges at yahoo.co.uk
Sat Feb 6 01:20:44 UTC 2010

> Torsten Bergmann wrote:
>> Andreas Raab wrote:
>>> Let's be a bit careful before jumping heads-on into the Metacello  
>>> frenzy.
>> Somehow I knew before that you will respond like this ... ;)
> Right. And that's the problem with prejudices. If you expect a  
> response of a certain form you'll find a way to interpret what's  
> being said to match your expectations even though the intention may  
> have been completely different.
> What I was saying to David, not to you, is that we need to make sure  
> that we don't introduce any undue dependencies on Metacello. Given  
> the dependencies of Metacello itself I think there is an actual risk  
> of that happening and I simply wanted to remind David that it's  
> important for us to make sure VMMaker doesn't require Metacello.
> BTW, it is unfair to spam your message to both Squeak-dev and the  
> Pharo list just to paint me as a nay-sayer in the community.
> Cheers,
>  - Andreas
>>> I don't mind if people choose to use Metacello to load VMMaker but  
>>> it shouldn't be the only option.
>> Hey - Metacello is "just" a package management tool for Monticello  
>> using descriptions of the dependencies and the

It's is not "just a package manager" it is huge and totally over  
engineered for the purpose you have in mind. You are talking 40  
classes! VMMaker is at a far lower level than Seaside or other things  
Metacello is being used for.

Installer has a mechanism that is much better suited to this purpose,  
a simple readable DSL for loading things. You can put  scripts into  
InstallerScripts to be loaded using

Installer install: 'VMMaker'.

this is very simple, and you can publish variants for all different  

>> versions that fit together. Anything I did was to create such a  
>> configuration. Nobody forces you or other developers to use  
>> Metacello - having such an (additional) config does not change the  
>> way you are working right now. Use Monticello, SqueakSource, ... as  
>> you did before. You can continue to use build scripts, installers,  
>> SqueakMap, Universe, whatever ... to load VMMaker.
>> But currently I dont see none of these "loaders" is well maintained  
>> (or only with private scripts), anything I've found was a

What do you need to be maintained. Installer was written in 2006 and  
has been working fine ever since, has been majorly refactored, and the  
api has stayed consistent, through all of that time. There is very  
little to maintain on installer, that is often the key to effective  

Sake/Packages just adds dependencies, it too is small and relatively  
simple. S/P has been relatively stable for a long period. In S/P If  
you need a package to load, you maintain it. It is for the users to  

I am certainly not convinced as to why you need Metacello, to achieve  
what Installer used to do in one class.

>> decription from David (see last mail) on the web. And how often  
>> does one ask which packages in which version fit
>> together to get VMMaker or other Squeak projects to work. Try to  
>> rebuild the
>> SqueakSource server and you know what I'm talking about!
>> Providing and maintaining a metacello spec is simple and works. And  
>> the

I don't agree. Nothing about Metacello strikes me as simple.

I could comment on the rest of your post, I basically disagree with  
pretty much everything you say.

Can Metacello publish and use definitions on a web page or wiki, can  
it load from squeakmap, or universes, can it access published bug  
fixes, can you override with your own local definitions, can it  
bootstrap from the source.st code inside a monticello package.

If you look at the range of functionality in the existing tools we  
have had for along time, Metacello really isn't offering anything of  
interest, and is certainly overkill for VMMaker.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100206/daf67be5/attachment.htm

More information about the Vm-dev mailing list