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.


> > 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.

Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists -
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to