[Zope-dev] setting missing minimum version in setup.py

[Shane Hathaway]

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