Previously Chris Withers wrote:
> Benji York wrote:
> > Lets say that someone adds two bug fixes to (call them fix A
> > and fix B) and then does a release.  Fix A requires >= 1.5 and
> > fix B doesn't.  If I want to benefit from fix B in my app (and don't use
> > the feature fix A repaired), then I shouldn't be forced to upgrade
> >
> I don't think that's your call to make, it's the maintainer of 
>'s call.
> > Another way to look at it: Just because a package's test suite won't
> > pass without a particular version of a dependency doesn't mean that
> > every user of the package needs that version of the dependency.
> WRONG! If you use a package, you need to accept that its dependencies 
> are decided by its author. Guessing that you know better than its author 
> is a very dangerous game and leads to a path where you might as well not 
> bother using a package manager at all and just go back to hit'n'hope...
> > If there were a way to ignore version requirements I'd be happy
> > to have them and ignore them.
> Wow...
> > Alternatively (my preference) the package would set versions in its
> > buildout using the KGS against which it works (plus any exceptions).
> KGS will be a zope dead-end imnsho... It's useful, but I don't see 
> anyone outside the Zope community caring about it...

This is an important point. As I see it the KGS is a Zope-only thing,
and is just a workaround for the mindless behaviour of setuptools. I do
not see it gaining acceptance outside of the Zope community, and imho
effort is better spent on improving the packaging tools.


Wichert Akkerman <>    It is simple to make things.                   It is hard to make things simple.
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to