Sorry for top-posting. Since my model was braked, I'll try to explain the
problem from very beginning. I didn't expect that model is totally wrong :-)
There is a package 'aaa.bbb' that uses setuptool only if it is installed on
the system. This is useful for development, but this breaks rpm build
process cause it expects __init__.py and doesn't expect egg and pth,
more over it ignores them. So in my case there is no egg & pth.
I started to dig if there is possibility to coexists development and
rpmbuild
processes on the same system without very messy spec file. I didn't find
the strict requirements for the package to list itself in a
namespace_package
even if I know that there would be 'aaa.bbb.ccc'. But if I not list it
there, I
can ignore egg&pth files, and in my cases setuptool will behave compatible.
So probably question does it break something if package 'aaa.bbb'
wouldn't list itself in a namespace_package? And does it provide something
useful if package 'aaa.bbb' would?
Best regards,
rik
P.J. Eby wrote:
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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
