Folks -

Here is the long overdue post about packages and how to manage them. One 
of the things that comes directly out of Edgars and my desire to unload 
a few more packages, is the question of what to do with them. That 
raises the question of how to deal with external packages in general. So 
here we go with some thoughts on both.

We have various package management systems that all fall short in some 
respect. First, there is Monticello, our source code management system. 
Monticello works reasonably well for maintaining individual source 
packages but is awfully lacking in two core areas: Managing dependencies 
and being findable. MCs "builtin" dependency mechanism is just awful; 
configurations work somewhat better but neither address "higher level" 
dependencies such as "this package depends on Seaside 2.8" (the only way 
to express this is by listing all of Seaside's packages explicitly). 
Secondly, MC is generally not indexable by Google which is a fatal flaw 
from my point of view (because how the hell are you going to find a 
package if you can't google for it?)

Our second candidate is Squeakmap. Of all the solutions, Squeakmap is 
currently the only one that is indexable by Google; a major advantage. 
However, Squeakmap doesn't have dependencies, rendering it difficult to 
use for non-experts. Squeakmap also has the disadvantage that it's 
pretty dated by now and has been in need of a serious face lift since 
its inception :-) (that said I do like it and would rather like to see 
it revived)

The third candidate I'm aware of is Universes. Universes is the only 
candidate here which has dependencies that actually work reasonably 
well. In addition, universes can be used off-line so it would be 
feasible to ship a "standard library" with Squeak for people to download 
and install (a little bit like Python's site-packages). The downside of 
Universes is that they're not indexable and their user interface is by 
far the most awful and unusable of all the proposals.

I think that's all the serious contenders at this point (if I'm missing 
something please let me know). From my perspective, I don't care which 
solution we choose as long as it fits the bill of:
* Being indexable by Google
* Reasonable dependency management
* Having a usable UI
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?

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.

In addition, we really need to start thinking about the packages that a 
"standard" Squeak should contain. Personally, I feel that one of the 
best decisions David and I made in Croquet was having the small base 
image be tucked away in the distribution so that people who want to 
build something small have a starting point but with the "standard" 
build being a fully featured set of packages that contained everything 
we wanted to show.

I think the approach is perfectly applicable to Squeak - we need to move 
the "core" image aggressively forward; every release should make it 
significantly smaller. And while we're doing this we should have a 
"standard" image (not necessarily a kitchen-sink image with *everything* 
thrown in) but the packages that we think your average Squeak user would 
be interested in seeing.

If people agree with the direction of aggressively shrinking the core 
image as well as figuring out what the default image should contain then 
our next steps should be:
* Figure out where to place unloaded packages (we could leave those in 
trunk if we wanted to but I'm not certain that's the right place; 
perhaps Edgar's Ladrillos could work?)
* Figure out a build process that we can apply to the core image to 
build the default image automatically
* Discuss and decide which packages should be part of the standard 
Squeak version
* Unload some more packages!

So far my thoughts on the issue. Feedback is very welcome, I think we 
need to move forward on this set of issues before the next release goes out.

Cheers,
   - Andreas