Opened at 2016-03-31T05:06:56Z
Closed at 2016-03-31T18:12:24Z
#2762 closed defect (fixed)
"UndefinedEnvironmentName" error with setuptools-20.6
Reported by: | warner | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | soon (release n/a) |
Component: | packaging | Version: | 1.11.0 |
Keywords: | Cc: | ||
Launchpad Bug: |
Description
The tahoe-1.11.0 release was only a few hours old when we started getting reports of failures. It looks like setuptools made a release today that breaks many packages. (In fact, they made seven releases today, which can't be a good sign).
https://github.com/pypa/setuptools/issues/523 is the setuptools bug. Apparently most 20.5.* and 20.6.* versions are broken. The recommended workaround (verified by warner and cypher) is to downgrade to setuptools-20.4, e.g.:
(venv) % pip install setuptools==20.4
The symptom is that pip install tahoe-lafs works normally, but then actually trying to run tahoe gives a traceback like the following:
File "/ve/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 278, in evaluate return _evaluate_markers(self._markers, current_environment) File "/ve/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 203, in _evaluate_markers lhs_value = _get_env(environment, lhs.value) File "/ve/lib/python2.7/site-packages/pkg_resources/_vendor/packaging/markers.py", line 185, 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.
I'm hoping that they'll make a new release tomorrow that fixes the problem, but in the meantime, if you see this error, try downgrading your setuptools.
Change History (1)
comment:1 Changed at 2016-03-31T18:12:24Z by warner
- Milestone changed from undecided to soon (release n/a)
- Priority changed from major to critical
- Resolution set to fixed
- Status changed from new to closed
Setuptools-20.6.7 has fixed the problem (they reverted the change that triggered it, and will try again in some later release). So a newly-upgraded virtualenv ought to be ok now.
They've removed almost all of the broken versions from pypi: it is still possible to install 20.6.6 (which breaks for me), but 20.5 and 20.6.0-20.6.5 are no longer on pypi (which also means I can't easily test them to identify exactly which ones were broken).
So: if you see this problem, do a pip install --upgrade setuptools. If the problem persists and pip list reports a setuptools of 20.6.7 or later, please re-open this ticket and give us the details.