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

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.


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.


It is missing from the 0.14.2 tarball fetched from PyPi.

---

From: Piotr Dobrogost [notifications@github.com]
Sent: October 28, 2012 9:32 AM
To: kennethreitz/requests
Cc: Viktor Haag
Subject: Re: [requests] requests.packages.chardet2 missing in 0.14.2, preventing installation on Python 3.3 (#916)

How is it missing? I see it's present in https://github.com/kennethreitz/requests/zipball/v0.14.2 for example.

—
Reply to this email directly or view it on GitHubhttps://github.com/kennethreitz/requests/issues/916#issuecomment-9845781.


@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 `setup.py` 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 `setup.py` doesn't know what to do with.


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


Sorry about this guys, looking into it.


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 setup.py, 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):

``` python
if is_py2:
    packages.extend([
        'requests.packages.oauthlib',
        'requests.packages.oauthlib.oauth1',
        'requests.packages.oauthlib.oauth1.rfc5849',
        'requests.packages.oauthlib.oauth2',
        'requests.packages.oauthlib.oauth2.draft25',
        'requests.packages.chardet',
    ])
else:
    packages.append('requests.packages.chardet2')
```


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


@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.


Can we get an estimate on when this issue should be resolved? I would like to replace urllib2 with requests in [PRAW](https://github.com/praw-dev/praw) but will not do so until I can confidently give a `>=` request number to depend on.


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


@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.


@bboe: Assuming the PR gets merged, `python setup.py 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).


@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. :-/ 


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


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