iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Another improvement by Nick: a better description of splitting portions among multiple directories.

This commit is contained in:
Eric V. Smith 2012-04-20 06:20:24 -04:00
parent ce4af70258
commit 661887ade7
1 changed files with 14 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
pep-0420.txt
View File

@ -84,19 +84,20 @@ doesn't. Likewise, setuptools supports inspecting zip files, and
supports adding portions to its _namespace_packages variable, whereas
pkgutil doesn't.
Namespace packages need to be installed in one of two ways: either all
portions of a namespace will be combined into a single directory (and
therefore a single entry in sys.path), or each portion will be
installed in its own directory (and each portion will have a distinct
sys.path entry).
The current imperative approach causes problems for system vendors.
Vendor packages typically must not provide overlapping files, and an
attempt to install a vendor package that has a file already on disk
will fail or cause unpredictable behavior. As vendors might choose to
package distributions such that they will end up all in a single
directory for the namespace package, all portions would contribute
conflicting __init__.py files.
Namespace packages are designed to support being split across multiple
directories (and hence found via multiple sys.path entries). In this
configuration, it doesn't matter if multiple portions all provide an
``__init__.py`` file, so long as each portion correctly initializes
the namespace package. However, Linux distribution vendors (amongst
others) prefer to combine the separate portions and install them all
into the *same* filesystem directory. This creates a potential for
conflict, as the portions are now attempting to provide the *same*
file on the target system - something that is not allowed by many
package managers. Allowing implicit namespace packages means that the
requirement to provide an ``__init__.py`` file can be dropped
completely, and affected portions can be installed into a common
directory or split across multiple directories as distributions see
fit.
Specification
=============