yes, both of those statements are true.However, with the namespace_packages = ['foo'], the lib\site-packages\foo\__init__.py does not get installed (even though it is in the source tree). Instead there's just a dir with "foo/bar/__init__.py" and "foo/blah/__init__.py". I will try to look in the "wheel" side of things next I guess. Perhaps pip is doing something since it seems to install even source distributables by first converting to a wheel.On Tue, Dec 1, 2015 at 1:38 AM, Marius Gedminas <email@example.com> wrote:_______________________________________________On Mon, Nov 30, 2015 at 06:59:31PM -0500, KP wrote:
> I'm not sure where the issue is, but when I specify a namespace_package in
> the setup.py file, I can indeed have multiple packages with the same base
> (foo.bar, foo.blah, etc...). The files all install in to the same
> directory. It drops the foo/__init__.py that would be doing the
> extend_path, and instead adds a ".pth" file that is a bit over my head.
> The problem is that it does not seem to traverse the entire sys.path to
> find multiple foo packages.
Does every foo.x package specify namespace_packages=['foo']?
Do they all ship an identical foo/__init__.py with
AFAIU you need both things in every package, if you want to use
> If I do not specify namespace_packages and instead just use the
> pkgutil.extend_path, then this seems to allow the packages to be in
> multiple places in the sys.path.
> Is there something additional for the namespace_package that i need to
> specify in order for all of the sys.path to be checked?
> I'm using 18.5 setuptools....but I am not sure if this somehow ties in to
> wheel/pip, since I'm using that for the actual install.
Give a man a computer program and you give him a headache, but teach him to
program computers and you give him the power to create headaches for others for
the rest of his life...
-- R. B. Forest
Distutils-SIG maillist - Distutils-SIG@python.org