[Distutils] namespace_packages: include itself ot not include

P.J. Eby pje at telecommunity.com
Tue Feb 8 16:09:49 CET 2011


At 01:07 PM 2/8/2011 +0300, Roman Kurakin wrote:
>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.

There is no such thing as a namespace provider.  That's why you're 
confused.  A namespace package is just a namespace for other modules 
and packages.  It does not have any existence of its own.


>  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.

You're still confused.  In the RPM case, there will be *no* aaa/__init__.py.


>But who will
>provide __init__.py for 'aaa.bbb' if we pack it as setuptool 
>provided it for us?

It is not necessary.  Look for a file like 
"mypackage-version-nspkg.pth" in the directory adjacent to aaa -- you 
will see that it contains code to make the package exist despite the 
nonexistence of the __init__.py


>>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?

You are saying, "but what if I provide the lunch?"  You can't provide 
the lunch.  You can only *join* the lunch.

You are trying to solve a problem that doesn't exist.  Namespace 
packages are the names of a *group* of modules or packages.  There is 
no "main" package for a namespace, and no "extensions".  There is no 
single project that "provides" the namespace, just like there is no 
one person who "provides" the lunch.

If you persist in thinking that there is a provider, then you will 
continue to be confused, and trying to solve a problem that doesn't 
actually exist.


>Should it list itself or not? In case it should, the question is how to
>deal with __init__.py?

As it says in the setuptools documentation, you must provide an 
__init__.py in your project that ONLY contains the namespace 
registration.  In installation environments that do not require an 
__init__.py (e.g. rpm installs), this file will NOT be included -- an 
nspkg.pth file will be used instead.  For .egg files and directories, 
the __init__.py of every participating project is included, but only 
the first one found on sys.path will actually be used.



>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.

Setuptools handles the reservations.  The project simply says, "I'm 
with the aaa group", and setuptools says, "ah, then you're sitting 
over here".  ;-)  If there is nobody else arrived yet, then 
setuptools takes care of allocating the table, so to speak, and then 
seats all the newcomers there as well.

But, just because one person arrives first, doesn't make them the 
head of the group.  Members of the party may arrive in any order, and 
when others show up they will be seated in the same place.



More information about the Distutils-SIG mailing list