Extract version from requests/__init__.py instead of importing requests

This works around a bug in the way setuptools' `test` command works when initially run.

Closes #2462


Do we believe this only affects sys?


## It's the only import in init and I'm hoping @wardi can help make sure this is correct.

Sent from my Android device with K-9 Mail. Please excuse my brevity.


looks like it would work, but reproducing the error is a pain. I don't yet know why it only failed on travis on certain python versions. Does some package need to be importable for it to get to this code? What special conditions are required?

I don't like magic importing and monkeypatching code in utility libraries, especially when it makes me chase phantom bugs like this. (I'm not even using SSL let alone SNI!)

Maybe I can reproduce by referencing this commit id in my install_requires and poking travis.


Seems I can't reference a commit id in install_requires, so this is going to be tricky to test unless you push it up to pypi under a different name, or help me figure out what environment will trigger the bug. https://github.com/ckan/ckanapi/pull/39


Maybe @p-p-m can share more details about how to reproduce this.


How to reproduce bug:
1. Clone nodeconductor(https://github.com/opennode/nodeconductor).
2. In `setup.py` change `requests<=2.5.1` to `requests==2.5.3`
3. Run python `setup.py` install


@p-p-m right, so the only way to reproduce is during install from an install_requires. I've got that too, I'll just have to push this commit up to pypi under a new project name and test that way.


@wardi with this info I have an idea how to test this without making a new package on PyPI. Give me a couple hours to experiment. Thanks.


So here's something that's interesting. I followed @p-p-m's instructions and had 0 problems. (Granted I've done it once so this may be non-deterministic behaviour and may require repetition.)

That said, I tried it on setuptools 3.6. I would hope that Travis is on an even more recent version.


That gave me an idea. I added a pip-freeze to my travis run just before the install https://travis-ci.org/wardi/ckanapi/builds/54313804

I think this rules out versions of installed python packages, unless there is something behaving differently based on some other things installed on the system. Still don't know how to reproduce this except in travis...

Python 2.6 (passing, probably because I've pre-installed requests in this case):

```
argparse==1.3.0
ckanapi==3.5.dev0
docopt==0.6.2
linecache2==1.0.0
mock==1.0.1
nose==1.3.4
numpy==1.9.1
py==1.4.26
pytest==2.6.4
requests==2.5.3
simplejson==3.6.5
six==1.9.0
traceback2==1.4.0
unittest2==1.0.1
wheel==0.24.0
```

python2.7 (failing)

```
mock==1.0.1
nose==1.3.4
numpy==1.9.1
py==1.4.26
pytest==2.6.4
wheel==0.24.0
```

python 3.2 (failing)

```
mock==1.0.1
nose==1.3.4
numpy==1.9.1
py==1.4.26
pytest==2.6.4
wheel==0.24.0
```

python 3.3 (passing, maybe a change in behavior in 3.3+ that avoids the issue?)

```
mock==1.0.1
nose==1.3.4
numpy==1.9.1
py==1.4.26
pytest==2.6.4
wheel==0.24.0
```

pypy (passing)

```
cffi==0.8.6
greenlet==0.4.5
mock==1.0.1
nose==1.3.4
py==1.4.26
pytest==2.6.4
readline==6.2.4.1
wheel==0.24.0
```


So using the ckanapi project, I'm able to reproduce this reliably. 

If I do

```
python setup.py test
```

After a fresh clone, I see the behaviour described in the bug. Interestingly, if I rerun `python setup.py test` again, the tests run and pass. If I remove `.eggs` and run `python setup.py test` then it fails again in the same way.


So if we look at the traceback we see:

```
    self.with_project_on_sys_path(self.run_tests)
```

Which contains [this code](https://bitbucket.org/pypa/setuptools/src/18eceee63709bc70c06b51a609f3dbd2eab07ef4/setuptools/command/test.py?at=default#cl-117). Which also messes with `sys.path` and `sys.modules`. Oh and on Py3, setuptools will [delete modules](https://bitbucket.org/pypa/setuptools/src/18eceee63709bc70c06b51a609f3dbd2eab07ef4/setuptools/command/test.py?at=default#cl-152) when running tests. (Which I don't think is at fault here, just amusing.)


So after using the version of requests that would result from this PR, we get the following with `python setup.py test`:

```
  requests/packages/__init__.py", line 74, in load_module
TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types
```

The line in question is

``` py
if not isinstance(m, VendorAlias)
```

Inside the list comprehension where we redefine `sys.metapath`. In otherwords, `VendorAlias` is now `None` as well. What's baffling to me is why this works the second time we run it.

To note, I put a pdb trace into setuptools' test command at line 161. The first time through sys.metapath has our `VendorAlias` instance on it. The second time through, it's empty. So what I think is happening is the following:

When it's run the first time, requests is imported by setuptools as part of the install. And I think the bug is actually in our `setup.py`.

In our `setup.py` we import `requests` so that we can find the version number. I'm going to try something else real quick, but I think we've found the real problem.


Bingo. That's it. I'll push up a new fix ASAP.


LGTM. :cake:


Ah, this looks good. I was hunting down the root cause for this bug - thanks for the fix!
When can we expect to see 2.5.4 on pypi?


@johnnykv 2.6.0 was released earlier today (2015 March 14)