[Python-Dev] PEP 382: Namespace Packages
P.J. Eby
pje at telecommunity.com
Fri Apr 3 05:12:18 CEST 2009
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.)
More information about the Python-Dev
mailing list