20.5.0+ breaks existing setup.py files - UndefinedEnvironmentName

[lnielsen]

The latest 20.6.4 PyPI is breaking our setup.py files with the following exception:

Traceback (most recent call last):
  File "setup.py", line 163, in <module>
    cmdclass={'test': PyTest},
  File "/opt/python/2.7.9/lib/python2.7/distutils/core.py", line 151, in setup
    dist.run_commands()
  File "/opt/python/2.7.9/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/opt/python/2.7.9/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/setuptools/command/test.py", line 152, in run
    self.distribution.fetch_build_eggs(self.distribution.tests_require)
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/setuptools/dist.py", line 313, in fetch_build_eggs
    replace_conflicting=True,
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/__init__.py", line 814, in resolve
    if req.marker and not req.marker.evaluate():
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 273, in evaluate
    return _evaluate_markers(self._markers, current_environment)
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 198, in _evaluate_markers
    lhs_value = _get_env(environment, lhs.value)
  File "/home/travis/virtualenv/python2.7.9/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 180, in _get_env
    "{0!r} does not exist in evaluation environment.".format(name)
pkg_resources._vendor.packaging.markers.UndefinedEnvironmentName: 'extra' does not exist in evaluation environment.

[lnielsen]

Seems to be related to this commit d25e2a5

[jaraco]

@s-t-e-v-e-n-k Can you look into this one?

@lnielsen How severe is the failure? Should I pull 20.5+ from PyPI?

[lnielsen]

Looks pretty serve. Just upgrading setuptools in a virtualenv breaks the code.

[lnielsen]

Just debugging now to provide some more information.

[jaraco]

I've removed 20.6.4 and 20.5.0 until the issue can be resolved.

[msabramo]

Also seeing this.

[msabramo]

My colleague has been looking into this and he thinks that it has to do with the fact that our tests are using a variable/parameter name called extra_environ. This is a parameter that is used by webtest (e.g.: see http://docs.pylonsproject.org/projects/webtest/en/latest/testapp.html#modifying-the-environment-simulating-authentication)

[bszonye]

I am seeing this in code that has variables and parameters named extra_environ that are ultimately passed to the webtest API. Renaming to extra_env_vars and extra_evars still hit the problem, but renaming to other_environ fixed it, so it looks like something is incorrectly identifying the extra_ pattern as an environment marker.

[nakato]

@lnielsen I can't reproduce this. How are you getting that traceback? What commands are you executing? What is the logging leading up to it? Is there anything that follows it?

[jaraco]

I can't replicate this either.

I inferred from the link that the command being executed is python setup.py test in the invenio-records-rest project, so I checked out that repo and ran setup.py test under Python 2.7 and 3.5 using setuptools 20.5+, and while some tests failed, the reported error did not occur.

I sense now that the failures are fairly isolated and only affecting tests, so I'm going to re-release the code in the latest version, but I am eager to see a fix for this issue, so do please provide more detail to describe how one can recreate the issue, preferably with a minimal use case.

[bszonye]

Our teams are encountering this when using the webtest API in a py.test fixture, so it affects all of their tests. I do not yet have a workaround that successfully builds against the webtest classes without triggering the setuptools bug, so those teams cannot even run commit tests to integrate new code.

[jaraco]

@bszonye Sorry. I don't mean to cause you trouble. Can you pin your environment to Setuptools 20.4 until the issue can be resolved?

[bszonye]

That’s what I recommended to the team for now, to pin setuptools<20.5 – tomorrow I will take a closer look to see if I can find a minimal test case.

[bszonye]

@jaraco Just confirmed with the team that version 20.6.6 does break their tests again, but they are able to work around by pinning to the 20.4 version. I suspect that something in packaging is misidentifying extra markers from code that happens to contain the string in certain identifiers.

Our traceback ends at the same place but starts with py.test instead of setup.py test:

[tests.python.functional.test_XXX.TestXXX.test_XXX] tests/python/functional/utils.py:44: in setUp
    self.testapp = get_webtest_testapp()
tests/python/functional/utils.py:98: in get_webtest_testapp
    app = get_app(join(conf_dir, 'test.ini'))
.tox/py27/local/lib/python2.7/site-packages/pyramid/paster.py:31: in get_app
    global_conf=options)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:247: in loadapp
    return loadobj(APP, uri, name=name, **kw)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:271: in loadobj
    global_conf=global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:296: in loadcontext
    global_conf=global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:320: in _loadconfig
    return loader.get_context(object_type, name, global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:450: in get_context
    global_additions=global_additions)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:559: in _pipeline_app_context
    APP, pipeline[-1], global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:454: in get_context
    section)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:476: in _context_from_use
    object_type, name=use, global_conf=global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:406: in get_context
    global_conf=global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:296: in loadcontext
    global_conf=global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:328: in _loadegg
    return loader.get_context(object_type, name, global_conf)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:620: in get_context
    object_type, name=name)
.tox/py27/local/lib/python2.7/site-packages/paste/deploy/loadwsgi.py:640: in find_egg_entry_point
    pkg_resources.require(self.spec)
.tox/py27/local/lib/python2.7/site-packages/pkg_resources/__init__.py:947: in require
    needed = self.resolve(parse_requirements(requirements))
.tox/py27/local/lib/python2.7/site-packages/pkg_resources/__init__.py:814: in resolve
    if req.marker and not req.marker.evaluate():
.tox/py27/local/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py:278: in evaluate
    return _evaluate_markers(self._markers, current_environment)
.tox/py27/local/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py:203: in _evaluate_markers
    lhs_value = _get_env(environment, lhs.value)
.tox/py27/local/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py:185: in _get_env
    "{0!r} does not exist in evaluation environment.".format(name)
E   UndefinedEnvironmentName: 'extra' does not exist in evaluation environment.