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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
