[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:  6.0
Component:  External Libraries                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  php80 php81 has-patch has-unit-      |     Focuses:
  tests early early-like-actually-early          |
-------------------------------------------------+-------------------------

Comment (by jrf):

 For everyone here now debatting the issue, while not having read the
 complete thread or the changelog, let me make something very clear:

 == **The namespacing in Requests 2.0.0 and the file renames are NOT a BC-
 break.**

 Let me repeat that: **The namespacing in Requests 2.0.0 and the file
 renames are NOT a BC-break.**

 The BC-break will come in Requests 4.0.0 a few years down the line.

 Yes, the code in Requests is now namespaced, but there is a full backward-
 compatibility layer in place and using any of the old class names (like if
 plugins use Requests directly) will still work without problems.

 When an old class name is requested, a deprecation notice is thrown. but
 for the lifetime of Requests 2.0.0, that deprecation notice can be
 silenced by setting a `REQUESTS_SILENCE_PSR0_DEPRECATIONS` constant. This
 has been implemented like this specifically with WP in mind, so plugins
 which use Requests directly and needing to support multiple WP versions
 can do so without issue.

 Yes, there have been some file renames, but again, this is not a BC-break.

 From the very beginning, Requests has had two "entry-points" for loading
 the files:
 1. Autoloading via a Composer generated autoloader.
 2. Autoloading via a custom autoloader which is included with the Requests
 code.

 The file renames, including the case-only renames, are handled 100%
 correctly by the both autoloaders.


 So where is the BC-break in this whole story ? Well, registering the
 custom autoloader has changed in Requests 2.0.0 and that change is
 effectively a two line change and was already included in the patch and
 will not affect plugins.

 So what is this BC-break I mention above in Requests 4.0.0 ? Well, that is
 the version in which it is the intention to remove the BC-layer.

 ----

 Now back to the problem at hand: what's breaking here is not Requests
 2.0.0. What's breaking is that the WP upgrader process is trying to use a
 mix of files from Requests 1.x and 2.x during the upgrade process and
 isn't equipped to handle case-only file renames.

 Am I surprised that that break things ? No, as that's a very clear bug and
 code smell. But it's a bug in the upgrader, not in Requests.

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