[Zope-dev] [Checkins] SVN: zope.testbrowser/trunk/ - Switched to Zope 3.4 KGS.

[Christian Zagrodnick]

On 2008-12-08 18:23:33 +0100, Tres Seaver <tseaver at palladion.com> said:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Benji York wrote:
>> On Mon, Dec 8, 2008 at 9:18 AM, Gary Poster <gary.poster at gmail.com> wrote:
>>> On Dec 8, 2008, at 9:02 AM, Benji York wrote:
>>> 
>>>> On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick <cz at gocept.com>
>>>> wrote:
>>>>> Log message for revision 93722:
>>>>> - Switched to Zope 3.4 KGS.
>>>>> 
>>>>> - New lines are no longer stripped in XML and HTML code contained in a
>>>>> textarea; requires ClientForm >= 0.2.10 (LP #268139).
>>>> This revision make the buildout fail with
>>>> 
>>>> Error: Couldn't find a distribution for 'ClientForm>=0.2.10'.
>>>> 
>>>> I suspect you had that version of ClientForm in your cache and didn't
>>>> realize that it is not available in the KGS index.
>>>> 
>>>> Even if we fixed that, I don't want to require a particular version of
>>>> ClientForm in testbrowser.  There's no need to impose a newer version on
>>>> people who don't need it.  Anyone who does need the bug fix can specify
>>>> the newer version in their project.
>>> FWIW, I disagree.  The specification that you removed is exactly the sort of
>>> thing that I think is appropriate in setup.py.  The tests will now fail (I
>>> assume, since I believe Christian Z added testbrowser tests for the failure
>>> caused by the ClientForm bug) with a lower version of ClientForm, so it is
>>> appropriate to set the value in setup.py.
>> 
>> Nope, the tests will pass in the zope.testbrowser buildout.
> 
> Having tests which pass only in that buildout is an "attractive
> nuisance":  I'm seeing test failures in the version of zope.testbrowser
> linked into the Zope2 trunk, for instance.
> 
> If the behavior of zope.testbrowser is broken in the absence of a
> sufficiently-recent version of ClientForm, then that behavior should be
> spelled out in setup.py's dependencies:  that is what they are for.

That's the way I think of it, too. Also the bug introduced by an older 
ClientForm is so subtle that it is not immediately obvious that it is 
the testbrowser which is broken. It may if you just got an upgrade, but 
not if you setup your things and it just behaves strange.


> 
>> However, if a testbrowser user for some reason run the testbrowser tests
>> outside of its buildout, then you're right, they may see a failure if
>> their versions aren't new enough.  At that point I would hope they would
>> read the CHANGES.txt and see that a new version is required.
>> 
>> The trade off is in requiring people to upgrade a dependency in order to
>> get a bug fix that they may not care about.
>> 
>> In the large, this is the problem with specifying versions in setup.py.
>> Doing so assumes too much about how people are using all the
>> dependencies involved.
>> 
>> Here's a scenario:  I fix a bug in some package, it depends on a newer
>> version of say, zope.publisher.  I put that requirement in my package's
>> setup.py.  A user of my package upgrades to get an unrelated bug fix and
>> is forced to use the newer zope.publisher.  It so happens that that the
>> new version of zope.publisher has a different bug that bites them.  They
>> now are in a bad spot.
> 
> A user of your package cannot rely on automatic dependency resolution in
> this case:  your package is broken without the new version of its own
> dependency, so they can't upgrade to it.
> 
> Stripping all versions from the dependencies in setup.py only works if
> users are willing to run their own package indexes, and figure out edge
> cases such as the ones you describe by themselves:  at that point,
> forking the egg to drop the manually-resolved extra dependency is a
> minor nuisance.

Agreed.



-- 
Christian Zagrodnick · cz at gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development