Re: [Distutils] Future namespace support
At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote:
2009/10/14 kiorky <kiorky@cryptelium.net>:
That's not what said the PEP (IOW what i had understood of)
Oh, you don't *use* it the same way, no, but I assumed that the internal mechanisms would be similar. Maybe I was wrong.
You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package. Bear in mind that the true mechanism of nsp's is simply a module's __path__ object; pkgutil and pkg_resources simply provide utilities for setting the __path__ appropriately. With PEP 382, the utilities become unnecessary, except for backward compatibility, and if you want to do fixup of a __path__ when sys.path is changed. However, as long as each nsp is only registered with one such utility, there should be no conflicts.
2009/10/14 P.J. Eby <pje@telecommunity.com>:
You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package.
But the same namespace works. I couldn't believe kiorky's claim that it wouldn't work, and I have now tested, and it works just fine. I had one packages nstest.sub, using setuptools and one nstest.sob use pkutils, and in each of them I had a method that would import the other module. It works just fine. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
2009/10/14 P.J. Eby <pje@telecommunity.com>:
You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package.
But the same namespace works. I couldn't believe kiorky's claim that it wouldn't work, and I have now tested, and it works just fine. I had one packages nstest.sub, using setuptools and one nstest.sob use pkutils, and in each of them I had a method that would import the other module. It works just fine.
Right, its just a race: whichever project gets its version of the namespace package imported "first" wins, sets the __path__, and everything works. No consolation prizes for the others, because they *never get imported* (their __init__.py is never even considered). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrWTGkACgkQ+gerLs4ltQ5YTwCePlqxXOdhviexEeLZU8HSVQ1x lbIAnRFq4DhbNsTLUdcIY2uIlcX0UliM =wkCg -----END PGP SIGNATURE-----
2009/10/15 Tres Seaver <tseaver@palladion.com>:
Right, its just a race: whichever project gets its version of the namespace package imported "first" wins, sets the __path__, and everything works. No consolation prizes for the others, because they *never get imported* (their __init__.py is never even considered).
Well, in my little test they both get imported. Both the pkgutil one and the setuptools one. Otherwise, how could they extend the __path__? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
participants (3)
-
Lennart Regebro -
P.J. Eby -
Tres Seaver