On Friday 16 November 2007, Chris McDonough wrote:
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.
What's you PyPI username. I can give you access. BTW, I developed a small tool that makes it easy to grant and revoke access to packages in PyPI called zope.pypisupport (http://svn.zope.org/zope.pypisupport/).
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.
+1
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.
Yeah, in the KGS I had to do the same. Some packages depend on stuff that is not yet fulfilled by the packages. For example, at least in buildout, the generated pyc files do not point to the correct py source files. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training