Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
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
Proposed resolution
- 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
Comments
Comment #2
heddnComment #3
effulgentsia CreditAttribution: effulgentsia at Acquia commentedComment #5
effulgentsia CreditAttribution: effulgentsia at Acquia commentedThis seems to imply that phar files can only be
exec
'd and notinclude
'd, but even if we end up having to contain an embedded phar file, what prevents us from being able toinclude
it and still use the PHP API? Is the issue that the phar file will contain classes (e.g., Symfony'sEventDispatcher
) that conflict with what's already loaded into Drupal? Is it possible to resolve this by building the phar file with an autoloader that accounts for that?