Namespace declaration using pkgutil vs pkg_resources
Hi All, Now we have 'setuptools' as a dependency for all packages. (I guess this is to make Buildout happy ?) So, it is certain that 'pkg_resources' module will be always available as it is bundled with 'setuptools'. If that is the case, why do we need a fall-back import of 'pkgutil' to declare a namespace package? So instead of: try: import pkg_resources pkg_resources.declare_namespace(__name__) except ImportError: import pkgutil __path__ = pkgutil.extend_path(__path__, __name__) Just this line would be enough to declare a namespace: __import__('pkg_resources').declare_namespace(__name__) Am I missing something ? Regards, Baiju M
On Mar 11, 2009, at 8:24 AM, Baiju M wrote:
Hi All, Now we have 'setuptools' as a dependency for all packages. (I guess this is to make Buildout happy ?)
No, it is because setuptools is needed for namespace packages.
So, it is certain that 'pkg_resources' module will be always available as it is bundled with 'setuptools'. If that is the case, why do we need a fall-back import of 'pkgutil' to declare a namespace package?
We don't.
So instead of:
try: import pkg_resources pkg_resources.declare_namespace(__name__) except ImportError: import pkgutil __path__ = pkgutil.extend_path(__path__, __name__)
Just this line would be enough to declare a namespace:
__import__('pkg_resources').declare_namespace(__name__)
Am I missing something ?
Nope. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Mar 11, 2009, at 8:24 AM, Baiju M wrote:
Hi All, Now we have 'setuptools' as a dependency for all packages. (I guess this is to make Buildout happy ?)
No, it is because setuptools is needed for namespace packages.
The boilerpate Baiju is wondering about replacement shows how to do non-setuptools "extensible" packages (quasi-namespaces). Declaring the dependency on setuptools is a bit silly, because only setuptools knows about dependencies: the only reason we declare it everywhere is to appease zc.buildout. I would leave the boilerplate alone, on the chance that it makes the package usable via straight distutils. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJt8oo+gerLs4ltQ4RAmlwAJ4luuHcp8fY6DNI83mdvJNHQi5vGwCgpWGA YvcZU4qT5Pe0Qu7y3RLo8fw= =nZvD -----END PGP SIGNATURE-----
Baiju M wrote: [snip]
Just this line would be enough to declare a namespace:
__import__('pkg_resources').declare_namespace(__name__)
Am I missing something ?
Since Jim says you're not missing something, I'm going to add to the Zope Framework Steering Group decisions that this is enough and we could clean up __init__.py's to this if we would want to. Regards, Martijn
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the Zope Framework Steering Group decisions that this is enough and we could clean up __init__.py's to this if we would want to.
So, let me try to understand the decision process here: 1. The extras_require is banned to enable building with regular distutils. 2. pkgutil is now banned which will prevent regular distutils from working properly. What exactly do we want to achieve? Zvezdan
On Wed, Mar 11, 2009 at 10:56 PM, Zvezdan Petkovic <zvezdan@zope.com> wrote:
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the Zope Framework Steering Group decisions that this is enough and we could clean up __init__.py's to this if we would want to.
So, let me try to understand the decision process here:
1. The extras_require is banned to enable building with regular distutils.
extras_require is _not_ banned yet. There is no such decision here: http://docs.zope.org/zopeframework/steeringgroup/decisions.html Though I can see this: "We can consider removing extra dependencies for particular Zope Framework packages in order to make the dependency graph easier to reason about. We will do this on a case by case basis though."
2. pkgutil is now banned which will prevent regular distutils from working properly.
'setuptools' is a hard-dependency for all packages now, without removing that, there is no point in keeping that fall-back import of 'pkgutil'. Regards, Baiju M
Hey, Zvezdan Petkovic wrote:
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote:
Since Jim says you're not missing something, I'm going to add to the Zope Framework Steering Group decisions that this is enough and we could clean up __init__.py's to this if we would want to.
So, let me try to understand the decision process here:
1. The extras_require is banned to enable building with regular distutils.
Huh? What does this have to do with regular distutils? That never was mentioned in the extra discussion as far as I know. Anyway, extras_requires isn't banned at all. http://docs.zope.org/zopeframework/steeringgroup/decisions.html We're careful about extras as they can make it harder to reason about package dependencies.
2. pkgutil is now banned which will prevent regular distutils from working properly.
What exactly do we want to achieve?
Who banned pkgutil? I recorded this: * In namespace package's ``__init__.py`` we have been using the following boilerplate code:: try: import pkg_resources pkg_resources.declare_namespace(__name__) except ImportError: import pkgutil __path__ = pkgutil.extend_path(__path__, __name__) Since ``setuptools`` is a dependency of our packages anyway, we can instead do the following:: __import__('pkg_resources').declare_namespace(__name__) Feel free to use that and also feel free to simplify existing ``__init__.py`` modules. Just make sure ``setuptools`` is a declared dependency of the package. I'm not very concerned with making regular distutils work myself; I don't really see the point as we're heavily committed to setuptools anyway as a project. Tres remarked that it might if we continued to write this. I don't quite see how that could be. People need setuptools installed anyway to be able to run the code in setup.py. To me, building with regular distutils is *not* interesting to the Zope Framework project at this stage. It just isn't capable enough and we can use our time a lot better than worry about that. Regards, Martijn
Martijn Faassen wrote:
Since ``setuptools`` is a dependency of our packages anyway, we can instead do the following::
__import__('pkg_resources').declare_namespace(__name__)
Feel free to use that and also feel free to simplify existing ``__init__.py`` modules. Just make sure ``setuptools`` is a declared dependency of the package.
Nit: In this case, two lines are better than one. import pkg_resources pkg_resources.declare_namespace(__name__) There's no need to use the lesser known __import__ function when an ordinary import statement will do. Shane
On Wed, Mar 11, 2009 at 3:22 PM, Shane Hathaway <shane@hathawaymix.org> wrote:
Nit: In this case, two lines are better than one.
import pkg_resources pkg_resources.declare_namespace(__name__)
There's no need to use the lesser known __import__ function when an ordinary import statement will do.
Indeed. -- Benji York Senior Software Engineer Zope Corporation
On Thu, Mar 12, 2009 at 12:52 AM, Shane Hathaway <shane@hathawaymix.org> wrote:
Martijn Faassen wrote:
Since ``setuptools`` is a dependency of our packages anyway, we can instead do the following::
__import__('pkg_resources').declare_namespace(__name__)
Feel free to use that and also feel free to simplify existing ``__init__.py`` modules. Just make sure ``setuptools`` is a declared dependency of the package.
Nit: In this case, two lines are better than one.
import pkg_resources pkg_resources.declare_namespace(__name__)
There's no need to use the lesser known __import__ function when an ordinary import statement will do.
Actually three lines will be required to replace that single line: import pkg_resources pkg_resources.declare_namespace(__name__) del(pkg_resources) BTW, I am +1 for single line __import__ approach. Regards, Baiju M
participants (7)
-
Baiju M -
Benji York -
Jim Fulton -
Martijn Faassen -
Shane Hathaway -
Tres Seaver -
Zvezdan Petkovic