[squeak-dev] Packages, Packages, Packages
andreas.raab at gmx.de
Sat Dec 12 05:14:54 UTC 2009
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
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
* 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.
More information about the Squeak-dev