mock setup.py fails to detect incompatible setuptools fork 'distribute' and after install fails with "Versioning for this project requires..."

[radekholy24]

Reproducer:

1. run a system with virtualenv 1.7.1.2 (in my case, a Vagrant box based on debian/wheezy64)
2. create a Python 2.7 virtual environment (virtualenv venv)
3. activate the environment (source venv/bin/activate)
4. upgrade pip (pip install --upgrade pip)
5. follow the mock's installation instructions (I did not find any, thus pip install mock)
6. import mock (python -c "import mock")

Actual behavior:

An Exception with the following traceback:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/mock/__init__.py", line 2, in <module>
    import mock.mock as _mock
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/mock/mock.py", line 71, in <module>
    _v = VersionInfo('mock').semantic_version()
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/pbr/version.py", line 460, in semantic_version
    self._semantic = self._get_version_from_pkg_resources()
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/pbr/version.py", line 447, in _get_version_from_pkg_resources
    result_string = packaging.get_version(self.package)
  File "/home/vagrant/venv/local/lib/python2.7/site-packages/pbr/packaging.py", line 725, in get_version
    raise Exception("Versioning for this project requires either an sdist"
Exception: Versioning for this project requires either an sdist tarball, or access to an upstream git repository. Are you sure that git is installed

Expected behavior:

mock can be imported

Affected versions:

• mock 2.0.0
• pbr 1.10.0
• pip 8.1.2
• distribute 0.6.24
• Python 2.7

Additional information

An upgrade of setuptools (pip install --upgrade pip) (to 28.6.1) after the installation of mock does not fix the issue. An upgrade before the installation helps.
Normally, I don't use these old libraries but I am forced to be compatible with Python 2.6 and Debian Wheezy seems to be the last Debian release that has Python 2.6 in its official repositories. Since I use that system only for testing and not for development, the provisioning of the system is automated (via Vagrant). Thus the steps above. Normally, I wouldn't even upgrade pip but I could not install mock without that.
What I want to say is that I understand that you expect users to use newer versions. But in such automated cases, it might not be the case. If you (or pbr - I don't know which package caused that) could enforce newer setuptools, it would really help. If not, at least a note in installation instructions would be nice.
Maybe this is a duplicate of #314. Maybe this is even a duplicate of https://bugs.launchpad.net/pbr/+bug/1505007. However, since the pbr bug is open for 1 year already without any response, it might be reasonable to implement a workaround in mock in the meantime.

[rbtcollins]

Thanks, this is a great bug report. I suspect the heart of the problem lies in the use of distribution: mock detects too-old setuptools but distribute isn't triggering that errror during installation. You can see here - https://github.com/testing-cabal/mock/blob/master/setup.py#L5 that we require setuptools 17.1 or newer to install: and some bug in distribute is failing to recognise that it is an older version. (Note that this has broken and been fixed multiple times in setuptools from memory :(.).

So to confirm this, upgrading setuptools in the venv should fix it: which you note you have done and does fix it.

Therefore - I'm going to retitle the bug to indicate the failure is that we don't detect the incompatibility.

I have some sympathy for your situation but at the heart of the problem, running unsupported code and seeking community support is a difficult mix. http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html is a good blog post in this space.

One thing you could do to deal with Python 2.6 and such old tools is to install older versions of mock. I'm sure that <2.0.0 versions will work 'correctly' (I say 'correctly' because they suffer some fairly significant bugs that have lead to errors in dependent code due to tests just silently passing.

[rbtcollins]

The underlying issue here is that distribute isn't installing the egg info in a way that pbr can actually read back - and pbr depends on the pkg_resources component of distribute, so the bug is down in that stack somewhere.

[rbtcollins]

Also, I think this is in the category of, patches welcome: I have no interest in devoting time to supporting installs on 2.6 better: I won't deliberately break it, but thats the limit of my interest.

[radekholy24]

Please note, that this bug is not specific to Python 2.6. I have deliberately provided a reproducer for Python 2.7.

Well, I cannot express how happy I would be if I could stop supporting Py2.6. But the system I want to support is my Nokia N9 phone. And since Microsoft shut down the repositories (I mean stopped supporting N9), I am stuck with Py2.6...

So, if you are not interested in supporting Python 2.6 anymore, may I ask you to improve the wording of the README accordingly? Until now I was under impression that you actually support Python 2.6... And if you mention there that e.g. setuptools >= 17.1 is required, I think that you can easily close this bug as resolved. But it's up to you of course. Just a suggestion... Actually, I can easily live with some workarounds in my Vagrantfile.

[tadeu]

There's a related error when using mock with frozen executables, because of this pbr/setuptools runtime dependency. Is it really important to have this dependency? Could the version information be written at setup time?

(It seems to have been introduced here: e795a4a)

[rbtcollins]

@tadeu thats a totally separate discussion: to install properly mock needs a setuptools that handles conditional dependencies correctly, and we're not detecting that the setuptools in use here fails to do so - due to bugs in setup_requires handling in that (ancient) version. (and I do mean ancient). We'd still fail to install properly if pbr was not being used, and mock would still not work. I'll retitle it to be even more expliclt

[cjw296]

Thankfully, distribute and the need for it are now long gone :-)