Unicode in DEFAULT_VERSION causes TypeErrors on Python 2.

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

---

Here's the stack trace I get when running buildout with setuptools 19.1

While:
  Installing.

An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/home/afayolle/.eggs-cache/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 1992, in main
    getattr(buildout, command)(args)
  File "/home/afayolle/.eggs-cache/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 565, in install
    self._compute_part_signatures(install_parts)
  File "/home/afayolle/.eggs-cache/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 811, in _compute_part_signatures
    options['__buildout_signature__'] = ' '.join(sig)
  File "/home/afayolle/.eggs-cache/zc.buildout-2.5.0-py2.7.egg/zc/buildout/buildout.py", line 1370, in __setitem__
    raise TypeError('Option values must be strings', value)
TypeError: ('Option values must be strings', u'zc.recipe.egg-2.0.1-py2.7.egg setuptools-19.1-py2.7.egg zc.buildout-2.4.7-py2.7.egg')

Using 19.0 works fine.

---

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

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

---

Got a +1 on this, got no additional useful info beyond what Alexandre has already posted - same issue.

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

---

Same for me, see for example here:
https://travis-ci.org/bioidiap/bob.learn.em/jobs/97264019

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

---

Sorry for the issue. It's almost certainly due to the change to the ez_setup.py script (per #215).

My first question is - does this need to be rolled back or is a fix for buildout just as easy?

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

---

I see it's reported here.

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

---

For now, I'm going to assume this is a buildout issue that can and should be addressed in buildout. If that turns out not to be the case, I'll re-open this, but for now, let's focus the investigation in the buildout ticket.

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

---

From what I can see in buildout's code, setuptools changed something so that dist.project_name now returns unicode instead of a (byte)string (on python 2).

There is an explicit check whether what it gets back is a str type. Probably one of the places where there's never been any non-ascii stuff, I assume. I'll try fixing it in buildout. Right now :-)

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

---

Ah! https://bitbucket.org/pypa/setuptools/commits/16007a2acbc5662238695f42d3d2ec1db09f0208 is the cause! I've found it.

resolve_version() downloads a json. What it gets out of it is nice and clean unicode. Which means the "I am setuptools 19.1" package name suddenly is unicode instead of ascii/bytestring because the "19.1" comes from json.

I'll compensate for that on the buildout side of things. Or is this something that might break other packages? I don't think so, but it might be worth brainstorming a bit about it.

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

---

Thanks for tracing the issue. I'll work out a fix right quick as well.

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

---

Issue #477 was marked as a duplicate of this issue.

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

---

In resolve version, always cast to a string (avoiding Unicode on Python 2). Fixes #476.

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

---

This would be indeed handier than fixing it in buildout. I've now found two places where I have to add a check for python 2/3 and a possible .encode() or str(...), so it starts to look a bit hacky.

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

---

Bootstrap script is updated; let me know if that doesn't address the issue.

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

---

I cannot reproduce the issue locally anymore with the small buildout that previously failed. I've fired off a travis job that previously failed and I'll report back when that one succeeds or fails.

But... how can a fix in ez_setup.py fix the issue that seems to be in the setuptools egg itself? It works, but I currently fail to see how :-)

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

---

I verified that buildout works again! See https://travis-ci.org/buildout/buildout/jobs/91337683 (this is on master and not on my lets-fix-this branch). So buildout again works without modifications and my branch is not needed anymore :-)

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

---

I can also confirm that the 19.1.1 release fixes the buildout where I first noticed the failure above. Thanks for addressing this quickly guys :-)