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

[Gary Poster]

On Dec 8, 2008, at 10:52 AM, 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.

That's not what I said. :-)

> 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.
>
> If the setup.py hadn't specified a version then the programmer could
> have constructed a set of versions that didn't exhibit any bugs that
> bite them, but they're precluded from doing that.

There are always scenarios with problems in which code depends on  
other packages.  I disagree with your argument, but if no-one else  
agrees with me I'm fine.

Gary