Contrib.social

Remove our runtime dependency on composer/composer: remove ComposerUtility

Open on Drupal.org →
Created on 19 October 2022, over 1 year ago
Updated 10 March 2023, over 1 year ago

Problem/Motivation

We currently have a runtime dependency on composer/composer. This is mainly so we can invoke Composer's API to get information about what packages are currently installed (in either the active directory or staging area). The bulk of that takes place in Package Manager's ComposerUtility class.

This architecture, however, means that core will need to make composer/composer a runtime dependency in order to support Automatic Updates. @effulgentsia opened a policy issue for that, which has honestly not seen a ton of action ( 📌 [policy] Move composer/composer from a dev dependency to a production dependency Closed: won't fix ). Although one knowledgeable person did weigh in and emphatically asked us NOT to do it: #3243899-10: [policy] Move composer/composer from a dev dependency to a production dependency → .

That got me thinking: do we really need to have this runtime dependency? Is there no other way to get the information we need from Composer? There is a very clear benefit to being able to remove the dependency, namely that we don't have an additional dependency (and we sidestep any runtime issues that folks might encounter).

Another problem is that ComposerUtility is not API-compatible with both Composer 2.2 and 2.3+. This problem was only revealed while trying to make Automatic Updates Drupal 10-compatible, since Drupal 9's constraints will implicitly force the installation of Composer 2.2. This plan would effectively eliminate this problem, and advance Drupal 10 compatibility.

After some thought, I propose that we absolutely have a path to removing the runtime dependency. Rather than relying on Composer's API, I think we can instead rely on two things to get the information we need:

  • The installed.php that Composer generates when packages are installed or updated. We already rely on this quite a bit in ComposerUtility.
  • The output of various Composer commands. We already rely on this in ComposerExecutableValidator, for a start, but Composer has a very robust command-line interface.

Eventually, I think we might even be able to drop the first item, since installed.php is technically internal to Composer, and rely solely on the output of Composer commands. But that could be done later.

Here's the path I think we should take:

  1. 📌 Add new InstalledPackagesList which does not rely on Composer API to get package info Fixed Right now, we have a method in ComposerUtility called getInstalledPackages(), which uses Composer's API to return a keyed array of PackageInterface objects. I propose we replace that with two classes: InstalledPackage, which is a simple read-only value object representing a single installed package, including the information that can be gleaned from installed.php. There would also be an InstalledPackagesList object, which would include most of the functionality currently in ComposerUtility, but its getInstalledPackages() method (or some other name) would return InstalledPackage objects, not PackageInterface. This class would rely only on the information in installed.php, and never try to load Composer's API.
  2. We would add new methods to Stage: getInstalledPackages() and getStagedPackages(). Each would return an InstalledPackagesList object. Stage's getActiveComposer() and getStageComposer() methods, along with ComposerUtility, would be deprecated.
  3. ComposerUtility::validatePackageNames() would be replaced by a new validator that subscribes to PreRequireEvent. This subscriber would write a fake composer.json to a temporary directory, and put all the required packages into its require section. Then it would run composer validate /path/to/fake/file, which would quickly validate that all the requirements are legitimate. This is proceeding in 📌 Stage::validatePackageNames() should not use the Composer API Fixed .
  4. 📌 ComposerSettingsValidator should run `composer config` to determine if HTTPS is enabled Fixed
  5. 📌 ComposerPatchesValidator should use ComposerInspector instead of ComposerUtility Fixed
  6. 📌 ScaffoldFilePermissionsValidator should use ComposerInspector instead of ComposerUtility Fixed
  7. 📌 Updater should use ComposerInspector instead of ComposerUtility Fixed
  8. 📌 ExtensionUpdater should use ComposerInspector instead of ComposerUtility Fixed
  9. 📌 \Drupal\automatic_updates_extensions\Form\UpdateReady should use ComposerInspector instead of ComposerUtility Fixed
  10. 📌 \Drupal\automatic_updates_extensions\Form\UpdaterForm should use ComposerInspector instead of ComposerUtility Fixed
  11. 📌 UpdateReleaseValidator should use ComposerInspector instead of ComposerUtility Fixed
  12. 📌 GitExcluder should use ComposerInspector instead of ComposerUtility Fixed
  13. 📌 UnknownPathExcluder should use ComposerInspector instead of ComposerUtility Fixed
  14. 📌 OverwriteExistingPackagesValidator should use ComposerInspector instead of ComposerUtility Fixed
  15. 📌 SupportedReleaseValidator should use ComposerInspector instead of ComposerUtility Fixed
  16. 📌 CollectIgnoredPathsFailValidator should use ComposerInspector instead of ComposerUtility Fixed
  17. 📌 FakeSiteFixtureTest should use ComposerInspector instead of ComposerUtility Fixed
  18. 📌 StatusCheckTraitTest should use ComposerInspector instead of ComposerUtility Fixed
  19. 📌 RequestedUpdateValidator should use ComposerInspector instead of ComposerUtility Fixed
  20. 📌 VersionPolicyValidator should use ComposerInspector instead of ComposerUtility Fixed
  21. 📌 \Drupal\automatic_updates\Form\UpdateReady should use ComposerInspector instead of ComposerUtility Fixed
📌 Task
Status

Fixed

Version

3.0

Component

Code

Created by

🇺🇸United States phenaproxima Massachusetts

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

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

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024