yuppie wrote: > Hanno Schlichting wrote: >> In a package based world, if you specify a dependency on a package, you >> can in my opinion only rely on the package contents itself to be there. >> You cannot rely on its dependencies to stay around. > > I agree with you in general, but Zope2 is a special package because it > represents the Zope 2 platform and ships with a KGS.
I'm fine with giving the Zope2 package this special meaning of representing "the framework". As long as people don't mistake this as a general rule to say: Oh, I just use this with Zope2, so lets specify it as a dependency and don't think about it. If a package only depends on Acquisition, DateTime and zope.* packages it does no longer depend on "Zope2". I'd like to encourage people to look at their real dependency and be honest about those. Especially looking at things from the perspective of: "why does my package have a Zope2 dependency" instead of "I use this inside Zope2, so let's specify Zope2". The later information is where a classifier of "Framework::Zope2" is appropriate, the former is not. > Keeping all specified dependencies of all packages always up to date is > a big maintenance burden. Or do you have a tool that syncs the specified > dependencies with the code base automatically? I don't have a tool to do this. Personally I think specifying dependencies is the same as keeping a changelog updated or being strict about version numbers - it's the extra administrative burden you get, for making things into a package and offering it for reuse. Hanno _______________________________________________ Zope-CMF maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests
