W/o setuptools, "setup.py install" skips zope/interface/common/

[tseaver]

In https://bugs.launchpad.net/zope.interface/+bug/611362, @exarkun reported:

After installing the 3.6.1 release from PyPI, the zope.interface.common package is not available:

exarkun@boson:~/Downloads$ tar xzf zope.interface-3.6.1.tar.gz
exarkun@boson:~/Downloads$ cd zope.interface-3.6.1/
exarkun@boson:~/Downloads/zope.interface-3.6.1$ python setup.py install --quiet --prefix /tmp/ZOPE-TEST
/usr/lib/python2.6/distutils/dist.py:266: UserWarning: Unknown distribution option: 'test_suite'
....
exarkun@boson:~/Downloads/zope.interface-3.6.1$ PYTHONPATH=/tmp/ZOPE-TEST/ python -c 'from zope.interface import common'
Traceback (most recent call last):
    File "<string>", line 1, in <module>
ImportError: cannot import name common
exarkun@boson:~/Downloads/zope.interface-3.6.1$

and supplied a patch:

https://bugs.launchpad.net/zope.interface/+bug/611362/+attachment/1471651/+files/setup.patch

I followed up:

Hmm, this seems to be true only when installing without setuptools:

@glyph followed up:

I just heard about a case of this happening on Ubuntu 12.10. I suspect it's a bug in setuptools or distutils or ubuntu's patching of same, not zope.interface; can someone comment on what mechanism ZI uses to include the 'common' package? I don't see it in setup.cfg, or a manifest file... I am guessing there's some setuptools magic which is supposed to make it get included.
Also of note; setuptools was installed on the system where this happened. It was zope.interface 4.0.3 in this case.

[glyph]

ZI 3.6.0 and Ubuntu 12.10 were both quite a while ago. I haven't seen this in some time; all my virtualenvs wth ZI 4+ and Ubuntu 14+ have been working flawlessly and I make new ones just about every day. Someone else will have to attempt to verify that this is still an issue.

[glyph]

Thank you for remembering though @tseaver !

[tseaver]

I think the issue only occurs now when you don't have setuptools installed. So, to reproduce::

$ /opt/Python-2.7.9/bin/virtualenv --no-setuptools /tmp/bare
$ cd /tmp/bare
$ wget https://pypi.python.org/packages/source/z/zope.interface/zope.interface-4.1.2.tar.gz
$ tar xf zope.interface-4.1.2.tar.gz
$ cd zope.interface-4.1.2
$ ../bin/python setup.py install

If you just create a virtualenv normally and the pip install zope.interface, everything works as expected.

[mgedmin]

Do we want to support setuptools-less installs?

You need setuptools for zope.* namespace packages on Python < 3.3 anyway.

[mgedmin]

BTW #14 is a duplicate of this, and has a patch.

[tseaver]

@mgedmin we do the pkgutil dance to allow namespace packages w/o setuptools:

$ cat projects/Zope/Z3/zope.interface/src/zope/__init__.py
# this is a namespace package
try:
    import pkg_resources
    pkg_resources.declare_namespace(__name__)
except ImportError:
    import pkgutil
    __path__ = pkgutil.extend_path(__path__, __name__)

[fgregg]

I think some of my users are running into this: dedupeio/dedupe#268

But I do have setuptools. https://github.com/datamade/dedupe/blob/master/setup.py#L5-L24

[jamadden]

To the question @mgedmin raised: is it still worth supporting setuptools-less installs? Is there anyone still trying to install with just distutils?

• pip always installs with setuptools
• buildout always installs with setuptools
• virtualenv creates environments with setuptools
• Starting with Python 3.4 the stdlib venv installs pip, and thus setuptools, by default.

[mgedmin]

Huh, from the patch mentioned in #14:

@@ -121,7 +122,13 @@
         "Topic :: Software Development :: Libraries :: Python Modules",
       ],

-      packages = ['zope', 'zope.interface', 'zope.interface.tests'],
+      packages = [
+        'zope',
+        'zope.interface',
+        'zope.interface.tests',
+        'zope.interface.common',
+        'zope.interface.common.tests',
+      ],
       package_dir = {'': 'src'},
       cmdclass = {'build_ext': optional_build_ext,
                   },

I see no reason to explicitly enumerate half of zope.interface subpackages in the setup.py. Let's either apply that or use setuptools.find_packages().

[jamadden]

Good point. There's also now this lovely block where if importing setuptools fails, the C optimizations don't get built:

try:
    from setuptools import setup, Extension, Feature
except ImportError:
    # do we need to support plain distutils for building when even
    # the package itself requires setuptools for installing?
    from distutils.core import setup, Extension
    extra = {}
else:
  # Define the C extension...
  extra = dict(...

So I'm +1 to going all-in on setuptools. I can make a new PR if desired.