[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:  5.9
Component:  External Libraries                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-dev-note php80       |     Focuses:
  php81                                          |
-------------------------------------------------+-------------------------

Comment (by schlessera):

 As @jrf already stated, Requests is still considered an external, third-
 party dependency, which moved from the `ryanmccue` personal GitHub account
 to the `wordpress` organization GitHub account. Requests has never adhered
 to the WordPress Core coding style. And now it has adopted PSR-4 and most
 PSR-12 conventions.

 The correct way to name it according to the code style in place in the
 repository and the conventions in place in the larger PHP ecosystem would
 have been to use `Wordpress\Requests` (note the lower-case P, part of the
 convention for PSR-4). We wanted to avoid that for obvious reasons, as
 Requests is neither a part of the actual WordPress CMS, nor did we want to
 set a precedent for namespacing Core. What we have now is therefore `under
 the 'wordpress' GH org` as a namespace.

 > Thanks for the context! Since PHP namespaces are case-insensitive, is
 there any chance to capitalize that as WPorg\Requests\, so that the
 capitalization of WP is consistent in lines like this and across the
 project in general?

 {{{#!php
 new WP_REST_Request( WPorg\Requests\Requests::POST, $route );
 }}}

 The above would actually be expected to use an import, which would turn
 the code into:
 {{{#!php
 new WP_REST_Request( Requests::POST, $route );
 }}}

 The import itself can be automatically generated/managed by any decent IDE
 or code quality tool, so you would never type that namespace anyway.

 Case-insensitive class names are often an issue if you work on multiple
 filesystems because any string comparisons to deal with the namespace
 (most notably in autoloading) tend to break. That's why most code quality
 tools will flag these as errors, and Composer explicitly does not even
 support them. I wouldn't be surprised if PHP decided to make them case-
 sensitive in a later version, as they are slowly getting rid of all and
 any ambiguities that might introduce bugs.

 I see no reason why the class name would be problematic, as with proper
 usage, it becomes inconsequential.

 Also, just as a final remark, @jrf and me (well @jrf, mostly) invested
 lots of time and energy in making a library that is a critical dependency
 of WordPress Core but had fallen into disrepair usable and maintainable
 again. A lot of thought went into everything, to ensure it works both as a
 dependency of WordPress Core as well as a useful package for any other PHP
 project that is depending on it, while maintaining backwards compatibility
 whenever we could. The entire endeavour was planned in such a way that
 pulling in the latest version is as frictionless as possible and can
 mostly just be automated. It would now be a total waste of contributor
 time to make changes just for the sake of it. However, I understand people
 feel strongly about the "WP brand/trademark". But I for one will not
 accept this additional effort be taken on by the Requests package. As a
 consumer of the Requests library, WordPress Core is of course free to
 render the process as efficient/inefficient as it wants, but I don't see
 any valid reason why the Requests package should adapt to that.

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