[Python-Dev] PEP 382: Namespace Packages (original) (raw)

P.J. Eby pje at telecommunity.com
Wed Apr 15 23:11:32 CEST 2009

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 instalrequires 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.)

More information about the Python-Dev mailing list