[Import-SIG] PEP 402: specification questions
pje at telecommunity.com
Thu Nov 10 19:25:39 CET 2011
On Thu, Nov 10, 2011 at 1:03 PM, "Martin v. Löwis" <martin at v.loewis.de>wrote:
> > Actually, scratch that part of my response. *Existing* namespace
> > packages that work properly already have a single owner
> How so? The zope package certainly doesn't have a single owner. Instead,
> it's spread over a large number of subpackages.
In distro packages (i.e. "system packages") there may be a
namespace-defining package that provides an __init__.py. For example, I
believe Debian (system) packages peak.util this way, even though there are
many separately distributed peak.util.* (python) packages.
> With PEP 402, those owning packages are the only ones that would have
> > to change.
> No. In setuptools namespace packages, each portion of the namespace
> (i.e. each distribution) will have it's own __init__.py; which of them
> gets actually used is arbitrary but also irrelevant since they all look
> the same.
> So "only those" is actually "all of them".
Nick is speaking again about system packages released by OS distributors.
A naive system package built with setuptools of a namespace package will
not contain an __init__.py, but only a .nspkg.pth file used to make the
(In this sense, the existing setuptools namespace package implementation
for system-installed packages is actually a primitive partial
implementation of PEP 402.)
In summary: some system packages are built with an owning package, some
aren't. Those with an owning package will need to drop the __init__.py
(from that one package), and the others do not, because they don't have an
__init__.py. In either case, PEP 402 leaves the directory layout alone. A
version of setuptools intended for PEP 402 support would drop the nspkg.pth
inclusion, and a version of "packaging" intended for PEP 402 would simply
not add one.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Import-SIG