[Distutils] namespace_package

KP patter001 at gmail.com
Wed Dec 2 21:46:23 EST 2015


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 at gmail.com
> wrote:

> Hi KP,
>
> On Dec 1, 2015, at 4:17 AM, KP <patter001 at 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 at gedmin.as> 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
>>
>>     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 at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20151202/61e3288d/attachment.html>


More information about the Distutils-SIG mailing list