Dependencies, Squeak Code Control [proposal, long] (was: [TFNR][REPORT]Where are we?!)

Colin Putney cputney at wiresong.ca
Tue Nov 18 21:57:15 UTC 2003


On Nov 18, 2003, at 12:29 PM, Peter van Rooijen wrote:

> Goran, Stephane, et.al.,
>
> I saw your discussion about code control: dependencies (module
> requirements), package configurations, bundles, packages, etc.
>
> I have some experience and have done some work in this area, and I 
> thought
> it might be helpful to present a code control scheme that I feel could 
> work
> well for Squeak. It's a design that is quite a bit lighter-weight than 
> Envy
> or
> StORE, and much more powerful than simple class categories and 
> variants of
> that. It requires no change to the way the image works with code, yet 
> it
> provides versioning, dependency management, build control, and support 
> for
> a distributed repository.
>
> I would be happy for this design to be used as a basis for discussion 
> or
> implementation.

Not to be too undiplomatic, but I'm wary of going down that path. It's 
not so much that I don't like the design as that I'm uncomfortable with 
the approach. The past is littered with similar projects that failed, 
despite the soundness of their design or the excellence of their 
implementations.

The design you present is pretty comprehensive, and is strikingly 
similar to the way John Sarkela described Team/V to me at OOPSLA. I 
have no doubt it's capable of supporting all the features that users of 
that and similar systems have come to expect. The problem is that it's 
large and monolithic - a Big Design Up Front - that must be implemented 
and deployed in one giant leap. The recent progress we've made in 
package management and versioning has been because we took baby steps. 
We built the simplest possible tools to solve the most basic problems 
we face. We started using those tools and adapted our development and 
social processes to them.

Now it's time to go back to the beginning and start a new iteration. 
What problems need to be solved now? Here are the three problems I 
think we should tackle next.

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 code.

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 now.

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.

What do people think about this? Are there any problems I've 
overlooked? Reasons why these are non-issues?

Colin




More information about the Squeak-dev mailing list