[Zope-dev] Namespace declaration using pkgutil vs pkg_resources

[Martijn Faassen]

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