Import issues in 2.5.2+

While I'm not entirely certain of the problem, this reproduces in our environment with an obscure (unrelated to requests) import error.

I've confirmed this was introduced in 2.5.2 and exists in 2.6.0, as well as 1f0e5775f28d6c2db3430fdc16a095762816bf87

If I had to guess, I'd say its related to this:
- Copy pip's import machinery. When downstream redistributors remove requests.packages.urllib3 the import machinery will continue to let those same symbols work. Example usage in requests' documentation and 3rd-party libraries relying on the vendored copies of urllib3 will work without having to fallback to the system urllib3.


If i end up with some spare time I will try to dig into this more. Unfortunately the codebase that this reproduces on is not public. That said, here's the error (though all I can say is it happens somewhere in the import cycle after some initial things load):

```
./bin/sentry upgrade --noinput
/Users/dcramer/Development/getsentry/getsentry/conf/settings/defaults.py:408: UserWarning: Unable to fetch package version: [Errno 2] No such file or directory: path(u'/Users/dcramer/Development/getsentry/VERSION')
  warnings.warn(u'Unable to fetch package version: %s' % unicode(e))
Using configuration 'getsentry.conf.settings.dev'
Traceback (most recent call last):
  File "/Users/dcramer/.virtualenvs/getsentry/bin/sentry", line 9, in <module>
    load_entry_point('sentry==7.5.0.dev0', 'console_scripts', 'sentry')()
  File "/Users/dcramer/.virtualenvs/getsentry/src/sentry/src/sentry/utils/runner.py", line 410, in main
    initializer=initialize_app,
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/logan/runner.py", line 169, in run_app
    management.execute_from_command_line([runner_name, command] + command_args)
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 399, in execute_from_command_line
    utility.execute()
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 392, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 261, in fetch_command
    commands = get_commands()
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/core/management/__init__.py", line 107, in get_commands
    apps = settings.INSTALLED_APPS
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/conf/__init__.py", line 54, in __getattr__
    self._setup(name)
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/conf/__init__.py", line 49, in _setup
    self._wrapped = Settings(settings_module)
  File "/Users/dcramer/.virtualenvs/getsentry/lib/python2.7/site-packages/django/conf/__init__.py", line 132, in __init__
    % (self.SETTINGS_MODULE, e)
ImportError: Could not import settings 'sentry_config' (Is it on sys.path? Is there an import error in the settings file?): No module named sentry_config
```

In this case 'sentry_config' is a virtual module managed by https://github.com/dcramer/logan via an import hook.


@dcramer This is interesting timing, as we're about to release 2.6.1. We believe 2.6.1 contains some fixes in this area. Do you mind trying the current master to see if that solves your problems?


@Lukasa I did try the referenced sha (which was master an hour or so ago) and it still exhibited the same issue. It's possible this is an issue in Logan, but the code there isn't very hacky (and I'm mostly certain its correct).


@dcramer The easiest way to verify that this is the source of the problem is to replace `requests/packages/__init__.py` with an empty file and see if the problem still appears. (I'm assuming you've already verified that the problem doesn't appear with some earlier version of Python.)


Confirmed it's the import hook present in requests.packages (via the above).


Does Logan play well with other tools that register meta_path hooks? Have you tested it with any of them?


Also what version of Logan are you using to get that traceback? The line numbers are wrong compared to master on Logan. Is it possible this is fixed in Logan already?


We're using the previous major version, but I tested (and actually tried to debug/throw random fixes in) on the latest logan.

Seemingly both packages are doing similar things, barring that requests tries to replace meta_path at one point.

Ideally Python would document some of this so people wouldn't have to guess so much as to the "right way" to do these things.


> Seemingly both packages are doing similar things, barring that requests tries to replace meta_path at one point.

@dstufft can speak best to why we replace it, but I believe we only filter out instances of our own hook to prevent infinite recursion when first attempting to import the name given to us.

That shouldn't be a big problem here though because the import error looks like it's probably coming directly out of Django.

Either way this will be fixed by 3e3fc76 in 2.6.1