It appears that the .pth file only adds the lib/site-packages/foo/ module to the path, so that part _works_ but that seems to only work for modules installed in to lib/site-packages. So if I do something like: foo.bar having this setup.py setup(name="foo.bar", version=str(__version__), packages=["foo","foo.bar"], namespace_packages=['foo'], ) To go with this package there's a couple of possible use cases: 1. --- simple pth file point to another participant in this name space package -- But I also have a pth file with: c:\test And the directory contents of C:\Test are: c:\test\foo\__init__.py # and this as the typical pkgutil.extend_path c:\test\foo\more\__init__.py The import mechanisms only find the "foo.bar" I installed and not the foo.more 2. -- is similar to #1, but maybe slightly more accepted normal...assume the same "foo.bar", and the setup.py provide. If I'm working on another "foo.more" package that participates in this namespace package, then an pip install from the source will _not_ work. The workaround I posted earlier (an additional package that is NOT a namespace package, and is needed to force an __init__.py to exist in lib/site-packages/foo). This works, but it feels like a bit of a hack, and that the the "-pkg.pth" created for foo.bar should have worked. (work = allow namespace packages in multiple directories that are in sys.path) On Wed, Dec 2, 2015 at 12:17 AM, Zvezdan Petkovic <zvezdanpetkovic@gmail.com
wrote:
Hi KP,
On Dec 1, 2015, at 4:17 AM, KP <patter001@gmail.com> wrote:
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).
This is exactly how it’s supposed to behave for namespace packages. The *.pth file will take care of providing info about your namespace to the python importer.
Instead there’s just a dir with "foo/bar/__init__.py" and "foo/blah/__init__.py".
These are regular packages. Hence they preserve their __init__.py. Hope this helps.
Regards,
Zvezdan
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 <marius@gedmin.as> 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
On Mon, Nov 30, 2015 at 06:59:31PM -0500, KP wrote: 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
import pkg_resources pkg_resources.declare_namespace(__name__)
?
AFAIU you need both things in every package, if you want to use namespace packages.
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.
Marius Gedminas -- 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 https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig