SqueakMap2, Kabungu and KomPackageBuilder dependencies management

stéphane ducasse ducasse at iam.unibe.ch
Tue Jan 3 14:15:42 UTC 2006

Hi samir

indeed I would like to see an easy and powerful way to deal with  
I'm not sure that kabungu is wrong. I like the idea that packages do  
not have dependencies
but you have a "configuration object" that tells which are a good  

I would ***really*** like to get something working for MC.
And for 2006 having a real package class = (rename of PackageInfo +  
state such as package comment)
would make a lot of sense.


> Happy new years all !
> I'm digging right now on the way each of these packages, SM2, Kabungu
> and KomPackageBuilder tried to manage dependencies. I feel that each
> of one introduce some interesting idea, and I'm wondering in which
> extent they could work together.
> KomPackageBuilder: (see KomPackaging)
> - packages to load with an url format, I like the idea but KomPackage
> introduced new protocols like sqmap:// and sqpkg:// not necessary to
> my sense, something with http:// must be sufficient (and does not
> introduce too much Comanche-specific stuff).
> - notion of optionalPackages and prerequisite, you tell in your
> MyClassInfo which kind of prerequisite must be done, in an array
> format : #('PackageRequired'
> 'http://www.squeaksource.com/PackageRequired-xy.12.mcz')
> Kabungu:
> - lot of work done to handle dependencies issues, but as far as I
>   understand the code, the dependencies are setting up in a
>   centralized way. I personally think that it's wrong, each package
>   must know what are its own dependencies, this should be not the role
>   of a single package.
> SqueakMap2:
> - not clear for me how it handles dependencies right now, it seems
>   that it's not possible yet, but guess that göran is working hard to
>   get something on.
> Monticello is also managing dependencies, but is not 'url-oriented',
> it put every dependencies on the same repositories to handle
> dependencies. Since a lot of people are working with Monticello and
> squeakmap, maybe the way of managing dependencies should converge in a
> way or another. I noticed that PackageInfo seems to be the common
> point of all these packages, so I'm wondering if we should agree to
> use PackageInfo as the common platform to collaborate around the
> dependencies issues ? Or is it not the right place ?
> Samir

More information about the Squeak-dev mailing list