patter001 at gmail.com
Tue Dec 1 16:31:27 EST 2015
(sorry for the stupid previous early send)
Just to recap:
1. if you don't put namespace_packages in the setup.py, then it will
uninstall the shared __init__.py when you uninstall any of the packages
2. If you put namespace_packages, then there is a pth file created for the
shared directory (site-packages/foo) and no foo/__init__.py is created
(even if it is in your package)
#2 - breaks things like : doing a source checkout that participates in this
namespace_package...If you do this then only the
lib/site-packages/foo/<modules> are importable
Solution appears to be:
create a standalone "foo" package that has ONLY the shared __init__.py, and
do NOT set "namespace_packages" . This seems to associate the __init__.py
with the "foo" tool, so that only when you uninstall the "foo" tool does
the __init__.py get uninstalled. It also has the shared __init__.py in
lib/site-packages, so it seems that enables the other namespace packages
that are source checkouts or added to path via other methods.
Hopefully this works long term, and maybe is useful to someone else out
On Tue, Dec 1, 2015 at 4:29 PM, KP <patter001 at gmail.com> wrote:
> Just to recap:
> 1. if you don't put namespace_packages in the setup.py, then it will
> uninstall the shared __init__.py when you uninstall any of the packages
> 2. If you put namespace_packages, then there is a pth file created for
> the shared directory (site-packages/foo) and no foo/__init__.py is created
> (even if it is in your package)
> #2 - breaks things like : doing a source checkout that participates in
> this namespace_package...If you do this then only the
> lib/site-packages/foo/<modules> are importable
> Solution appears to be:
> On Tue, Dec 1, 2015 at 7: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). 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 <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
>>> > (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
>>> 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
>>> > 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
>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Distutils-SIG