> By using Metacello a projects author can make specific versions/ 
> package configurations available to others and afterwards commit new  
> code to the repo without affection others.

The author will not have tried and tested the code in every context,  
so really he doesn't know what is actually needed to load. The  
definitions need to be done the other way around, in the hands of the  
"users" to tell the author what works where, and what fixes are needed  
for what to work where.

I am looking forward to more forks, the way metacello manages its  
package definitions will not scale to more forks, it is cluttered  
enough as it is anyway and you only have 3 forks. What about when we  
are up to 50 or so forks.

You keep saying you only need this only this and only need that, this  
is way too complicated, and you only have to have 15 things loaded,  
before it all works. Yet you are telling us that this is the way  
forward for a modular future built on a kernel image.

It cant be because a kernel image will not have Monticello loaded, nor  
will it have network, or compression even.

The original 2006 Installer vision did get lot of bang for one little  
buck. Installer was one class, and it was only ever intended to be the  
first class. It only takes one more class to add dependencies  
(SakeTask) and one more to add all the metadata you could want  
(SakeInfo).

Installer has the advantage that you can see exactly what it is  
installing, and you can pick a single line of code and execute it line  
by line as you go for debugging. You can also call up specific  
versions, or authors, and you can also load stuff from squeakmap  
without squeakmap loaded, and load MC packages without MC loaded. You  
can point Installer at a web page and it finds the script, it does  
lots of things Metacello doesnt do in a more minimal context. Yet even  
Installer is too complicated, you cant rely on images to have  
installer loaded either!

What "we" need is for the package manager to be generating something  
that is deterministic and reliable, so you can see what it is going to  
do and what it did. Then mix and match stuff around, to create  
localised alternative selection.

After working with Sake/Packages (which as you know is much simpler  
than Metacello) but none the less capable, and it included all of  
universes, I have come to the conclusion that having dependency  
management is not the way to go. Sure it is flash when it works, but  
when it doesn't, who knows what happened in which order. I never got  
on very well with the linux apt-get stuff either.

The way I coped with linux's apt get stuff was simple, I didn't  
bother, I used the knoppix distro, which comes with everything pre- 
installed. This is what I think the way forward for kernel cuis is.  
You distribute images with everything interesting pre-installed.  
However the users can by seeing the exact organisation of how the  
image was created, the user can grab the bits he wants and assemble  
his image using bits of other images. So the seaside bits published in  
a Seaside one click image would be grabbable, and combinable with the  
bits from a Magma image, to make a Seaside-Magma image.

>> This installs in a fraction of the time and space.
>
> Hey, installer is just a loader.

You can see exactly what it is doing.

SakePackages loaded Seaside and Magma and Seaside-MagmaHelper in one  
hit too, but people didn't care that much about dependency management  
then, and I was building images with 60+ package in it. I have got  
20+  packages just for my own framework on top of seaside... Keeping  
package definitions up to date will end up as a full time job for  
someone, this has got way out of hand!

My new solution is based on 3 classes, an Export Target, an Exporter  
and an Export definition.

(Export to: 'testing') purge fileOut.

Is all I need to do to save everything. Why didnt I have this solution  
three years ago... simply because everything we are using is too darn  
complicated, and we are so convinced we have some great tools that we  
aren't bothering to think of simpler ideas.

> Metacello is a package management
> system!!!

Big, complicated, lots of dependencies.

> Ever worked with Envy or Maven in Java, ...?

No.

> Without Metacello (or a comparable package management system) we
> will NEVER SCALE projects or allow that they develop independent
> from each other without breaking each other!

I disagree, I think you just need to think about the problem in  
simpler terms.

> Especially when
> they are managed outside of the image - and I think that's our goal:
> a small kernel image and external projects/packages that could be
> loaded (and that fit together to work and could be based on another).
>
> Metacello does the minimal thing to manage that and even if it

No way does Metacello represent a minimal thing

> may require more work (especially on tools) it does a fairly good job
> already. You just have to learn about it and about modularity.
>
> Sorry for the long post - but I hope I was able to wet your appetite  
> towards modular Smalltalk.

You just scared me, a poor mediocre coder, imagining a future when the  
loading tools have more code and classes in them than the system itself.

I think that Juan has it right, simplicity, elegance and the ability  
to innovate and use ingenuity is the key to solving our future  
problems including scaling.

The problem I see as a casual observer looking at  metacello is that  
if that is our "simple solution" and it doesn't do quite what I want,  
then I am not going to be able to fix it. I prefer the small tools  
combine to make powerful solutions.

I now have the same opinion of Monticello. Everyone is so busy using  
the package version control that they have given up trying to find  
other simpler solutions to the real problems.

A week of working in an image without Monticello and I am rocking!

At the end of the day squeak was sold as an environment that anyone  
could change right down to the metal. However we still rely on  
"someone else" to fix the kernel for us. I have sat starting for 4  
years at horrible code in the kernel, and it is still there. Honestly  
I think Juan has shown us the light

Keith