[policy, no patch] composer.phar vs. API (automatic updates)

Created on 17 July 2020, over 4 years ago

Updated 4 September 2024, 4 months ago

This is closely related to #3159972: [policy, no patch] Require Composer 2 for Automatic Updates while still supporting Composer 1 for Drupal 9 generally → . After we have some type of composer v2 available to us, what type of availability should it be? We could embed a version of composer as a phar file. Or we could create a run-time dependency on composer/composer: ^2 that exposes us a PHP API

The pros to use the PHP API is we have an actual API.
The con to using the PHP API are (theoretical) composer dependency issues that get resolved if we contain an embedded phar file.
Con to using a phar file is a error out/sys out from calling exec does not make a good API and contains a high risk of being fragile

📌 Task

Status

Closed: outdated

Version

11.0 🔥

Component

Base →

Last updated about 3 hours ago

Created by

heddn Nicaragua

Live updates comments and jobs are added and updated live.

Incomplete comments

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Comment 4 months ago →
🇳🇿New Zealand quietone
Status changed to Closed: outdated 4 months ago2:40pm 4 September 2024
Comment 4 months ago →
🇺🇸United States effulgentsia
Automatic Updates ended up executing Composer via Symfony's Process component which uses proc_open. In other words, the composer.phar option.

Production build 0.71.5 2024