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

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Comments

heddn created an issue. See original summary.

heddn’s picture

Issue summary: View changes
effulgentsia’s picture

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

effulgentsia’s picture

The con to using the PHP API are (theoretical) composer dependency issues that get resolved if we contain an embedded phar file.

This seems to imply that phar files can only be exec'd and not include'd, but even if we end up having to contain an embedded phar file, what prevents us from being able to include it and still use the PHP API? Is the issue that the phar file will contain classes (e.g., Symfony's EventDispatcher) 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?

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.