Closed bandgeekndb closed 3 months ago
Thanks for calling this out!
Thanks for pointing that out @bandgeekndb, for me it was having valet installed, once i removed that, installed takeout and then reinstalled valet i was good to go.
I had the same issue by installing Valet first. Since Valet will work with the v1 package, I was able to install takeout by allowing package downgrades with the -W
flag.
composer global require tightenco/takeout -W
Of course, this could break other packages. I used this on a new machine with only Valet installed so I knew there wasn't an issue. YMMV. I second adding a v2 constraint.
If you try to install Takeout after installing another package with Guzzle v7, you cannot install Takeout due to a dependency conflict.
For example, when installing Laravel Envoy, Guzzle v7 is a dependency and it requires the guzzlehttp/psr7 library with the following constraints:
"guzzlehttp/psr7": "^1.8.3 || ^2.1",
With nothing else constraining the psr7 package, Composer will install at least v2.1. Then, when you try to install Takeout after this, Composer can't recognize that stepping down to a v1 release would allow Takeout to install.
If you install Takeout first, you get v1 of the psr7 package and then installing Envoy after this just uses the existing v1 package installed since that is acceptable.
I think the simplest solution would be to add a compatible v2 version to our psr7 dependency. I don't have the time right now to test that change, so I wanted to open this in case anyone else had the bandwidth to make it happen. Otherwise, I'll circle back to this when I can and open a PR.