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 <[EMAIL PROTECTED]>
>>> On Dec 8, 2008, at 9:02 AM, Benji York wrote:
>>>> On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick <[EMAIL PROTECTED]
>>>>> 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
>>>> 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
>>>> 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
> 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
> spelled out in setup.py's dependencies: that is what they are for.
>> However, if a testbrowser user for some reason run the testbrowser
>> 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
>> 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
>> 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
>> version of say, zope.publisher. I put that requirement in my
>> 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
>> new version of zope.publisher has a different bug that bites them.
>> 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
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -