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]> >> wrote: >>> On Dec 8, 2008, at 9:02 AM, Benji York wrote: >>> >>>> On Sat, Dec 6, 2008 at 10:28 AM, Christian Zagrodnick <[EMAIL PROTECTED] >>>> > >>>> 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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )