[Python-Dev] PEP 382: Namespace Packages

[P.J. Eby]

At 10:00 PM 4/15/2009 +0200, Tarek Ziadé wrote:
>Now for the "base" or "core" package, what peoplethat uses setuptools
>do most of the time:
>
>1- they use zc.buildout so they don't need a base package : they list
>in a configuration files all packages needed
>    to build the application, and one of these package happen to have
>the scripts to launch the application.
>
>2 - they have a "main" package that doesn't use the same namespace,
>but uses setuptools instal_requires metadata
>      to include namespaced packages. It acts like zc.buildout in some ways.
>
>For example, you mentioned atomisator.* in your example, this app has
>a main package called "Atomisator" (notice the upper A)
>that uses strategy #2

I think that there is some confusion here.  A "main" package or 
buildout that assembles a larger project from components is not the 
same thing as having a "base" package for a namespace package.

A base or core package is one that is depended upon by most or all of 
the related projects.  In other words, the dependencies are in the 
*opposite direction* from what you described above.  To have a base 
package in setuptools, you would move the target code from the 
namespace package __init__.py to another module or subpackage within 
your namespace, then make all your other projects depend on the 
project containing that module or subpackage.

And I explicitly excluded from my survey any packages that were 
following this strategy, on the assumption that they might consider 
switching to an __init__.py or __pkg__.py strategy if some version of 
PEP 382 were supported by setuptools, since they already have a 
"base" or "core" project -- in that case, they are only changing ONE 
of their packages' distribution metadata to adopt the new strategy, 
because the dependencies already exist.


>So :
>- having namespaces natively in Python is a big win (Namespaces are
>one honking great idea -- let's do more of those!)
>- being able to still write some code under the primary namespace is
>something I (and lots of people) wish we could do
>   with setuptools, so it's a big win too.

Yes, that's why I support Martin's proposal: it would allow 
setuptools to support this case in the future, and it would also 
allow improved startup times for installations with many 
setuptools-based namespace packages installed in flat form.  (Contra 
MAL's claims of decreased performance: adopting Martin's proposal 
allows there to be *fewer* .pth files read at startup, because only 
.pkg files for an actually-imported package need to be read.)