[Import-SIG] PEP 420: Implicit Namespace Packages
Nick Coghlan
ncoghlan at gmail.com
Mon Apr 23 03:08:55 CEST 2012
On Mon, Apr 23, 2012 at 9:51 AM, Michael Foord <fuzzyman at gmail.com> wrote:
> On 19 April 2012 21:18, Eric V. Smith <eric at trueblade.com> 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 | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG
mailing list