This happens to work, because all of our "distribution" (i.e. distributable packaged Python code) names to coincide with all of their "package" (i.e. a directory with a __init__.py in it, which is "import"-able) names, except, I think for Twisted on Brian's debian sid system.
But there's no reason why it should always work, and the only reason for that __import__() was to give us an explicit error message indicating missing requirements in the case that pkg_resources isn't importable or that the requirements don't have correct .egg-info metadata. So, by removing this stanza we may allow certain places to get a more ad-hoc failure message, i.e. an ImportError from somewhere, instead of an ImportError from _auto_deps.py, but that's okay.
Note that dependencies which do not have their .egg-info metadata with them are increasingly rare, since Python 2.5 distutils creates the .egg-info file by default, and Linux distributions have stopped their former practice of actively deleting the .egg-info files.
We've never heard of a version of zope.interface that *wasn't* compatible, and there is a bug in Ubuntu's packaging of zope.interface which causes it to report its version number as 0.0.0:
https://bugs.launchpad.net/zope.interface/+bug/185418
zooko recently added a runtime check, via setuptools, that specific versions of various
packages were reported as available through setuptools at runtime.
however exe and app builds run with collected egg contents, not linked against entire
eggs, i.e. the code is transcluded into a single library.zip
thus setuptools reports that those specific version cannot be reported as available,
though they are in fact available built into the library
this disables that runtime check if the app is running 'frozen'
Using pkg_resources.require() like this also apparently allows people to install multiple different versions of packages on their system and tahoe (if pkg_resources is available to it) will import the version of the package that it requires. I haven't tested this feature.
