It looks like Drupal 10.1.0-beta1 rc1 updated the dependency version of 'guzzlehttp/promises' from 1.5 to 2.0.
Unfortunately, 'aws/aws-sdk-php' used by some modules is not compatible with 'guzzlehttp/promises’ 2.0, and this blocks the update to 10.1 stable (10.1-alpha does install).
The AWS SDK devs have acknowledged the issue, but it will not be addressed until at least August.
https://github.com/aws/aws-sdk-php/issues/2713
Promises 2.0 was just released a month ago on May 21st, so it would be nice to drop this version requirement to provide other components time to update.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 3368790-9.patch | 1.29 KB | longwave |
Comments
Comment #2
catchguzzlehttp/promises isn't a direct dependency of core afaik, so it's only pinned on composer.lock, not in composer.json afaik - unless I've missed something.
Are you using drupal/core-recommended or something else? And what does composer why-not say?
Comment #3
mr.white commentedYou’re right! It looks like Promises is actually a dependency of guzzlehttp/guzzle.
I was able to replicate this on a new project by running
composer create-project drupal/recommended-projectwhich installs Guzzle 7.7.0, which requires Promises 2.0.Here is a snippet of the relevant Composer tree.
Comment #4
mr.white commentedActually, I think I read the tree wrong…and Promises is actually a direct dependency of Drupal 10.1.
https://packagist.org/packages/drupal/core-recommended
Here is the full tree.
Comment #5
mr.white commentedComment #6
cilefen commented@catch is saying that core-recommended, which essentially locks dependencies, is not compulsory.
Comment #7
mr.white commentedI can understand that, but since 'core-recommended’ is the recommended option the implications are effectively the same, no?
I don’t imagine that 2.0 is in fact required by core - so this comes down to a packaging issue.
AWS a popular component used on many sites for backups an other things, so allowing these sites to update to 10.1 is likely in Drupal’s best interest.
Comment #8
longwaveWe could skip adding
guzzlehttp/promisestodrupal/core-recommendedby ignoring it inDrupalCoreRecommendedBuilder::getPackage(), we already do this forpsr/http-message. As Guzzle only uses this library internally and presumably does some kind of testing with both major versions, perhaps it is OK to loosen that constraint although we won't technically be testing Drupal with both major versions?Comment #9
longwaveComment #10
cilefen commentedIf we remove enough packages from the lock file we can deprecate it 🤪
Comment #11
longwaveI think there is an argument for removing all indirect dependencies from core-recommended, we should probably trust our dependencies to declare their dependencies correctly.
Comment #12
cilefen commentedcore-recommended-light?
Comment #13
catchI think we can trust guzzle to correctly declare dependencies on its own components anyway.
Comment #14
longwaveShould we commit this to 10.1.x only and assume everyone will upgrade by the time 10.2.0 is released in December?
Comment #15
catchYeah why not, we can always cherry-pick forwards if that turns out to be wrong.
Comment #16
mr.white commentedI guess to me it seems odd to keep this as a direct dependency at all, unless there is something specific in 2.0 (or Promises in general) that is required by core. I agree with @catch and would simply allow Guzzle to set its own dependancies in all versions moving forward.
Just my 2c, and I’m sure you guys know better than me what impact this has on core.
Comment #17
longwave@jabeler it is only a direct dependency of
drupal/core-recommended, which is a set of recommended packages because those are the ones that have explicitly passed our test suite. We have found in the past that sometimes different versions or combinations of versions of dependencies have issues when used with core, socore-recommendedwas created to provide a tighter set of dependencies than core alone. You are free to depend ondrupal/coreinstead ofdrupal/core-recommended, with the caveat that you might run into issues that our automated testing did not find.Comment #18
mr.white commentedThat makes sense.
I guess it also makes troubleshooting a lot simpler if most sites are using the same set of components.
Comment #20
catchCommitted/pushed to 10.1.x (only), thanks!