Roger Ineichen wrote:
What do you do if version x.y works with d.e.d but not with d.e.e (because it's borken) and fixed in d.e.f.
This means you could use d.e.d or d.e.f. but not d.e.e
What's your solution then? Fix the version to d.e.d or d.e.f or skip fixing versions?
The version requirements in setup.py should specify only API compatibility. They have nothing to do with bug fixes; that's the domain of the KGS. How about an example. Let's say we have zope.schema version 5.2, which requires zope.interface version 4.1 because zope.interface version 4.0 has a different API. Let's also say that zope.interface version 4.1.5 has a bug that breaks zope.schema, but versions 4.1.4 and 4.1.6 are OK. Since that level of detail is burdensome and unnecessary for setup.py files, zope.schema should require "zope.interface >= 4.1" and let the KGS provide the finer detail. People who don't use a KGS will be fine because they'll get 4.1.6+ as soon as it's released.
Note; Not that fixing versions in a package is a bad thing in general. But such fixed versions will mess up the KGS that's the bad part. And since the KGS solves any kind of version conflict problems, there is no way to do it in a package anymore.
The KGS is too fine grained for many uses. I, for example, would like to use the latest z3c.form, but I really can't, because it relies on a bunch of other packages with revised APIs and the API requirements are not written anywhere. I don't care about bugs; I can fix bugs. What I can't do is read other developer's minds to discover API version requirements. Note that if I could use the current z3c.form, I would also be able to help develop it. Surely many other developers face similar circumstances. Thus I believe the Zope project is quietly missing opportunities for developers to get involved due to the lack of coarse-grained version requirements. Shane