-
-
Notifications
You must be signed in to change notification settings - Fork 9.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unbundling logic still breaks downstream. #2870
Comments
The issue I'm seeing is that, after importing first
Importing
but |
So we definitely broke this. On the other hand, I don't really understand the Python import logic well enough to effectively fix this problem. Thoughts? |
See also https://github.com/kennethreitz/requests/issues/2867 That SO question was about 2.6.0 I thought. Is this still a problem with 2.8.x? |
Oh that's a good point, did this get backported into the distros? |
So 2.6.x has the old VendorAlias logic from pip. 2.7.0 had nothing but some distros (Debian specifically, more specifically @warsaw) backported the patch from @untitaker that was released in 2.8.0. So version information is very important here. |
My recollection is that @fasaxc was using 2.7.0 from Ubuntu 14.04 trusty-liberty, but I may be mistaken. |
Ubuntu may have pulled in Debian's patch from @warsaw. In that case, this is still relevant. (Alternatively, Ubuntu may have continued using the VendorAlias from 2.6.x and we should check that.) |
If it turns out that Debian actually does have the new logic, I'd say it's a good time to think about actually giving up on vendoring urllib3. On 10 November 2015 16:20:13 CET, Ian Cordasco notifications@github.com wrote:
Sent from my phone. Please excuse my brevity. |
@untitaker I can understand that, but I don't believe we can really discuss doing that unless we get the whole team together, which realistically means PyCon 2016. |
On Nov 10, 2015, at 07:20 AM, Ian Cordasco wrote:
Ubuntu tracks the Debian version. There are no deltas, except for some % rmadison -u debian requests % rmadison -u ubuntu requests |
|
I believe so, yes. |
On Nov 10, 2015, at 06:24 AM, Cory Benfield wrote:
Don't forget, @eriol is really doing most of excellent work on this package Our 2.8.1-1 removed the devendorizing patch we were carrying separately, so https://anonscm.debian.org/cgit/python-modules/packages/requests.git/tree/debian/patches Of course, we prefer to reduce the differences between the Debian version and |
Hmm. Can we attempt to discover whether this problem exists in Debian's released packages for 2.8.x? |
Lukasa, who do you mean exactly when you say "the whole team"? Isn't Kenneth some sort of BDFL, so his decision would suffice? On 10 November 2015 16:51:56 CET, Barry Warsaw notifications@github.com wrote:
Sent from my phone. Please excuse my brevity. |
@untitaker He is, correct. However, of the three maintainers he's the one opposed to unbundling. Ian and I are both unanimous that we'd like to unbundle. However, we have a duty of care over this library, and that includes not changing things that Kenneth cares a great deal about without his explicit say-so. I don't want to have a detailed discussion with Kenneth about this remotely, because this issue is close to all our hearts and we should discuss it in an environment that makes it easy for us to treat each other like humans, with respect and kindness. Those two qualities are often lost online, and that would be a tragedy: our working relationships are more important than that. |
@Lukasa I'm sad to confirm but yes, the problem actually exists in Debian testing (with the new import machinery). On Debian this is what I got: import requests
import urllib3
from urllib3.exceptions import MaxRetryError
print(urllib3.exceptions.MaxRetryError is MaxRetryError) # False I'm real sorry I did not noticed when we discussed https://github.com/kennethreitz/requests/pull/2567. I'm not neither an import logic expert, but your proposal seems the only way to fix this, without unvendoring. Maybe we can ask to @brettcannon if he can take a look at this: I can volunteer to recap all the story so far. Also, I just want to say thanks to you, @sigmavirus24 and @kennethreitz because although you can just mark this as wontfix, we started working together talking without forget that we are all human beings. |
@eriol Thanks for investigating. =) And thanks for working with us on this. Again, I can't reiterate enough, it's really important to us to get to a place where everyone's getting a good experience. We're not there yet, but we'll keep trying. I'd be delighted to see if someone who knows the import machinery really well can propose a better solution to this problem. If you're willing to do the legwork on ramping up @brettcannon that would be even better @eriol. Otherwise, we should aim to take that boring manual step or see if we can avoid the problem in requests in some other way. |
We should do this as a stop-gap solution for now. It will benefit the users and it's trivial for now. Meanwhile we should investigate longer-term solutions to this. |
I'm traveling this week but I can try and take a look next week. |
Basically @fasaxc is right in his analysis of the problem. The tricky bit is that this is all influenced by how you actually import something. You have to realize each of the following statements use slightly different logic to get you what you want: import urllib3.exceptions; HTTPError = urllib3.exceptions.HTTPError
from urllib3 import exceptions; HTTPError = urllib3.exceptions.HTTPError
from urllib3.exceptions import HTTPError If you use the last approach then that will definitely trip you up in this instance because import will do an explicit import for Now to solve this, @Lukasa was right and you can just patch every module in |
Thanks so much @brettcannon. 🍰 is owed. =) Ok folks, given the set of solutions proposed, does anyone have preferences? |
Thank you @brettcannon! |
So I'm enumerating the options and asking questions to make sure I understand correctly.
As in, ensuring that
We had that option and it broke many a thing. I'm not in favor of going back down that route.
Hm. This sounds like something in the vein of option 2 but a little less magic-y. It still feels like some abuse of the module system and like it might cause us problems. If we come up with something like this, I would appreciate it if @fasaxc and @eriol would commit to testing this with python-etcd and making sure things still aren't broken before shipping a release with it.
Breaking this into two sub-suggestions:
My 2¢: We can take a short term solution of the first option for a |
@brettcannon many thanks! I'm also in favour of the less magic solution. @sigmavirus24 I really appreciate your words, thanks! |
On Nov 17, 2015, at 06:14 AM, Ian Cordasco wrote:
It's mildly disconcerting that a library would fiddle with another library's
Yep, I suspect that #1 may be the best approach, and that #3 would be Thanks! |
I created http://bugs.python.org/issue25649 for the aliasing idea that @warsaw had (I wouldn't count on it getting a blessed solution, but you never know :) . And just to toss in my opinion, the explicit aliasing is the safest, most compatible way to do things (it's still not fool-proof since |
With the recent unbundling, I'm closing this as it should no longer be an issue. |
Just a quick note to say also that I was able to drop all the Debian specific patches: https://tracker.debian.org/news/860709. |
Originally reported by @fasaxc. Interested parties: @sigmavirus24 @dcramer @eriol @ralphbean @warsaw
We added support for a new form of unbundling logic in #2567. Unfortunately, this seems not to work properly. Specifically, the presence of requests in a system makes it impossible to catch urllib3 exceptions correctly: see this Stack Overflow question for more.
This problem seems to specifically affect the urllib3 sub-packages, not urllib3 itself. One proposed change is to add every urllib3 sub-package that gets imported to the list of modules requests explicitly imports in this stub file. This is pretty gross, but might work. Does anyone have other suggestions?
The text was updated successfully, but these errors were encountered: