> 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.
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests