Dependencies, Squeak Code Control
cputney at wiresong.ca
Wed Nov 19 00:29:51 UTC 2003
My general response here is that you're getting too bogged down in
specifics. Consider the problems that drove the development of
SqueakMap and Monticello to their current state. I'd say they were
something along these lines: "I need an easy way to find, download and
install packages" and "I need to be able to create and distribute
different versions of my packages and intelligently merge them with
Yes, these are simplifications, and even over-simplifications, but the
point is that we now have the tools to do these things, and they do
them well. They not only solve these problems, they solve all the
nagging little problems that come up when you confront the details of
actually doing this tuff.
I'm looking for the next "macro problems" that we need to solve as a
community. Now I'll respond to the individual points below.
On Nov 18, 2003, at 3:24 PM, Avi Bryant wrote:
> On Nov 18, 2003, at 1:57 PM, Colin Putney wrote:
>> 1) Package dependencies. If I'm loading a package that depends on
>> another package, I want SqueakMap to notice this and load that
>> package for me as well. There are lots of ways to do this, of course,
>> but I think Göran's plan is excellent. The only thing missing is
> That works well for SqueakMap, but what about when you're loading
> development code from a repository? Should there be some
> bundling/dependency system there? If I'm branching a bunch of
> packages at once, how do I mark that a certain set of versions goes
> together, in the version control system?
> Or should every development team be running a SqueakMap server, and
> all the tagging/dependency information goes there? Colin, should our
> "development stream" server be an SM instance?
That's a different (though similar) problem. Yes, Monticello probably
also needs some way to aggregate packages. It's possible that it needs
a dependency mechanism too. I myself haven't felt that need so far, but
perhaps others have. If so, perhaps this is a more important problem
than my #2 below.
My point here is that it doesn't "work well for Squeak Map" yet. It
hasn't been written. We haven't started using it and don't *know* how
well it works. Let get it running on SqueakMap, then worry about
whether the dependency engine can or should be used in Monticello as
>> 2) Version history queries. Monticello needs better facilities for
>> answering questions like "what is the history of this method?",
>> "What's the latest version of this package?", "What are the senders
>> of this message, now and in the past?" Avi and I are working on this
> At least, we're working on the middle question. The first and last
> question would require (I think) repositories that stored versions in
> some better indexed form than .mcz files. A GOODS-based repository
> may be in order, or maybe a PostgresRepository, but I don't know of
> anyone working on this (volunteers welcomed).
Yeah, we're tackling the middle question first. I see development
streams as a way to handle inter-version queries, though, so the other
two questions, and many others like them should be answerable with
similar mechanisms. One thing at a time though.
>> 3) More explicit packaging in the image. We need to make the
>> development tools - browsers, message lists, change sorters and so on
>> - package aware. We also need to refactor parts of the kernel,
>> compiler etc, to make it easier to make it easier to load and unload
>> packages safely. The guys at SCG are probably the experts here, since
>> Roel's Notifications work is key to this, and they've already
>> discovered the hard way where the issues are in hacking on the
>> SystemBrowser. Ned and Daniel have also done some useful work in this
>> area. Nevertheless, this is probably the area that's the least
>> "sorted out" in terms of how to proceed.
> I've been thinking about this some, and before we make the tools
> package-aware, I think we need to come up with a protocol by which the
> entities (classes, methods, and so on) can be made package-aware - or,
> more precisely, context-aware. As well as #methods and #subclasses, I
> want to have something along the lines of #methodsInContext: and
> #subclassesInContext:, where the context may be Smalltalk (ie, the
> entire image), may be a particular package, may be some group of
> packages (or bundle, or whatever), and so on. And I want this same
> protocol to be implemented both by Monticello's "dead" declarations
> and by the live objects in the image. Or maybe these shouldn't be
> methods on Class, but on some external Mirror, I don't know.
These are implementation details. The goal is to have package-aware
tools. Yes, it would be good to have tools that can be pointed at
different contexts, but that's a consequence of a good design, or
possibly a future goal.
Right now, it's more important to have tools that present packages as a
conceptual entity to the user. We need to be able to create a new
package, move classes and methods between packages, browse by package,
and so on. PackageInfo provides all (or most) of what we need to do
> Once we figure out this model, the tools themselves should be easy.
I'd go about it the other way. Let's create some tools. Then the model
should be easy. Baby steps. Refactor.
More information about the Squeak-dev