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
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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -