[Python-Dev] PEP 382: Namespace Packages
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 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.
>- 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