Import aliases for Debian

Alternative to #2375, on the risk of being naive...


@sigmavirus24 You own this logic for the most part: how does this look?


Also I suppose it'd be nice if @dcramer tries this (because of https://github.com/kennethreitz/requests/issues/2558)


It _looks_ okay but I want to toy with it a bit before we merge it.


If you're fine with this, I'd like to add a module docstring (or comment) that explains the whole situation before merging.


@untitaker why not just add it while I'm testing it?


I just meant to say that so you don't merge this too soon.


From my POV this seems safe. @mitsuhiko might have better feedback


@untitaker thanks for working on this. Just for reference, here is what it's used in Debian at the moment:
https://anonscm.debian.org/viewvc/python-modules/packages/requests/trunk/debian/patches/04_make-requests.packages.urllib3-same-as-urllib3.patch?revision=32576&view=markup

Yes, I'm exporting only urllib3 since importing chardet from requests.packages seems not used, at least no one complained about this.

I choosed to not cherry pick  #2375 due the problems emerged: I don't want Debian and Ubuntu users to have a system version of requests not in the best shape: it will give only more problems.


Seems good @eriol. Would you adopt a solution offered by requests though, to avoid Distro-specific breakage?

BTW @sigmavirus24 this is ready for review.


@untitaker of course I will like to drop a custom patch! :smile:
I had to write more to explain better my opinion, sorry for this. My opinion is that less divergence from upstream is the better, and it's for this reason that I forward all modification non Distro-specific to upstream.
Furthermore the Debian patch is not perfect, see [Debian Bug #771349](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771349).
So to recap I will be extremely happy to drop 04_make-requests.packages.urllib3-same-as-urllib3.patch in favor of an upstream solution.
Thanks!


This works well for me. Objections to merging @Lukasa?


@sigmavirus24 I'm super reluctant to rush this out, given the way stuff previously went. Can we try to tap people who've had problems/objections in the past and get them to confirm that this works better for them?


I'll try to reach mitsuhiko


@untitaker did you mean @mitsuhiko? I would hope a direct ping would suffice.

---

@Lukasa I would argue this is probably, on the whole, better than our previous meta_path hackery for several reasons:
1. It provides the same functionality
2. It's significantly simpler (simple is better than complex)
3. It allows for all of this to work in the case where requests is vendored without its vendored dependencies (see @untitaker's use of `__name__` when adding the alias to `sys.modules`)
4. It doesn't mess with other meta_path plugins (e.g., PyInstaller, the hack that @dcramer and @mitsuhiko are using, etc.)
5. It falls back in the correct order
6. It's far easier to explain to someone
7. When urllib3 is not vendored, the following works as we'd like it to:
   
   ``` py
   import urllib3
   from requests.packages import urllib3 as rurllib3
   urllib3 is rurllib3
   ```

I have yet to test this with PyInstaller, but the root of the problem there was the fact that our meta_path plugin was in the wrong place relative to the multiple plugins that PyInstaller uses. So with that removed, this should just work. I'm also confident that if @mitsuhiko and @dcramer test this with their code that hacks the meta_path, then they'll not see any problems.


@sigmavirus24

> @untitaker did you mean @mitsuhiko? I would hope a direct ping would suffice.

Unfortunately I don't think so. I haven't heard back from him either, perhaps
@dcramer can ping him about that?

---

@eriol BTW this should also remove the need to rewrite every import statement
inside requests itself.


@sigmavirus24 I'm not disputing better at all. =) What I'd like to do is to take all reasonable precautions to reduce the risk of deploying this fix. For example, can @eriol and @ralphbean confirm that their package building functions correctly with this patch?

Basically, rushing helps nobody, and I'd like to try to begin a run of stable requests releases if at all possible. The last run of four-or-five broken releases in a row is bad, and we need to not get in the habit of doing that.


@Lukasa Note that I'm not arguing for this to be merged with a release to follow immediately after. We could even defer this to 3.0 if you want to not rush it (which I don't think we're doing frankly). The current state of affairs only makes end users' lives more difficult at this point.


@Lukasa if is it possible I would like to have a bit more of time: right now I'm checking reverse dependencies of requests in Debian to not break stuff, see: https://lists.debian.org/debian-python/2015/05/msg00021.html (@sigmavirus24 thanks for details, I did not have time to reply on the list, but your mail was appreciated :smile:).
I should finish during this week, so should be able to cherry pick and test this immediately after.


@eriol always happy to help. We don't have a release planned so we don't have a timeline for when this would be merged. Take your time. Don't stress out. We'll be here and so will the patch. =D


How to down the the code?


@wangshaochen you can just add ".patch" to PR URL:
https://github.com/kennethreitz/requests/pull/2567.patch

HTH!


@eriol  Ths!  I yet don't know. with command_line? 


It's not clear what you want to do. Could you tell us more?


i'm sorry. this is my first-time  see it.


@Lukasa @sigmavirus24 any updates on this?


We're still hoping to have @eriol and/or @ralphbean take a swing at this code and confirm it's working for them.


I waited to upload requests 2.7.0 in unstable (I uploaded into experimental first) to give httpie maintainer the time to update Debian package (we had httpie 0.8).
Unfortunately this week I'm too busy, so I can cherry pick and test only starting from next week.


Looks good here!


Sorry for the delay! I have tested it and all seem fine! Many thanks @untitaker!


\o/ Alright, I'm happy to cautiously wave this through.