3.6 "full" packages

Daniel Vainsencher danielv at netvision.net.il
Mon Jul 28 13:56:53 UTC 2003


Speaking to your trouble with DVS, I think that deprecating DVS is
premature, indeed, DVS could simply be left as it was, and unmaintained,
so that its users can migrate or take up responsibility for it.

[RB extensions and patches to system make all sort of trouble,
especially when not updated]
True - good packages should not include patches, and should minimalist
about extensions. That way they are quite unlikely to break other
peoples stuff. The RB maintainer is a slob(/been preoccupied with other
stuff). AFAICT, that doesn't apply to MC.

> I do mind very much if some package thinks
> it needs to enforce what that package thinks is "good for me".
...
[Reasons to use existing Smalltalk code formats]
MCV is wonderful for developing stuff. That its format is not standard
(say, SIF or .st) is a small inconvinience in my mind. You can export it
to .st. To sum up, you're not forced to force your users into anything.
Since I think that all of my users (wearing my RB maintainer hat) could
be interested in sending me patches for the RB, and this should be easy
for them to do, I certainly do find it appropriate to install MC for
them if it is missing.

I am slightly bothered by the fact that there is no way for them to see
beforehand what will happen, but I can live with that until SM
dependencies come about.

> You seem to
> assume that Monticello is going to be the "one and only" system in Squeak.
Certainly not. Until a few weeks ago I was rooting for an
alternative/complentary system that seemed to be brewing. It is merely
the best we have now, in that it is the first to give us a useful
concept of code packages. Note that my arguments merely require the
assumption that it is the system I as a maintainer want to use, not some
global "best/one and only" assumption.

> ... against silently loading
> (or even requiring) some particular package unless it is needed for what the
> package itself does
This basically means that you would disallow the use of alternative
formats on SM at all, including SAR, projects, and so forth? I don't
understand this at all. I think alternative formats are critical for
evolution of how we share stuff, and SAR and MC are definite
improvements in this area.

This of course doesn't by any means mean that you should be forced to
use MC to release your own packages, but other than the DVS deprecation,
I don't see any reason why you are.

Daniel

Andreas Raab <andreas.raab at gmx.de> wrote:
> > I don't see why "mere squeak user" should mind very much that MC gets
> > silently loaded. Do you?
> 
> Yes. Lots and lots of reasons. "Silently loading" packages makes assumptions
> about those packages which may not be true on any particular system. For
> example, try to load the SmaCC development package (I did this yesterday)
> which will silently install RB. Do I mind? Yes. Because RB hasn't been
> updated to the KCP changes in 3.6 because it makes all sorts of extensions
> and modifications to my system. I do mind very much if some package thinks
> it needs to enforce what that package thinks is "good for me".
> 
> This is in particular true about package/versioning systems. You seem to
> assume that Monticello is going to be the "one and only" system in Squeak.
> Well this may be true and it may not (IIRC, quite similar things have been
> said about DVS). Someone might port Store to Squeak. And someone else might
> invent an entirely new system. These similar kinds of systems can easily
> conflict as they have to hook into the system at a very low level and I
> would be extremely unhappy with some package which silently loads a
> potentially incompatible packaging/versioning system for no other reason
> than me being able to even look at it.
> 
> Another reason why I don't like this approach at all is evolution. The
> smallest common denominator among the different versions of Squeak and other
> Smalltalks are just plain (potentially attributed) file outs. Using one of
> those will enable you to load that particular piece of code even years from
> now, and from systems which are out of use for years. For example, I still
> have code which I wrote in VW (ten years ago) in a particular
> packaging/versioning system and it is because it used basically fileout
> format that I don't have to worry about it. I can still browse and load it
> and I will be able to do this ten years from now even though I no longer
> have the packaging system being used.
> 
> Just consider that even the B3D package (which I put up on SqueakMap a
> couple of month ago) could not be loaded into Squeak 3.6 any longer without
> some serious fiddling with the loading architecture. I solved this problem
> by extracting the SAR (which fortunately is plain zip) into a directory,
> manually installing the files from there and then fix up the loader.
> Consider what this would mean if each file were an .mcv and something in the
> format or interface would change (thus my original point of me not using any
> "beta" versions for reliable packaging).
> 
> All of this speaks in my understanding very loudly against silently loading
> (or even requiring) some particular package unless it is needed for what the
> package itself does (which, btw, applies to the SmaCC/RB example above, but
> this was an illustration about the kinds of things that can easily happen
> when you start loading stuff silently).
> 
> Hey, why I do even have to tell you this - you are the guys who want to cut
> the system into bits and pieces ;-) I'm actually making _your_ points ;-)
> 
> Cheers,
>   - Andreas
> 
> > -----Original Message-----



More information about the Squeak-dev mailing list