On Mon, Mar 16, 2009 at 10:24 AM, Martijn Faassen
<faas...@startifact.com> wrote:
> Stephan Richter wrote:
>> On Sunday 15 March 2009, Wichert Akkerman wrote:
>>> If the package does not work with an older version of zope.publisher
>>> than imho that version restriction *has* to be in setup.py.
>> And what if I backport the fix?
>> We have done version specification like this in the Zope packages before and
>> it almost brought development to complete halt, because versions would not
>> match anymore.
> I'm not sure I agree you here, Stephan. A possible disagreement within
> the steering group, how interesting! :)

> I think more specific open requirements (as opposed to the most widely
> open requirement) can be very useful. Useful to the maintainers of the
> Zope Framework KGS, the Zope 3 KGS, the Grok KGS, the Zope 2 KGS, and to
> application specific lists of packages, and users who are developing or
> testing packages in some other way. I've used this pattern quite
> successfully when developing a bunch of related packages.

I don't like version requirements in setup.py because they assume too
much about how people are using the package.

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

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.

If there were a way to ignore setup.py version requirements I'd be happy
to have them and ignore them.

Alternatively (my preference) the package would set versions in its
buildout using the KGS against which it works (plus any exceptions).
People could then refer to that to know what versions it actually works
with and they can verify that it works by running the tests.
Benji York
Senior Software Engineer
Zope Corporation
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to