[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
platforms.
>> 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
maintenance.
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
maintain.
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.
cheers
Keith
-------------- 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