Packages (was: Re: DVS Roadmap)

danielv at netvision.net.il danielv at netvision.net.il
Fri Nov 15 08:22:50 UTC 2002


I think this all is great. Especially having our own CVS like
repository, tailored for Squeak work sounds wonderful.

In the vein of lightweight modularity work, I think PackageInfo, as
separate from the rest of DVS, and maybe with some additions/integration
would make a good basis for packages in Squeak generally.

So I think we should think whether we might want to (gasp) add this to
the base Squeak image. A reminder for everyone of what PackageInfo does
-

It maintains clear, well defined specification of what code is in a
specific package, and the related information required to load/install
it (like related files).

The way it does this is by using a convention (this is what might be
controversial and I want opinions on) where:
A. System categories PWS-Kernel, PWS-Actions and PWS-Swiki are all part
of the PWS package, simply because a PackageInfo exists for that common
prefix.
B. The method FileList>>renderFile is also part of the same package,
despite FileList not being in those categories, because the method is in
the method category *pws (Asterisk followed by the package name). Such a
method is called a class extension.

The reason I'm mentioning this here, is because this convention gives us
a compatible way of doing class extensions in our packages, and also in
detangling the image, as Colin showed in his PWS modifications.

Objections, comments? If we agree about the convention itself, we can
talk about having PackageInfos in the image, and what other tools might
benefit from being based on them.

As an example, the RB Lint tool should obviously be able to check a
package, right?

Daniel

Avi Bryant <avi at beta4.com> wrote:
> Since roadmaps and RFCs seem to be the order of the day...
> 
> Those of you involved in the various packaging and detangling efforts may
> be interested to know what's happening with my DVS package in the near
> future.  OOPSLA got me started on some refactoring and rethinking, and the
> results so far are this:
> 
> - I've split the PackageInfo class out from the rest of DVS, so that it
> can be used on its own by other packages.  There are already tools out
> there that depend only on it (like SpaghettiTracer) and others that could
> be made to (like Ned's SARBuilder).  That way people can do package
> analysis, etc, without having the whole DVS UI/chunk-parser/etc loaded.
> I will probably also include a lightweight fileOut tool as an alternative
> to the full DVS system.
> 
> - Colin Putney and I have started extending PackageInfo with some useful
> analysis tools: queries like #externalUsers (outside methods that
> reference classes in the package) and #externalCallers (outside methods
> that send messages unique to the package).  This could be useful, along
> with SpaghettiTracer, for the image carvers - Colin used this to split out
> PWS.
> 
> - After a discussion with Michael Rueger at OOPSLA, I've made a good start
> at a simple declarative source model and versioning system; the idea is to
> move to a non-fileout based, pure-Squeak CVS-like tool.  I got the
> auto-merging working today, and it's looking pretty good.  The name of the
> system is Monticello.
> 
> I'll start releasing this stuff in the next couple of weeks as it
> stabilizes, and as I update docs.  Those with packages that currently
> depend on DVS may want to coordinate with me so we can release a stable
> set of tools together.  It would be nice if SM had some dependency support
> by then too... ;)
> 
> Cheers,
> Avi



More information about the Squeak-dev mailing list