On 2009-04-14 18:27, P.J. Eby wrote:
> At 05:02 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> I don't see the emphasis in the PEP on Linux distribution support and the
>> remote possibility of them wanting to combine separate packages back
>> into one package as good argument for adding yet another separate
>> hierarchy
>> of special files which Python scans during imports.
>>
>> That said, note that most distributions actually take the other route:
>> they try to split up larger packages into smaller ones, so the argument
>> becomes even weaker.
>
> I think you've misunderstood something about the use case. System
> packaging tools don't like separate packages to contain the *same
> file*. That means that they *can't* split a larger package up with your
> proposal, because every one of those packages would have to contain a
> __pkg__.py -- and thus be in conflict with each other. Either that, or
> they would have to make a separate system package containing *only* the
> __pkg__.py, and then make all packages using the namespace depend on it
> -- which is more work and requires greater co-ordination among packagers.
You are missing the point: When breaking up a large package that lives in
site-packages into smaller distribution bundles, you don't need namespace
packages at all, so the PEP doesn't apply.
The way this works is by having a base distribution bundle that includes
the needed __init__.py file and a set of extension bundles the add
other files to the same directory (without including another copy of
__init__.py). The extension bundles include a dependency on the base
package to make sure that it always gets installed first.
Debian has been using that approach for egenix-mx-base for years. Works
great:
http://packages.debian.org/source/lenny/egenix-mx-base
eGenix has been using that approach for mx package add-ons as well -
long before "namespace" packages where given that name :-)
Please note that the PEP is about providing ways to have package parts
live on sys.path that reintegrate themselves into a single package at
import time.
As such it's targeting Python developers that want to ship add-ons to
existing packages, not Linux distributions (they usually have their
own ideas about what goes where - something that's completely out-of-
scope for the PEP).
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Apr 14 2009)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
________________________________________________________________________
2009-03-19: Released mxODBC.Connect 1.0.1 http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
http://www.egenix.com/company/contact/
--
http://mail.python.org/mailman/listinfo/python-list
