I have taken down the zope.app.publisher 3.5.0a2 release from the cheese shop after being punished with the appropriate access. ;-) I suspect that will bite someone, but I think it will bite "the right" people. We'll see how this works out during the bot run tonight (an interactive test of installing zope.tal was promising). - C On Nov 16, 2007, at 10:49 AM, Chris McDonough wrote:
On Nov 16, 2007, at 9:25 AM, Jim Fulton wrote:
On Nov 14, 2007, at 8:23 AM, Chris McDonough wrote:
Attempting to easy_install all 'zope'-related releases using the script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.p... , the results were:
122 failures, 67 successes.
I guess most of these can be fixed by unscrewing the zope.traversing problem. Has anyone done that? Is anyone going to? :) If not, I will just cause I'm tired of reading about it. :(
I would, but I don't have access. I think we just need to take down the bogus zope.app.publisher 3.5.0a2 release.
I hate the idea of removing releases (because it "changes history"). But I suspect it's a better solution than releasing zope.app.publisher 3.5.0 and zope.traversing 3.5.0, where zope.app.publisher 3.5.0 depends on 'zope.traversing' instead of 'zope.traversing>=3.5.0a1.dev-r78730'. That would mean we're positing that that release actually works with everything else and I don't know if it does or doesn't.
Some of these errors are spurious. For example, ZODB4 shows up as a failure even though there are no distributions. I think the test script needs to check for this case.
I think the metadata on the cheeseshop needs to get cleaned up:
import xmlrpclib s = xmlrpclib.ServerProxy('http://www.python.org/pypi') s.package_releases('ZODB4') ['4.0a2']
http://pypi.python.org/pypi/ZODB4/4.0a2
I also think you should not list as failures anything that failes due to a gcc error. Often this will be due to the absense of libraries (e.g. spread).
Yep. I'll have to maintain the exclude list manually I think, because the failure output isn't necessarily regular.
- C