[Distutils] Bilingual namespace package conundrum

[Barry Warsaw]

On Jan 03, 2015, at 03:09 AM, Nick Coghlan wrote:

>This was the intended solution when PEP 420 was written - we deliberately
>didn't break old-style namespace packages, we just made them redundant for
>code that only needs to run on 3.3+. This is much easier to learn, since it
>means creating packages as subdirectories "just works", and automatically
>collecting all search path subdirectories with a given name into a common
>namespace by default better matches the typical behaviour of other search
>path based explicit import systems.
>
>However, implicit namespace packages aren't inherently *better* than the
>old explicit ones at runtime, as the end result is the same in either case:
>a module.__path__ entry that contains multiple directories. The only
>difference is in whether you get there by leaving out __init__.py and
>letting the 3.3+ import machinery handle it, or by doing it explicitly
>yourself.
>
>That means there's a bug to be fixed in the lazr packages - they provide an
>__init__.py file, thus turning off the implicit namespace package support,
>but then they use a version check to also turn off the explicit namespace
>package support. If you turn off both kinds of namespace package support,
>you're not going to have a namespace package at the end of it :)

While I agree that the lazr package's __init__.py files should not have the
version checks (and I've released fixes for the few that I care about
immediately), I still think it could make sense for better support in the
Python installation tools to support PEP 420 namespace packages.

FWIW, the Debian packaging tools explicitly remove namespace package
__init__.py files from portions when they are built for Python 3 (let's assume
we don't care about any Python 3 that doesn't support PEP 420).  We've not had
any problems with this that I know of.

I suppose with a working old-style namespace __init__.py file, there's little
practical effect, but for consistency it makes sense.  One reason would be
introspection tools, which would see a different set of attributes for
`dir(lazr)` in the two cases, one where lazr is a concrete package and the
other where it's a virtual/namespace package.

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/20150106/6d6e24e9/attachment.sig>