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
Hi samir
indeed I would like to see an easy and powerful way to deal with dependencies. 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 configuration.
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.
Stef
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
Hi!
Samir Saidani saidani@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' 'http://www.squeaksource.com/PackageRequired-xy.12.mcz')
The notion is interesting. But having dependency information inside a package version is IMHO wrong.
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.
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.
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.
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 ?
Samir
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 tool.
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.
regards, Göran
- 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')
The notion is interesting. But having dependency information inside a package version is IMHO wrong.
Yeap
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.
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.
Goran would that mean that it would be integrated with PI? For me I would like to get dependency to manage well packages at squeaksource level and not only at map level.
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.
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 ?
Samir
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 tool.
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.
Indeed they serve as config files. May be this is a good way to do it. We do not use them to manage 3.9 since we have to linearize the packages and sometimes this is not working (because of circular dependencies and this shortcut MC loading power (all classes of a class bunch of packages are loaded without taking take of package boundaries and this helps especially when you have a tangled system like Squeak).
Stef
squeak-dev@lists.squeakfoundation.org
-
goran＠krampe.se -
Samir Saidani -
stéphane ducasse