[Distutils] namespace packages (and PEP 382)

P.J. Eby pje at telecommunity.com
Sun Apr 25 03:34:51 CEST 2010

At 02:45 PM 4/24/2010 +0900, David Cournapeau wrote:
>Is there a
>design document or something else decribing how the namespace
>mechanism works for setuptools ? I would like to support namespace
>package in my own packaging project, but it is not clear to me what
>needs to be done on my side of things.

Namespace packages in *Python* are the result of adding entries to a 
package's '__path__' attribute.  By default, the list only has one 
entry - if you make it have one for each directory (or zipfile 
subdirectory) that contains modules for that package, then presto, 
you have a namespace package.

How you get those entries in __path__ is the only real difference 
between pkgutil, pkg_resources, and the upcoming PEP 382.  (Well, 
there's also the nspkg.pth hack, which I'd just as soon do away with 

I'm thinking that in 0.7 I may add a PEP 382 emulation module 
(separate from pkg_resources) for older versions of Python, as it 
would allow some odd bits to be dispensed with in pkg_resources.

For example, declare_namespace could simply add a '*' to the __path__ 
of the right package(s), and the nspkg.pth files could just make sure 
the PEP 382 emulation was loaded, without needing to set up fake 
package modules.  Other pkg_resources APIs that rely on an internal 
list of namespace packages could just look in sys.namespace_packages, 
and so on.

One thing that's not entirely clear at the moment in PEP 382, though, 
is that it doesn't really specify how the other sys.path entries are 
found and mapped -- presumably it's something like 
os.path.join(syspathentry, *pkgname.split('.')) -- but the handling 
for such path entries isn't really described.  In a Python version 
where NullImporter exists (2.5+), though, the cost of extra 
nonexistent __path__ entries is negligible, so I suppose filtering 
the entries for directory existence and the presence of other .pth 
files isn't necessary.

The PEP should probably be clearer on this point, though - i.e., both 
on what exactly goes in __path__, as well as whether .pth files are 
read in the other paths, and whether .pth files are needed on any 
other paths.  (I also wonder if other .pth contents besides '*' 
really need to be supported anyway; I expect it would depend on 
whether anybody is using the .pkg files allowed by extend_path()...)

More information about the Distutils-SIG mailing list