Previously Chris Withers wrote:
Benji York wrote:
Lets say that someone adds two bug fixes to zope.foo (call them fix A and fix B) and then does a release. Fix A requires zope.bar >= 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 zope.bar.
I don't think that's your call to make, it's the maintainer of zope.foo'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 setup.py 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. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.