On Dec 8, 2008, at 10:52 AM, 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
>> 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
> 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 newer
> 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
> 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.
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -