[wp-trac] [WordPress Trac] #54504: Update Requests library to version 2.0.0

[WordPress Trac]

#54504: Update Requests library to version 2.0.0
-------------------------------------------------+-------------------------
 Reporter:  jrf                                  |       Owner:
                                                 |  SergeyBiryukov
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  External Libraries                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  php80 php81 has-patch has-unit-      |     Focuses:
  tests early early-like-actually-early          |
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:75 schlessera]:
 > **Requests v2 does not break backwards compatibility with v1**.
 > ...
 > The reason why this was not cleanly integrated into WordPress Core is a
 very different one:
 > ...
 > @azaozz I would be grateful if you would stop repeating such incorrect
 statements - pretty much everyone else has been very vocal

 Uhhh, it seems we are still talking about different things :(

 I cannot understand what you mean by "v2 does not break backwards
 compatibility with v1". Tried replacing v1 with v2 in trunk and got this:
 {{{
 Fatal error: Interface 'WpOrg\Requests\HookManager' not found in /src/wp-
 includes/Requests/Hooks.php on line 19
 }}}

 How a fatal error is not breaking back-compat? If backwards compatibility
 was maintained, there wouldn't be any need to modify any other code
 outside of the Requests directory. However looking at
 https://github.com/WordPress/wordpress-develop/pull/1624/files#diff-
 339369deb37417feede85bbf7991a48f8ad44ec96e389ed42cecda99f2f2e98a there
 seem to be many changes to other WP files.

 Another, perhaps larger part of the problems here is: what should an open
 source project do with contributions that do not follow its philosophy and
 seem to be disregarding its rules? As far as I've seen most open source
 projects do not accept contributions that refactor code without a good
 enough reason. The "improved maintainability" by renaming
 functions/methods and adding namespaces seem more of a personal preference
 here. WordPress is mostly legacy PHP code, this is not an exception.

 As I said above, a refactoring would have been warranted if it added new,
 needed functionality or significantly improved the existing functionality.
 This is not the case in Requests 2, unfortunately.

 So what should the WordPress Open Source project do with such
 contribution? Seems there are two options:
 1. Fork it's own sub-project and maintain it as part of core. This means
 Requests 1 will need to be patched to be PHP 8+ compatible as part of
 core. It also means the Requests library will have to be moved outside of
 https://github.com/WordPress/. Then the maintainers will be able to do as
 many changes as they want and follow their own philosophy and rules. I'm
 not looking forward to any of this :(
 2. The WordPress Open Source project would make an exception and accept a
 contribution that do not follow its philosophy and rules. This will be a
 bad precedent that may lead to other contributors attempting to do
 something similar in the future. Not looking forward to this either.

 What would you do if you had to decide which is the "lesser evil"?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54504#comment:78>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform