[Interface-dev] Separate zope.interface package

[Fred Drake]

On Tuesday 15 June 2004 03:39 pm, Tim Peters wrote:
 > Is this really a serious bug?  I find no uses of extend_path in Python,
 > Zope 2, or Zope 3; indeed, it appears to be used only once across all the
 > code Google knows about.

I removed the only call to this from Zope 3 when we realized this bug existed.  
We would be using it for both the "zope" and "zope.app" packages were it not 
for the bug.

 > If it is a serious bug, it's going to require new C code in Python to fix
 > it (see case_ok() in import.c -- the way to check for case match on
 > case-insensitive filesystems varies wildly across such systems, and
 > requires invoking platform-specific C functions (e.g., the Win32
 > FindFirstFile() on Windows); the very hairy case_ok() could be reused, but
 > not without refactoring the C source to expose it to Python code).

Yes, I understand that.  We'd like to be able to install zope.app sub-packages 
in an instance home, even though the main body of zope.app is installed in 
the software home.  Two possible solutions are to have the __init__.py for 
both the zope and zope.app packages call pkgutil.extend_path(), and rolling a 
Zope-specific solution that's sensitive to the specific layouts of software 
and instance homes.  The later seems more fragile, and breaks as soon as we 
attempt to use it in a FrankenZope on Windows.


  -Fred

-- 
Fred L. Drake, Jr.  <fred at zope.com>
PythonLabs at Zope Corporation