Postponed on #3220220: Update guzzlehttp/psr7 to 2.1.0.
Problem/Motivation
Guzzle 7 is compatible with PSR-18 out of the box, but PSR-17 compatibility is only available with the 2.x branch of the guzzlehttp/psr7 component. (Yes, they acknowledge that the naming is confusing.)
Drupal currently uses Diactoros for its PSR-17 implementation. However, Laminas projects have recently adopted a policy of placing an upper bound on PHP version compatibility, meaning we need to wait for them to do a release after every PHP minor in order to support that minor, which means we could go 6+ months without supporting the latest PHP version. Therefore, it is desirable to look for alternatives to the Laminas packages.
Once #3220220: Update guzzlehttp/psr7 to 2.1.0 lands, PSR-17 support is available in Guzzzle and we can attempt to use it.
Proposed resolution
See if we can swap out Diactoros' PSR-17 implementation for Guzzle's.
Remaining tasks
TBD
User interface changes
N/A
API changes
TBD (but the PSR interfaces are supposed to be the public API, so...)
Data model changes
TBD
Release notes snippet
10.0.0: Composer dependency laminas/laminas-diactoros is removed. The functionality is now provided by Guzzle. If you have any project that depends on Diactoros' code beyond the functionality previously provided by core (uncommon), ensure sure it is declared as a dependency in your composer.json or change the code to use Guzzle.
9.4.0: Drupal 10 will switch from laminas/laminas-diactoros to Guzzle. It should not be necessary to make any changes unless you are directly referencing Diactoros classes. If your project does depend directly on any Diactoros code (uncommon), you should make sure it is declared as a dependency in your composer.json or change the code to use Guzzle.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 3255243-15.patch | 9.79 KB | kim.pepper |
| #9 | 3255243-8.patch | 9.79 KB | longwave |
Comments
Comment #2
gábor hojtsyComment #3
longwaveIncludes #3220220: Update guzzlehttp/psr7 to 2.1.0, the additional changes are pretty straightforward.
Comment #4
longwaveBeing bold and marking this straight off as NR as the tests passed and the changes are minimal.
Do we want to remove
laminas/laminas-diactoroshere as well?Comment #5
gábor hojtsyFail on PHP 8.0 is due to #3255439: Update PHP 8.0.0 to PHP 8.0.13 on DrupalCI to allow Drupal 10 testing on PHP 8.0.x.
Comment #6
gábor hojtsyRe removing
laminas/laminas-diactoros, if this is the only reason we used it, IMHO this would be the best place to remove it.Comment #7
longwaveComment #8
gábor hojtsy#3220220: Update guzzlehttp/psr7 to 2.1.0 was committed just now so this needs to be updated.
Comment #9
longwaveRerolled :)
Comment #10
gábor hojtsyI think the only question here is what to do in a Drupal 9.4 variant of this patch? How to deprecate a purely 3rd party library where we are not wrapping it? The Drupal 10 patch looks RTBC though :) Tagging to make sure a release manager considers that question.
Comment #11
longwaveRe #10 I think we just add it to the release notes of 10.0.0 - if anyone is using
laminas/laminas-diactorosideally they should depend on it explicitly anyway, and they can easilycomposer requireit if their code breaks following the upgrade.Comment #12
gábor hojtsyTagging for needing release notes and to be included in release notes then.
Comment #13
andypostit needs CR now to pro
As `guzzlehttp/psr7` used now
Comment #14
alexpottNeeds a reroll because composer.lock conflicts.
Comment #15
kim.pepperRan the command:
COMPOSER_ROOT_VERSION=10.0.x-dev composer update --lockComment #16
alexpottThanks @kim.pepper.
Comment #17
alexpottCommitted d9e7844 and pushed to 10.0.x. Thanks!
Comment #19
catchRetrospectively untagging. Encouragingly easy one.
Comment #20
xjmWow, great to see this in! So glad this was as straightforward and I'd dared hope it might be.
We do need some way to notify people of this change prior to D10. Haven't we raised deprecation warnings in the past when we remove a core Composer dep?
At a minimum we will say it is deprecated in the 9.4.0 release notes, but in the past we've been able to raise deprecation warnings related to it.
Comment #21
catchI don't think we have. In this case code should only be relying on this via the services, and the API of those doesn't change.
For direct usages despite this, if a module depends on a composer dependency directly, they'll still get it pulled in. If they don't, they could get a hard break but we can't account for modules not declaring dependencies like that.
Searching contrib for Diactoros\Response finds a lot of what looks like incorrect type declarations (RedirectResponse, AjaxResponse) which should be pointing to Symfony's classes instead. This looks already-broken to me.
Usage of the things we're actually replacing here doesn't show up.
http://grep.xnddx.ru/search?text=Diactoros%5CResponse&filename=
The only core references we're changing outside of services.yml is in a couple of tests. For those cases it would be theoretically possible to provide a bridge class in 9.4.x and 10.0.x (extending Diactoros and Guzzle respectively), but don't think we should unless we can find a contrib usage.
Comment #22
xjmI fixed the release notes to tell people what to do (declare their dependencies correctly) based on #21. Thanks!
Comment #23
xjmAdding CR link to the release notes as well.
Comment #24
xjmBetter place for the link.