ImportError no module named urlparse

In #3682, @leth reported an error which I've just encountered:

```
$ python -m rwt requests -- -c "from requests.packages.urllib3.contrib import appengine as gaecontrib"
Collecting requests
  Using cached requests-2.12.0-py2.py3-none-any.whl
Installing collected packages: requests
Successfully installed requests-2.12.0
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/var/folders/c6/v7hnmq453xb6p2dbz1gqc6rr0000gn/T/rwt-pu44a5vi/requests/packages/urllib3/contrib/appengine.py", line 45, in <module>
    from urlparse import urljoin
ModuleNotFoundError: No module named 'urlparse'
```

Because the source of #3682 appears to be unrelated to this Python 3 only bug, I'm opening a new issue.

I have the same issue as leth, and requests_toolbelt is unusable due to this bug. I don't think I can wait for due time to pass. Should requests_toolbelt be trapping this exception?

@jaraco I believe what you're seeing is shazow/urllib3#1025. It has been patched on master for urllib3 but was caught after 1.19 released. This may be enough of an issue to warrant bumping urllib3 to 1.19.1 and adding it to a 2.12.1 release? Until then, you'll likely need to use 2.11.1 unless @sigmavirus24 has a solution via requests-toolbelt.


I can confirm that pinning to requests 2.11.1 is sufficient to work around the issue.

```
$ python -m rwt requests_toolbelt requests==2.11.1 -- -c "import requests_toolbelt"
Collecting requests_toolbelt
  Using cached requests_toolbelt-0.7.0-py2.py3-none-any.whl
Collecting requests==2.11.1
  Using cached requests-2.11.1-py2.py3-none-any.whl
Installing collected packages: requests, requests-toolbelt
Successfully installed requests-2.11.1 requests-toolbelt-0.7.0
```

That serves my use case and eliminates the urgency from my perspective.


I'm not really feeling like rushing up to a new urllib3 release for this bug. So I'm going to say that downgrading to 2.11.1 is the best course of action for now, and the next major release of Requests will fix this issue. 😊


> This may be enough of an issue to warrant bumping urllib3 to 1.19.1 and adding it to a 2.12.1 release?

@nateprewitt Requests release procedures are clearly documented. Please don't make up policy that we don't follow for us.


Sorry @sigmavirus24, I wasn't attempting to insinuate anything about policy. I was simply asking a question about severity. Thanks for pointing that documentation out, I had previously missed the sentence on vendoring changes.


> I'm not really feeling like rushing up to a new urllib3 release for this bug. So I'm going to say that downgrading to 2.11.1 is the best course of action for now, and the next major release of Requests will fix this issue. 😊

@Lukasa @sigmavirus24 
The last major release was almost 3 years ago. I'm hoping you meant minor? I see procedure allows vendor updates in minor releases. 

Assuming you did is there anything interested parties can do to speed up the release? Minor releases seem to come ever 3-4 months. Which is a bit long to wait for 1 line of code and miss the improvements in 2.12.0. Its certainly not a pleasant situation, but having just done a release is now not the cheapest time to do another one? Given that there are minimal changes to requests to deal with.

http://docs.python-requests.org/en/master/community/release-process/


Sorry, I did mean minor.

@tunezaq Sure, except of course that the fix is in urllib3. That means it requires a release of urllib3, and the current master of urllib3 contains _substantial_ functional changes. That means that we'd be forcing a rapid release of urllib3 and a rapid release of Requests to ship the fix for this bug, which means that the pretty substantial release of urllib3 would get dropped before it was really ready for use.

Ultimately, it's just not as easy as it seems like it would be. Sorry!


@Lukasa My bad, I had thought the change was in a released version.

Last attempt :), would you consider a hotfix (cherry-pick) release to get the change into a `1.19.1` urllib3? I wasn't able to find a documented release process for the project, but that would allow this issue to be resolved very timely. I see urllib3 releases a bit more often, I would guess by the time its released again requests may not be in a place for a minor release. Seems like this is a "critical window" where the issue can be resolved now or in a couple months.


The biggest reason I can think of for doing this is that right now this change broke requests-toolbelt on Python 3, and so by extension also broke twine on Python 3. See also sigmavirus24/requests-toolbelt#167. We have, in the past, put a bugfix release of urllib3 into a patch release of Requests, so we can probably bear to do that again.

This is pretty frustrating, and I think if we hadn't broken such major consumers then I wouldn't be so worried: there is little in 2.12.0 that is desperately valuable.


Ok, I have shipped 2.12.1 that should resolve this issue.