Use Composer's internal API to access ::getInstalledPackages()

Created on 1 September 2022, about 2 years ago
Updated 6 February 2023, almost 2 years ago

Problem/Motivation

We currently use \Drupal\package_manager\ComposerUtility::getInstalledPackagesData to access Composer's installed.php data. That works today, of course, but it might be better (safer) to use Composer's own code API to shield ourselves from future implementation detail changes in Composer.

Steps to reproduce

n/a

Proposed resolution

\Composer\InstalledVersions::getInstalledPackages() seems like the obvious API candidate, but it's dependent on its own __DIR__, without a way to specify an alternative path. Therefore, it can't be used as-is from the active directory on the staging directory. There are a few possible workarounds to this limitation, each with their own benefits and drawbacks which will not be fully outlined here:

  • Fork the class, making it possible specify a path
  • In the appropriate request, modify the class loader at runtime to point to the class in the staging directory
  • Find an alternative approach that doesn't involve using installed.php at all.

We may find some inspiration in these libraries:

Remaining tasks

tbd

User interface changes

n/a

API changes

tbd

Data model changes

n/a

πŸ“Œ Task
Status

Closed: outdated

Version

2.0

Component

Package Manager

Created by

πŸ‡ΊπŸ‡ΈUnited States traviscarden

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.

Production build 0.71.5 2024