Making requests PEP 302 compatible which makes its zip_safe for .egg distrubution


Thanks for this!

I don't know how much Kenneth will want/not want this. However, in its current form this PR can't be accepted. The reason is that our `requirements.txt` file actually defines our _testing_ requirements. For actual use, Requests has _no_ external dependencies. This is important to us, which means that adding setuptools as an external dependency is something we're very strongly resistant to.


Ahh, ok well since PEP 302 is accepted and part of the standards track, i believe the functionality of pkg_resources will eventually become part of the standard library.

I personally try to use all my external modules as .egg because its much easier to version control a bunch of .egg files instead of a bunch of loose files that get .pyc files mixed among them when you try to upgrade to new versions of packages but only want the source checked into your version control and not the .pyc files.


I'm perfectly happy to do this in principle, but I have a fuzzy memory of Kenneth not liking `zip_safe`.


Ok, well i'll get this pull request into a good place with Travis CI, so if you guys decide to add this support it should be easily merged.


> I personally try to use all my external modules as .egg because its much easier to version control a bunch of .egg files instead of a bunch of loose files that get .pyc files mixed among them when you try to upgrade to new versions of packages but only want the source checked into your version control and not the .pyc files.

So there are a few issues with this:
- If you're vendoring requests, it shouldn't be working just yet. (It will work in 2.0)
- New versions of packages shouldn't be hard to pull from either GitHub or PyPI.
- If your version control system does not know how to ignore files based on a pattern match (e.g., `.pyc`) then you're using an awful VCS.
- Perhaps since there's exactly one different line in the `setup.py` file (and that rarely changes in the first place) you might be able to automate a process that looks like:
  - Download package from PyPI (or GitHub)
  - Replace existing setup.py with your setup.py
  - Run `python setup.py bdist_egg` (or whichever the command is, I sincerely forgot)
  - Use the `.egg` generated by that instead.
- Finally, `zip_safe`'s status (PEP or not) is not a deciding factor for us as maintainers (or author in Kenneth's case). We don't follow PEP-008 or PEP-257 so it is reasonable to expect that we might not bother with PEP-302 either.

I appreciate the fact that you put the effort forth and for all I know Kenneth may change his mind w/r/t using `zip_safe` but your argument about `pyc` files being checked into your VCS is fundamentally flawed in my opinion.


Honestly, I'm afraid to change this because 'cacert.pem' works perfectly for everyone now.


Closing for now, but please keep the comments coming. I just need to be convinced that this worth the risk :)


Well after reading more about the history of PEP 302, really it seems no one uses external package data as intended by the PEP, in which cause they basically say you shouldn't be part of a .egg in you have external data file dependancies.  There appears to be a builtin module called pkgutil(created for PEP 302) which has a method get_data() which returns the binary data from the requested data file within the .egg.  Obviously the way cacert.pem is used by being passed along to other methods and modules not as binary data but as a filepath, as with most other external data files like that.

So setuptools gets around this by using the resource_filename method which extracts the requested data file to a temp location, and returns the filepath to that temp location.  Obviously this leaves around unwanted temp files(there is a cleanup method that can be hooked to atexit, but that seems dirty and error prone)

It would be super nice if we could get alot of python packages to work inside of .egg(much like .war in the java world) but at this point in time it seems to be way more hassle then its worth.

I have looked at a number of other python modules to see what it would take to make then more PEP 302 compliant but it appears to be way more hassle then its worth.  Access to data file dependencies just doesn't work inside of the zipped .egg format.