setuptools 8.0 fails with zc.buildout 2

[ghost]

Originally reported by: tomgross (Bitbucket: tomgross, GitHub: tomgross)

---

With the release of setuptools 8.0 all buildouts fail with the following error:

#!python

tom@localhost:~/demobuildout> python2.7 bootstrap.py
Downloading https://pypi.python.org/packages/source/s/setuptools/setuptools-8.0.zip
Extracting in /tmp/tmp_34LbA
Now working in /tmp/tmp_34LbA/setuptools-8.0
Building a Setuptools egg in /tmp/tmpeA5PHB
/tmp/tmpeA5PHB/setuptools-8.0-py2.7.egg
Traceback (most recent call last):
  File "bootstrap.py", line 145, in <module>
    if _final_version(distv):
  File "bootstrap.py", line 131, in _final_version
    for part in parsed_version:
TypeError: 'Version' object is not iterable

This error did not occur with setuptools 7.0 and earlier. A workaround can be found here:
http://blog.toms-projekte.de/workaround-setuptools-buildout-bug.html

---

• Bitbucket: https://bitbucket.org/pypa/setuptools/issue/296

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I think the Version object returned by pkg_resources should continue to be iterable. Let's write a test to capture that requirement within the setuptools test suite, and then implement it.

Here is the code where that error occurs. I see that buildout is depending on the internal structure of the Version class, specifically the string-based encoding.

I suspect the new Version class won't be compatible here. @dstufft, can we wrap Version in something that's close enough to support buildout? If not, we may have to pull setuptools 8 until buildout can be updated to support the new model.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Moment, I'm trying to grok what the buildout code is doing at all here.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Ok so it's just trying to determine if a version is a pre-release or not?

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

So I see two solutions here and I'm not familiar with how buildout works enough to figure out which one is more reasonable.

1. Modify bootstrap.py so that it checks the return value of pkg_resources.parse_version and uses the object attribute for determining if something is a pre-release or not.
2. Subclass the packaging version classes in setuptools so that they are iterable, and when you iterate over them they return a string that looks something like what used to be returned.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Oh to to be clear, I'm pretty sure we can get a fix ASAP for this, i'd much prefer not to pull 8.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

I believe this should fix buildout https://github.com/jaraco/setuptools/pull/16 and it also raises a warning so people who are relying on that behavior will know it's not a good idea to rely on it.

What I did was just put the entire old parse_version there, so if someone is using the result of iterating over the result of parse_version to order things, they won't get the new sorting algorithm, however that sorts the same in most cases anyways so it should be too bad (and they'll get a warning if they do that anyways). I've also added a test which is just copy/pasting the code from buildout.

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

@dstufft: merged and released as 8.0.1. Thanks for the quick response.
@tomgross: please let us know if this doesn't resolve the issue.

[ghost]

Original comment by papachoco (Bitbucket: papachoco, GitHub: papachoco):

---

Hi ..

I am still having issues w/ zc.buildout-2.2.5 (py27) .
I am getting the following warning
setuptools-8.0.1-py2.7.egg/pkg_resources.py:130: RuntimeWarning: You have iterated over the result of pkg_resources.parse_version. This is a legacy behavior which is inconsistent with the new version class introduced in setuptools 8.0. That class should be used directly instead of attempting to iterate over the result.
stacklevel=1,

and sadly after that, distributions cannot be found

e.g.

Getting distribution for 'z3c.recipe.staticlxml==0.10'.
Error: Couldn't find a distribution for 'z3c.recipe.staticlxml==0.10'. (https://pypi.python.org/pypi/z3c.recipe.staticlxml)

same with 'pillow==2.6.1'.

Also oddly enough if I get pass that, I get this error when checking versions

The constraint, 2.6.1, is not consistent with the requirement, 'pillow==2.0.0,>=2.4.0'.
While:
Installing eggs.
Error: Bad constraint 2.6.1 pillow==2.0.0,>=2.4.0

Thanks

Carlos

PS. Rollback to 7.0 everything works as expected

[ghost]

Original comment by j1m (Bitbucket: j1m, GitHub: j1m):

---

Yea, this didn't work, but thanks for trying. :)

I'm fixing buildout.

[ghost]

Original comment by datakurre (Bitbucket: datakurre, GitHub: datakurre):

---

@jaraco @dstufft I can confirm the same issue as @papachoco (deprecation warning is ok, because buildout should be fixed, but it also fails to find any distributions).

Also, may or may not be related to buildout issue, I had issues of some packages depending on Version to be indexable. Would it be also possible to get backwards compatibility for that? (With similar deprecation warning, of course.)

Anyway, thank you the hard work for backwards compatibility.

[ghost]

Original comment by kylemacfarlane (Bitbucket: kylemacfarlane, GitHub: kylemacfarlane):

---

@J1M I've run into a different bug with setuptools 8.0/8.0.1 and buildout 2.2.5 under Python 3.4.

The version comparison chokes at the following point:

File "/vagrant/eggs/zc.buildout-2.2.5-py3.4.egg/zc/buildout/easy_install.py", line 427, in _obtain
    if distv > bestv:
TypeError: unorderable types: SetuptoolsVersion() > tuple()

The problem is that buildout defaults bestv to an empty tuple which can't be compared to SetuptoolsVersion.

[ghost]

Original comment by j1m (Bitbucket: j1m, GitHub: j1m):

---

Yeah, I know cuz ... tests. I'm working my way though test failures now.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

So I see two things we can add here:

1. Indexing the SetuptoolsVersion object, I was thinking about this anyways because of https://review.openstack.org/#/c/141653/
2. Make it possible to compare a tuple() to a SetuptoolsVersion() object.

Both obviously with the RuntimeWarning.

[ghost]

Original comment by j1m (Bitbucket: j1m, GitHub: j1m):

---

FTR. I think this will be a positive change. Version management is a lot saner now.

[ghost]

Original comment by j1m (Bitbucket: j1m, GitHub: j1m):

---

Donald, no worries. I've just about got this fixed.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Here's another Pull request which I hope will re-enable compatability with older buildouts: https://github.com/jaraco/setuptools/pull/17

I don't actually know how to use buildout so I'm not sure the best way to test it to make sure it actually does that, I'm just going by the errors shown here.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Heh, Well I'll leave it up to Jason and you to figure out if my PR should be merged :)

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Oh @J1M incase you didn't know, setuptools is using https://warehouse.python.org/project/packaging/ and so will pip 6.0. (Well techincally setuptools is subclassing it to add legacy behaviors). Not sure what your buildout code is doing, but if you're doing any version manipulation or specifier manipulation internal to buildout that code might be useful on it's own for you.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

Oh, my GH#17 PR also fixes Openstack I think.

[ghost]

Original comment by datakurre (Bitbucket: datakurre, GitHub: datakurre):

---

@dstufft @jaraco Thanks for 8.0.2. Fixed issue where legacy code was relying on SetuptoolsVersion indexable behavior.

[ghost]

Original comment by papachoco (Bitbucket: papachoco, GitHub: papachoco):

---

Thanks a lot guys. Distributions are now found. However, there is still an issue. Not sure if it is in zc.buildout or setuptools. I am using pillow 2.6.1 and I am getting the following error

Installing eggs.
The constraint, 2.6.1, is not consistent with the requirement, 'pillow==2.0.0,>=2.4.0'.
While:
Installing eggs.
Error: Bad constraint 2.6.1 pillow==2.0.0,>=2.4.0

The error comes from reportlab-3.1.8-py2.7-macosx-10.9-intel.egg/EGG-INFO/requires.txt:pillow ==2.0.0, >=2.4.0

It works fine with setuptools 7.0 and zc.buildout-2.2.5.

Thanks a lot
Carlos

PS> https://bitbucket.org/rptlab/reportlab/issue/55/setuptools-80-cannot-install-reportlab-318

[ghost]

Original comment by nidi (Bitbucket: nidi, GitHub: nidi):

---

I'm also still having issues with setuptools 8.0.2 and buildout 2.3.0 as described in GH:buildout/buildout 220.

Looks like the changes GH:jaraco/setuptools 17 introduced aren't enough yet and __hash__ is also required for SetuptoolsVersion.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

The reportlab error is because PEP 440 simplifies the specifier syntax and changes it from something that is genuinely hard to understand (I've worked with it a lot, and I have a hard time even forming a mental model of what it does) with something that is super simple to explain and work with. The downside is that there are going to be some edge cases where the restricted functionality will require some adjustments :(

The __hash__ problem is specific to Python 3, and it's because I forgot that Python 3 made it so that when you subclass a class which has a __hash__ method, the subclass does not automatically inherent the parent's __hash__ method if you define an __eq__ method in the subclass.

I've addressed this with https://github.com/jaraco/setuptools/pull/18

[ghost]

Original comment by datakurre (Bitbucket: datakurre, GitHub: datakurre):

---

Upgraded over 50 Plone configurations to zc.buildout 2.3.0 and setuptools 8.0.2 in the morning (each with about 400 packages). A few invalid version specifiers caused issues, because they were not valid after PEP 440 and were no longer comparable, but setuptools itself worked well. Thanks for the backwards compatibility fixes.

[ghost]

Original comment by dstufft (Bitbucket: dstufft, GitHub: dstufft):

---

I think this issue can be marked as fixed now?

[ghost]

Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco):

---

I think so, but please comment or re-open as appropriate.