[Interface-dev] Separate zope.interface package

[Tim Peters]

[Fred Drake]
...
> - Python's difficulty in dealing with packages that are split across
> multiple locations (where len(__path__) > 1); the pkgutil bug should be
> seen as quite serious, I think, but there have been no followups other
> than my own:
>
>     http://www.python.org/sf/935117

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.

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

> ...
> We should determine what requirement we have for separate releases.  I
> think for ZC the biggest issue is for everyone to be on the same page
> about what zope.interface is, which means there should be one release
> authority, and other ZC code should rely only on published releases.

The part of this that doesn't work in practice is that clients of published
releases don't update to new releases -- they don't have time, or implicitly
expect you (the release maker) to integrate new releases for them.  Guess
how often I've integrated the ZConfig trunk into ZODB since we switched to
SVN; it's exactly as often as the Zope trunk has integrated a ZODB release
since then.