Switch from guzzle / psr7 to composer's HttpDownloader

[nicolas-grekas]

Composer already has a battle-tested HTTP client built in. What about leveraging it? That'd make the experience more consistent with composer itself.

[davisenra]

Not a contributor to the project, but this enhancement suggestion got me curious. What would be the optimal strategy for bringing Composer's HttpDownloader here? Had a brief look at Composer’s repo and noticed that src/Composer/Util/HttpDownloader.php is not an external dependency.

[nicolas-grekas]

Everytime I worked with composer, I "just" hacked around until I managed to make things work :) The first thing that needs to be decided is if this would be desirable in any ways. I can think of shared proxy/ssl/token/maintenance management for example. These look all highly desirable for the project to me.

[asgrim]

This is a great suggestion. I'll look into feasibility. For reference at the moment, PIE makes three HTTP calls using Guzzle:

• \Php\Pie\Downloading\DownloadZipWithGuzzle (GET to download zip itself)
• \Php\Pie\Downloading\GithubPackageReleaseAssets (GET to github api to find release assets for Windows systems)
• \Php\Pie\Installing\InstallNotification\SendInstallNotificationUsingGuzzle (POST to packagist for install stats)

Note that should we take on #48 (i.e. utilise the Composer Installer system) then this suggestion is possibly rendered obsolete anyway (as the Composer Installer would be using the HttpDownloader anyway).

[asgrim]

After #83 is merged, there is one place left (GH API calls in GithubPackageReleaseAssets) that uses Guzzle; should be simple enough to refactor that. Will start on this soon.

[asgrim]

I have a branch ready to update GithubPackageReleaseAssets to use Composer HttpDownloader, but I need to get #83 merged first :+1: