Packages Team report

Avi Bryant avi.bryant at gmail.com
Fri Mar 18 13:27:50 UTC 2005


The packaging effort is starting slowly; we're mostly in a discussion
phase so far, rallying around two topics that you might describe as:

a) How to (know how to) take the image apart
b) How to (know how to) put it back together again so it still works

You might notice some overlap here with the Modules work; the key
difference is that the Packages team is focused on the attending
social, rather than technical, issues.  That's the idea of "to know
how to": we're not trying to change the technology of loading and
unloading methods and classes from the image, just to provide the
right kind of metadata so that a user can make informed choices about
which ones to load and unload when.

To that end we're looking at two major pieces of work.  One
(addressing "a") is to properly categorize the methods and classes in
the image into packages with minimal dependencies on each other.  I've
put up a preliminary page to coordinate this work here:
http://minnow.cc.gatech.edu/squeak/5641 .  If anyone wants to start
tackling this, please, jump right in.

Meanwhile, Daniel Vainsencher and Dan Ingalls have posted about tools
they've written that should help automate some of the process; after a
little bit of experience with them, we'll need some further discussion
about what the best combinations of tools and techniques might be. 
One process that seems like it might work is:

1. Use MudPie (Daniel's tool) to find the "top layer" of packages,
that aren't depended on by much else.
2. Do a manual scan through these packages to toss out any extensions
that don't belong; unlike the Kernel packages, there shouldn't be
many.
3. Use Dan's tool to extract these packages and their extensions from
the underlying muck.

The other ongoing work (addressing "b") is the question of how to
maintain a package repository.  SqueakMap has been a wonderful
resource for the Squeak community, but needs to evolve to meet our
needs: for example, multiple/private repositories, dependencies, and
stable (guaranteed compatible) sets of packages .  Lex Spoon's
Universes system provides one nice solution to these issues, and Göran
has agreed to begin an incremental migration of some of the Universes
work into SqueakMap.  The first step will be to register Universes as
items in SqueakMap so that there is a known central index of all of
the stable package sets.

More as it happens.

Avi



More information about the Squeak-dev mailing list