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

[Gary Poster]

On Dec 8, 2008, at 12:23 PM, Tres Seaver wrote:

> -----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.
>
>> 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.

Thank you for taking the time to think through and clearly describe  
the position I share, Tres.

Gary