[Distutils] Proper handling of PEP420 namespace packages with setuptools and pip

Barry Warsaw barry at python.org
Wed Apr 22 23:41:45 CEST 2015


On Apr 23, 2015, at 07:08 AM, Robert Collins wrote:

>PEP-420 and legacy packages being mixed for one namespace doesn't work at all
>today - in principle fixable via changes to both setuptools and importlib -
>but it was about here that the other openstack folk said 'ok wow, lets just
>stop using namespace packages :)

I think this is actually by design, despite what PEP 420 says.  If you have a
portion that contains an __init__.py, that basically overrides any namespace
portions found on sys.path.  It's all or nothing.

Now, were this comes up for me is in bilingual code.  I have some namespace
packages (e.g. flufl.*) which should live in the same parent package even if
the portions live in distinct directories.  Each package has an __init__.py
that stitches things together for Python 2 (using the various common hack
recipes), but of course installing this package in Python 3 means they aren't
namespace packages, and this makes me sad.

I wish there was some kind of exception or marker I could put in the
flufl/__init__.py files that signaled PEP 420-aware Python 3s to treat it as
if the __init__.py doesn't exist.

In the Debian ecosystem, we solve this with package builder help.  The
standard helpers will actually not include the top-level __init__.py file for
the Python 3 binary package version, so they'll be stitched-together
namespace-ish for Python 3 and straight up PEP 420 namespace packages for
Python 3.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150422/a4d1371d/attachment.sig>


More information about the Distutils-SIG mailing list