Kabungu and KomPackageBuilder dependencies management
goran at krampe.se
goran at krampe.se
Tue Jan 3 22:33:07 UTC 2006
Samir Saidani <saidani at squeakfr.org> wrote:
> 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).
IMHO not interesting.
> - notion of optionalPackages and prerequisite, you tell in your
> MyClassInfo which kind of prerequisite must be done, in an array
> format : #('PackageRequired'
The notion is interesting. But having dependency information inside a
package version is IMHO wrong.
> - 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.
Kabungu is a synthesis of ideas from the planned model in SM and Lex's
Universes. After exchanging a bunch of emails with Michal I actually
liked it a lot and decided to "just use it" as the model for SM since I
felt it was quite close to my planned model anyway. The idea was to
leave the code for Michal to maintain. Then I think Michal decided to
not work with me, but I am not sure. So that kinda hangs in the air
right now. I might end up taking Kabungu and integrating it in SM
myself, or perhaps using it in combination with my own ideas.
> - 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.
Right. The latest release actually has some code in it - but nothing
more than that.
> 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 ?
Mmmm, I don't think it is the "right place". But note that Monticello
and SM has different needs.
The dependency model that SM will end up with (Kabungu or mine or a
synthesis or something else entirely) is meant for "published" releases
of packages. Monticello is much more fine granular being a development
But having said that it might very well end up merging together somehow.
For example, the MonticelloConfiguration files that people use more and
more should be added as a known package type in SM IMHO.
More information about the Squeak-dev