Re: PEP 420: Implicit Namespace Packages

On Mon, Apr 23, 2012 at 9:51 AM, Michael Foord <[email protected]> wrote:
> On 19 April 2012 21:18, Eric V. Smith <[email protected]> wrote:
>>
>> This reflects (I hope!) the discussions at PyCon. My plan is to produce
>> an implementation based on the importlib code, and then flush out pieces
>> of the PEP.
>>
>> In particular, I want to make sure the PEP addresses the various
>> objections that were raised, especially by Nick.
>>
>
> So a namespace package is a directory (tree) on sys.path. For a standard
> Python install how will these be installed?
>
> If you need to install "foo.bar" and "foo.baz" will distutils and packaging
> do the right thing? (And what specifically is the right thing for Python's
> own package management tools - merging the namespace packages or keeping
> them separate somehow?)

<lib_dir>/site-packages/foo/bar
<lib_dir>/site-packages/foo/baz

The whole point of dropping the __init__.py file requirement is that
merging the namespace portions becomes trivial, so you don't need to
worry about sys.path hackery in the normal case - you can just install
them into a common directory (adding it on install if it doesn't exist
yet, removing it on uninstall if the only remaining contents are the
__pycache__ subdirectory).

However, for zipfile distribution, or running from a source checkout,
you could instead provide them as <app_dir>/foo/bar and
<app_dir>/foo/baz and they would still be accessible as "foo.bar" and
"foo.baz". Basically, PEP 420 should mean that managing subpackages
and submodules becomes a *lot* more like managing top level packages
and modules.

Agreed the packaging implications should be specified clearly in the
PEP, though (especially the install/uninstall behaviour when namespace
portions get merged into a single directory).

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia