[Distutils] namespace_packages: include itself ot not include

[Roman Kurakin]

P.J. Eby wrote:
> At 12:06 AM 2/8/2011 +0300, Roman Kurakin wrote:
>> but one is initial provider of 'aaa' share
>> and other consumer of 'aaa' share.
>
> This statement is why you're confused.  A namespace is not "provided" 
> by anyone, only participated in.
No I am confused by practice :-) . The problem I am thinking about is 
__init__.py.
So __init__.py is my namespace provider I thinking of beside the scene. The
problem I hit was with rpm packages I was playing with. The package 
'aaa.bbb'
list itself in namespace_packages and developer states that this is 
needed cause
there is 'aaa.bbb.ccc' package. In this case, installer drops 
__init__.py not only
for aaa/__init__.py but also for aaa/bbb/__init__.py. For 'aaa' this is 
correct
since some one should provide __init__.py for 'aaa' before us. But who will
provide __init__.py for 'aaa.bbb' if we pack it as setuptool provided it 
for us?
> Think of it this way.  You and I decide to have lunch together.  I am 
> not providing the lunch.  You are not providing the lunch.  But we are 
> both participating in the lunch.
>
> That is how namespace packages work.  aaa.bbb participates in the aaa 
> namespace, therefore it lists aaa as a namespace package.
But what about 'aaa.bbb' that lists itself as a namespace package?
Should it list itself or not? In case it should, the question is how to
deal with __init__.py?

That is why I tried to draw such model with providers and extenders.
One should make reservation if lunch is planned in some popular place.

rik
>
> Better, a concrete example.  zope.interface participates in the zope 
> namespace package, so it lists 'zope' in namespace_packages.  There is 
> no "zope" package that stands by itself, there are only zope.* 
> packages that together participate in the zope namespace.
>
>> Why 'aaa.bbb' should even know that there is, or
>> will be any other, for example 'aaa.bbb.ccc'?
>
> It would only do this if you indeed planned to have that happen.
>
> For example, I have a 'peak.util' namespace package.  There are many 
> projects, such as DecoratorTools, Importing, and so forth on PyPI that 
> provide modules in that namespace.  DecoratorTools is 
> peak.util.decorators, Importing is peak.util.imports, and so on.
>
> There is NO peak.util package, however.  You cannot download peak.util 
> someplace, because it is a *namespace* package.
>
> The entire point of a namespace package is that it's just a name, and 
> NOT an actual package.  You would never import anything directly from 
> peak.util, because it's just a place where other packages live.
>
> "peak" is also a namespace package, and there are other projects that 
> contribute modules and subpackages to that namespace.
>
>> In a simple case 'shared' is a little bit confusing in case we are 
>> 'extending'
>> namespace via strict hierarchy aaa.bbb, aaa.ccc, aaa.bbb.ddd etc. Where
>> any of packages are initial providers of their own namespaces. 'aaa' and
>> 'aaa.bbb' share 'aaa' namespace, but one is initial provider of 'aaa' 
>> share
>> and other consumer of 'aaa' share.
>
> Namespace packages don't work like that.  All participants in a 
> namespace are *equal peers*, not "base plus extensions".
>
> Sure, you can DO it, but the tools don't have any notion that one 
> package is the base and another is the extender.  That's why you're 
> getting confused: you are thinking "base and extension", but namespace 
> packages are peer-to-peer.  You participate in a namespace by having 
> some code that goes in it, and EVERY project that participates in that 
> namespace must declare it -- no exceptions.
>
> (If a project doesn't declare the namespace, and it ends up first on 
> sys.path, it will block access to all the other participants in the 
> same namespace.)
>