[Python-Dev] PEP 382: Namespace Packages

[P.J. Eby]

At 03:21 AM 4/3/2009 +0200, Matthias Klose wrote:
>+1 speaking as a downstream packaging python for Debian/Ubuntu I 
>welcome this approach.  The current practice of shipping the very 
>same file (__init__.py) in different packages leads to conflicts for 
>the installation of these packages (this is not specific to dpkg, 
>but is true for rpm packaging as well). Current practice of 
>packaging (for downstreams) so called "name space packages" is: - 
>either to split out the namespace __init__.py into a 
>separate    (linux distribution) package (needing manual packaging 
>effort for each    name space package) - using downstream specific 
>packaging techniques to handle conflicting files    (diversions) - 
>replicating the current behaviour of setuptools simply overwriting 
>the    file conflicts. Following this proposal (downstream) 
>packaging of namespace packages is made possible independent of any 
>manual downstream packaging decisions or any downstream specific 
>packaging decisions

A clarification: setuptools does not currently install the 
__init__.py file when installing in 
--single-version-externally-managed or --root mode.  Instead, it uses 
a project-version-nspkg.pth file that essentially simulates a 
variation of Martin's .pkg proposal, by abusing .pth file 
support.  If this PEP is adopted, setuptools would replace its 
nspkg.pth file with a .pkg file on Python versions that provide 
native support for .pkg imports, keeping the .pth file only for older Pythons.

(.egg files and directories will not be affected by the change, 
unless the zipimport module will also supports .pkg files...  and 
again, only for Python versions that support the new approach.)