-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
backport of #32305 causes regressions in various packages #77053
Comments
The backport of issue bpo-32305 causes regressions in several packaged namespace packages: https://bugs.debian.org/890621 while the change is intended, is it appropriate to backport it to 3.6? Please could you have a look, you might still have an appropriate chroot laying around ;) |
Both of those upstreams should be using |
Now that we know that this change *does* break some existing code, I think it is worth having that talk as mentioned in PR 5481: "I suppose it's possible that this will break existing code, but I'd argue that because current behavior runs counter to the documentation and makes no sense given the inconsistencies, it is better to fix them. I propose this change be applied to 3.7 and 3.6, although if you, my friendly reviewer, disagrees about 3.6, we can talk about it!" The question I have is: is the problem the backport is trying to fix severe enough to cause package regressions in the middle of a maintenance release cycle? Sure, the third-party packages should be fixed and such a change is fine for 3.7 but we also kinda promise that installing a maintenance release should be painless. I don't know what is the right answer and I don't want to spend a lot of time on this but I'd like to get a bit more input on this before we go ahead with releasing it in 3.6.5. |
I'm personally fine if the change gets reverted. I don't think the odd behaviour is severe enough to justify breaking projects in a maintenance release. Besides, they will learn soon enough about their code breaking in Python 3.7. |
+1 from me for making the change 3.7.0+ only - 3.6 isn't doing the right thing, but given folks are relying on it doing the wrong thing, then let's leave it alone given where it is in its lifecycle. |
OK, I agree with Brett and Nick. Barry, are you OK with reverting this change for 3.6? If so, can you do the honors? |
I'd personally prefer to keep the fix (I ran into some problems w/3.6), but I'll defer to the RM. I'll revert the change for 3.6, but I want to test it with importlib_resources first, since I'll probably have to spin a new release of that package too. |
Thanks, Barry! I don't see that either action is ideal but I am concerned about breaking third-party packages and 2 (already known) breakages is worrisome. And thanks, @Doko, for bringing the matter up. |
reopening. Lib/test/libregrtest/setup.py still needs fixing at least on 3.6, I didn't check the trunk. libregrtest/setup.py: 60c60
|
reopening. Lib/test/libregrtest/setup.py still needs fixing at least on 3.6, I didn't check the trunk. libregrtest/setup.py: 60c60
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: