help build a stable universe

David T. Lewis lewis at mail.msen.com
Mon Sep 6 15:38:55 UTC 2004


On Sun, Sep 05, 2004 at 11:12:58AM -0400, Lex Spoon wrote:
> Let's put together a stable package universe for 3.7, and see how it
> goes!  I think seeing Universes in action, even under a rushed release
> schedule, would let people see why I think package universes are a good
> artifact for us to develop and to rally around.  A stable 3.7 universe
> would be a good starting point for users who want to play with Squeak,
> and it would be a good basis for people building software on top of
> Squeak; in both cases, users value stability over having the newest
> software.

Lex,

I tried the "Squeak 3.7" universe, and it seems to work quite nicely.
Per your off list suggestion, I made an update to the load script for
OSProcess so that it works better with CommandShell in this universe.
The Universe Editor worked fine, and I was able to create an "account"
and update the OSProcess package entry and URL. There are a few rough
edges on the UI as expected for a brand new package, but I was able to
figure it out and it worked fine once I got the hang of it.

I ran into one glitch as a result of starting with the Squeak3.7g2Full
image. When I loaded OSProcessPlugin or XDisplayControlPlugin, they
notice the "depends-on" for VMMaker. The Universe Browser does not
know that VMMaker is already installed in the Full image, and tries
to load it, which leads to some errors and confusion. This is probably
pretty much what should be expected given that I started with a Full
image, but I wanted to mention it as a possible source of problems.

Universes looks very promising! Combined with SqueakMap, it could lead
to a very nice way to maintain "distributions" for various Squeak
communities.

I've really only played with it a little bit so far, but just to
see if I've got the basic idea right:

- A "Universe" describes a collection of Squeak packages at version
  levels are are consistent within that Universe. Depending on my
  interest in (for example) bleeding-edge versus rock-solid-stable,
  or software-developer versus educator, I would be able to select
  packages from the appropriate universe and have some confidence
  that they will play nicely together.

- The depends-on in a Universe is just a statement that (for example)
  the OSProcessPlugin package in this universe requires installation
  of the VMMaker package from this same universe, regardless of what
  other versions of OSProcessPlugin and VMMaker may have been developed
  before or after this Universe was established.

- The overall catalogue of everything in the universe of Squeak is
  kept in SqueakMap. A package in a Universe will hopefully always
  refer to a specific release of that package on SqueakMap.

- The nitty-gritty dependency rules for specific versions of various
  packages would be in SqueakMap. For example, if OSProcessPlugin
  works only with even-numbered VMMaker versions that are created on
  Wednesdays and Saturdays, the Universe does not care about any of
  that.

- As the developer of a package, I would expect to "release" it
  through SqueakMap, including (in the future) declaring any dependency
  rules related to other packages. I would not necessarily know or
  care what Universes my package will appear in.

- As the creator of a Squeak "distribution" (in the Debian sense of
  the word), I would expect to put together a Universe of packages
  selected from SqueakMap, using whatever release version of each
  package is appropriate at the time. In addition, I would add any
  simple dependency rules that declare that package XXX in this
  universe requires package YYY in this universe (or maybe these
  rules will be automagically derived from SqueakMap at some point,
  so they don't require any additional declaration in the Universe).

Thanks for doing this work, it looks really good so far.

Dave

p.s. The goal of "building a stable universe" sounds noble enough,
but perhaps a bit ambitious even for a Squeak project ;-)




More information about the Squeak-dev mailing list