[Distutils] namespace_packages: include itself ot not include

[P.J. Eby]

At 10:29 PM 2/8/2011 +0300, Roman Kurakin wrote:
>There is a package 'aaa.bbb' that uses setuptool only if it is  installed on
>the system.

In that case, it can't sensibly use setuptools namespace 
packages.  At all.  You need to either:

1. always use setuptools
2. use an alternate namespace package mechanism (such as 
pkgutil.extend_path()), and not declare the namespace
3. Not use namespace packages at all


>This is useful for development, but this breaks rpm build
>process cause it expects __init__.py and doesn't expect egg and pth,
>more over it ignores them. So in my case there is no egg & pth.

The nspkg.pth file is for non-egg installs.  If you have an egg, 
there is no nspkg.pth file for that package.


>I started to dig if there is possibility to coexists development and rpmbuild
>processes on the same system without very messy spec file. I didn't find
>the strict requirements for the package to list itself in a namespace_package
>even if I know that there would be 'aaa.bbb.ccc'.

It is a requirement for consistent and correct runtime behavior 
across all installation targets.  (The installation targets are .egg 
file, .egg-directory, and non-egg (e.g. rpm))


>So probably question does it break something if package 'aaa.bbb'
>wouldn't list itself in a namespace_package? And does it provide something
>useful if package 'aaa.bbb' would?

To make sure we're clear: if aaa.bbb is actually a namespace -- that 
is, if it has separately-installable contents -- then you MUST 
declare it if you want consistently correct runtime behavior.

If you do not declare it, then there are some environments where it 
will appear to work, and there will be other (superficially 
identical) environments where some part of the namespace will 
mysteriously fail to be importable.

In other words, the rules are there for a reason.  These limitations 
are the nature of Python 2.x's import machinery, which was not 
originally designed with namespace packages in mind.

There is a namespace package PEP that (in principle) provides a 
better mechanism than what setuptools does, but implementation 
progress is currently stalled, and the PEP has not been 
accepted.  So, your options at the present time for separately 
installed parts of a namespace package are as I have described.

There is a pure distutils approach you can use that allows partially 
installed packages to exist, but it is somewhat fragile and is not 
setuptools compatible.  It requires that there be a "provider" of a 
package, in the sense that exactly one project contains the 
__init__.py for the package.  But it is fragile because it may not be 
supported on all platforms and build targets, and it requires that 
aaa.bbb be always installed before aaa.bbb.ccc....  but of course the 
distutils by themselves have no dependency mechanism to enforce this.