[squeak-dev] Re: Packages, Packages, Packages

Andreas Raab andreas.raab at gmx.de
Sat Dec 12 07:43:21 UTC 2009

Miguel Cobá wrote:
> Maybe more attention to the real uses of the technology
> outside the "core" squeak is needed here.
> Since some months ago, Dale Henrichs has made available Metacello
> that doesn't tries to "fix" monticello, but to build on top of the
> limitations of it by treating monticello as what does better:
> to load a single version of a given package in the image.
> Then it adds the apropriate "package" dependencies in
> a higher level. No need to feature creep monticello but use
> it as a sound base for solving the issues you mentioned.

I do not understand which problem domain Metacello is addressing and 
how. If you have more information, this would be very welcome.

>> Since none of the solutions above currently fits all the requirements we'll
>> have to fix some. That could mean adding dependencies to SqueakMap; it could
>> mean giving Universes a reasonable UI; it could mean fixing dependencies in
>> Monticello. I really don't care either way but I think we'll have to figure
>> something out here. Is anyone out there interested in or perhaps even
>> working on addressing any of these issues?
> Please, let behind that "squeak for all" mentality. The right tool for
> the right job.
> One tool (squeak or any other) can't solve all the problems.

I'm not claiming it can. I'm laying out a couple of issues that we need 
to address, and list the current options as far as I  understand them. 
The only thing I'm strongly against is to end up with another dependency 
on a tool that hasn't been written yet and that by the end of the day 
will the job just as incomplete as the alternatives.

>> The second big issue is how we deal with "core" vs. "extended" packages in
>> Squeak. As we move towards a smaller kernel, we should know which packages
>> are core and which ones are not. And when we remove packages that are
>> currently part of the image, we need a place to put them.
> Discussend long time ago in Pharo. Some useful ideas can be gathered
> from there, even if the project name produce some bad feelings.

Can you summarize the results of that discussion?

> So the question is, has ever been considered to simply build the bridge between
> communities and to use the PharoCore image as the base for Squeak?

This wouldn't work for the same reasons that it wouldn't work to use a 
Squeak-trunk image as the basis for Pharo. You should propose that at 
some point just to see what kind of reaction you get ;-)

   - Andreas

More information about the Squeak-dev mailing list