Skip to content

requests.packages.chardet2 missing in 0.14.2, preventing installation on Python 3.3 #916

ViktorHaag opened this Issue Oct 27, 2012 · 19 comments

10 participants


Requests-0.14.1 included requests.packages.chardet2. This module is missing in 0.14.2 but the setup process still attempts to load it for python3 builds. This prevents installing/upgrading to this version with pip3.


Travis-ci have just say to me this is present with python3.2 too.


I imagine this will present the same problem on any Python3.x platform, but I only tested it locally against 3.3.

ghost commented Oct 28, 2012

I can confirm this happens with Python 3.1, 3.2 and 3.3 while installing from PyPI. As a side note, pip install requests==0.14.1 works just fine.

ghost commented Oct 28, 2012

@ViktorHaag: Right! Just installed from the GitHub tarballs and everything went smooth.


@bmcustodio PyPI doesn't do the packaging, that's @kennethreitz's job. Something must have changed in between the 0.14.1 and 0.14.2 releases. If you feel like tackling that, be our guest.

Also the 0.14.2 tarball fetched from GitHub is generated by GitHub and not by @kennethreitz. So that tarball also includes a bunch of extra information that doesn't know what to do with.

gtaylor commented Oct 29, 2012

This is also affecting me on Python 3.3 with Homebrew on Mac.


Sorry about this guys, looking into it.

@kennethreitz kennethreitz reopened this Oct 31, 2012

I'm not sure if this is related, but I noticed that installing 0.14.1 from PyPI (on Python 3.3) includes oauthlib, chardet, chardet2, and urllib3 in the packages directory, while installing it from the 0.14.1 GitHub tarball only includes chardet2 and urllib3. If you delete setup.cfg, PKG-INFO, and requests.egg-info from the PyPI tarball, it behaves the same as the GitHub tarball. This is using distribute 0.6.30.

In, it looks like the intent is to exclude chardet and oauthlib from 3.x installations and exclude chardet2 from 2.x installations (that is, the GitHub tarball behavior):

if is_py2:
madjar commented Nov 8, 2012

Could it be because if is_py2: is resolved at packaging time and not at installation time, so that if python sdist upload is executed on python2, chardet2 is not included ?

ghost commented Nov 8, 2012

@madjar: Most certainly. On the other hand, if it had been packagaed under Python 3, the same would happen with the other vendored packages.


@bmcustodio: My diagnosis as well. The tarball on pypi lacks chardet2; it looks like the package was uploaded to pypi using python 2. Cloning directly from GIT installs properly.

bboe commented Nov 15, 2012

Can we get an estimate on when this issue should be resolved? I would like to replace urllib2 with requests in PRAW but will not do so until I can confidently give a >= request number to depend on.

ghost commented Nov 15, 2012

@bboe: I have issued a PR (#929) some days ago which would resolve this issue. Let's wait for @kennethreitz's approval (or not) of it :-)

bboe commented Nov 15, 2012

@bmcustodio I saw your pull request, however, you didn't address the comment by @sigmavirus24.

As a more general question, is it even possible to provide python-version specific source distributions? Your PR does not seem to handle that as the source distribution will either be created from python2 or from python3 but as far as I know, one cannot be provided for both.

ghost commented Nov 15, 2012

@bboe: Assuming the PR gets merged, python sdist would create exactly the same output under Python2 and Python3 as dependencies would get resolved at install time rather that at packaging time.

Regarding your question, I don't think that's possible (or even desirable).

bboe commented Nov 15, 2012

@bmcustodio I see. I misunderstood the problem as a need for a variable installation dependency, but just realized that that is not actually a problem with source distributions.

If means anything, I support not having vendored dependencies, however, I'm sure @kennethreitz decided to do it that way for the exact reason that I'm hoping this issue get resolved. That is, to prevent installation issues of the package in question when its dependencies have installation issues. :-/

ghost commented Nov 16, 2012

@kennethreitz: Ok, so (I think) I have a solution for this. I'll issue a PR in a minute...

Lukasa commented Nov 24, 2012

This issue is being discussed in #939 and #951, so we no longer need this issue. Closing for cleanliness, thankyou all for your contributions!

@Lukasa Lukasa closed this Nov 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.