setuptools 34 requires pyparsing >= 2.0.3

[marksteward]

Setuptools 34.0.1-34.1.1 doesn't coexist with pyparsing 1.5.7, failing with the following error (which can be found in various places across Google):

$ virtualenv env
$ env/bin/pip install --upgrade pip wheel setuptools==34.1.1
...
$ env/bin/pip install pyparsing==1.5.7
Collecting pyparsing==1.5.7
Installing collected packages: pyparsing
  Found existing installation: pyparsing 2.1.10
    Uninstalling pyparsing-2.1.10:
      Successfully uninstalled pyparsing-2.1.10
Successfully installed pyparsing-1.5.7
$ env/bin/python -c 'import setuptools.version'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/tmp/env/local/lib/python2.7/site-packages/setuptools/__init__.py", line 12, in <module>
    import setuptools.version
  File "/tmp/env/local/lib/python2.7/site-packages/setuptools/version.py", line 1, in <module>
    import pkg_resources
  File "/tmp/env/local/lib/python2.7/site-packages/pkg_resources/__init__.py", line 72, in <module>
    import packaging.requirements
  File "/tmp/env/local/lib/python2.7/site-packages/packaging/requirements.py", line 59, in <module>
    MARKER_EXPR = originalTextFor(MARKER_EXPR())("marker")
TypeError: __call__() takes exactly 2 arguments (1 given)

I've seen the conversation in #940, which states that only installing from wheels is supported, but this is some pretty non-obvious breakage. I've also just found pypa/packaging#91 and pypa/packaging#93, but not until after discovering the dependency issue and going to write a pull request.

As a wheel build doesn't exist for previous versions (pip install --only-binary pyparsing pyparsing==1.5.7 fails) would it be reasonable to set a dependency in setuptools to be explicit?

[jaraco]

I'd rather not place the dependency in the wrong place as a workaround for a known issue, as then I have to manage the workaround, which should be more work than just getting the issue fixed in packaging, which is the right thing to do. It would not make sense to have this dependency declared in setuptools except for this issue. Since the traceback implicates packaging and the issue is filed there, it seems it would be best to put the pressure on that package to release the appropriate fix.