[Distutils] __init__.py getting left out of mpkg

[Phillip J. Eby]

At 02:29 PM 3/6/2007 -0500, jason pellerin wrote:
>I've been meaning to ask about this same issue, specifically with
>respect to namespace packages, bdist_rpm and imp. I've had to patch
>the spec files for all namespace packages that we build as RPMs, since
>although the .pth file works when using import or __import__, imp
>doesn't seem to recognize it, and that breaks Paste's app loading.

Then Paste's app loading is broken, and wouldn't work with an egg either, 
if it's using "imp" and ignoring the package's __path__.


>So
>I have to have the RPMs put a dummy __init__.py in the package --

Make sure it includes a namespace declaration, or other things will 
break.  And of course you must only include this __init__.py for *one* 
member of the namespace package.


>which has problems of its own, but at least leaves me with a
>functional install.
>
>I'm wondering if it's a known issue that imp can't/doesn't use .pth
>files,

It doesn't - it's on a completely different level of the import 
structure.  However, any sanely-written use of "imp" should respect the 
__path__ that's set up by the .pth file.  So either Paste is broken, or the 
application using Paste is being run with python -s, disabling the import 
of the "site" module, and thereby the activation of .pth files and 
site-packages.  However, if import is working in the same environment (same 
Python options, etc.), then it's Paste that's broken.

>and if so, is there any other way to handle namespace packages
>in --single-version-externally-managed besides .pth files?

I truly wish there were.  But .pth files were the best I could come up with 
to make the silly thing work at all, without requiring every piece of a 
namespace pacakge to depend on a package whose only content is the 
__init__.py file.