Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unicode in DEFAULT_VERSION causes TypeErrors on Python 2. #476

Closed
ghost opened this issue Dec 16, 2015 · 16 comments
Closed

Unicode in DEFAULT_VERSION causes TypeErrors on Python 2. #476

ghost opened this issue Dec 16, 2015 · 16 comments

Comments

@ghost
Copy link

ghost commented Dec 16, 2015

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.


@ghost
Copy link
Author

ghost commented Dec 16, 2015

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.

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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?

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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


I see it's reported here.

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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.

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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 :-)

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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.

@ghost
Copy link
Author

ghost commented Dec 16, 2015

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


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

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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


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

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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


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

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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.

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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


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

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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 :-)

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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 :-)

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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 :-)

@ghost
Copy link
Author

ghost commented Dec 17, 2015

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


A job on our internal jenkins server is also happy again, so yes: it is fixed. Thanks!

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants