Monticello, SM2, BFAV in 3.7alpha

Avi Bryant avi at
Tue Jan 27 00:19:39 UTC 2004

On Jan 26, 2004, at 3:35 PM, Michael Rueger wrote:

> I may be the lonely kid on the block here, but I'm against it on 
> principle. I don't use the Monticello for a variety of reasons, but 
> besides that I don't want *any* (can I double bold this?) packaging 
> system in the basic system.
> Packaging systems have the tendency to viral themselves into all 
> aspects of the core system and once they are there, nobody even has 
> the chance to come up with a different approach.
> The total and utterly failure of the module system, from which we had 
> to back out as we couldn't remove it any more, taught us a lesson, 
> please let's remember it.
> I'm not saying that Monticello is not a usable (and hopefully at some 
> point stable) system, but packaging should not be built-in. Period.
> I like the SM approach, as it does not enforce a particular packaging 
> approach, but rather allows people to post their code in whatever 
> loadable format they want.

If I can ramble about this for a bit - I guess there are at least three 
issues here for me:

- "Package definition" (grouping classes and methods within the image) 
is not the same as "package management" (which includes mechanisms for 
loading/storing/versioning packages)
- "In the Basic image" (loaded by default into the image people 
download) is not the same as "part of the core system" (it's difficult 
or impossible to have a useful image without it because so much depends 
on it)
- Putting interfaces in the core is not the same as putting 
implementations in the core

I agree with you in that I would argue very strongly against having any 
particular package management implementation being part of the core 
system.  The design space is just too large, and the options too 
varied, for it to make sense to commit ourselves strongly to one 
system.  As you say, SM has exactly the right approach here.

I would argue almost as strongly that we *should* have a package 
definition interface as part of the core.  That is, I think it would be 
useful to have a standard Package interface (or, if you prefer, call it 
Categorization) that various system tools like the Browser can depend 
on.  Nothing fancy, just a way to tell what discrete groups of code 
exist in the image.  SystemOrganizer is one possible implementation of 
this, that the tools all currently know about and use.  PackageInfo is 
another possible implementation, basically just a subtle refinement of 
SystemOrganizer.  We may have better implementations in the future.  
But this is something that most tools benefit from (indeed, are 
benefitting from, in the form of SystemOrganizer), and it's something 
that's easy to build an abstract interface around.

The question at hand is whether to put a particular package management 
implementation (Monticello) into the Basic image.  I don't actually 
think this would be a problem, for this reason: as long as we have a 
good Package abstraction in the core, people building tools will depend 
on that rather than on Monticello, which would itself be just another 
client of the Package abstraction (this was of course the point of 
separating out PackageInfo).  Other package management systems could 
easily live side by side with it and use the same Package objects, so 
there shouldn't be any viral effect.  By the same logic, however, I 
don't think it's crucial that we put it into Basic - since nothing 
should be depending on it, it should always be trivial for a user to 
just load it with a single click from the Package Loader when they want 
it (or load it on demand from an item in the world menu, or whatever).



More information about the Squeak-dev mailing list