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 wrote: Hi KP, On Dec 1, 2015, at 4:17 AM, KP 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 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