At 09:51 AM 4/15/2009 +0200, M.-A. Lemburg wrote:
On 2009-04-15 02:32, P.J. Eby wrote:
> At 10:59 PM 4/14/2009 +0200, M.-A. Lemburg wrote:
>> 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.
>
> If we're going to keep that practice, there's no point to having the
> PEP: all three methods (base+extensions, pkgutil, setuptools) all work
> just fine as they are, with no changes to importing or the stdlib.
Again: the PEP is about creating a standard for namespace
packages. It's not about making namespace packages easy to use for
Linux distribution maintainers. Instead, it's targeting *developers*
that want to enable shipping a single package in multiple, separate
pieces, giving the user the freedom to the select the ones she needs.
Of course, this is possible today using various other techniques. The
point is that there is no standard for namespace packages and that's
what the PEP is trying to solve.
> In particular, without the feature of being able to drop that practice,
> there would be no reason for setuptools to adopt the PEP. That's why
> I'm -1 on your proposal: it's actually inferior to the methods we
> already have today.
It's simpler and more in line with the Python Zen, not inferior.
You are free not to support it in setuptools - the methods
implemented in setuptools will continue to work as they are,
but continue to require support code and, over time, no longer
be compatible with other tools building upon the standard
defined in the PEP.
In the end, it's the user that decides: whether to go with a
standard or not.
Up until this point, I've been trying to help you understand the use
cases, but it's clear now that you already understand them, you just
don't care.
That wouldn't be a problem if you just stayed on the sidelines,
instead of actively working to make those use cases more difficult
for everyone else than they already are.
Anyway, since you clearly understand precisely what you're doing, I'm
now going to stop trying to explain things, as my responses are
apparently just encouraging you, and possibly convincing bystanders
that there's some genuine controversy here as well.
--
http://mail.python.org/mailman/listinfo/python-list
