Contrib.social

[policy, no patch] Automatic Updates & Project Browser, should NOT handle dependency management for projects not known to Composer

Open on Drupal.org →
Created on 22 August 2022, over 2 years ago
Updated 14 May 2025, 2 days ago

Problem/Motivation

Automatic Updates and Project Browser are being developed in contrib with a plan for Drupal core inclusion. They are both using package_manager an API module, currently in the Automatic Updates project, to handle Composer operations.

Unless we explicitly do not support it users may assume that Automatic Updates and Project Browser are compatible with dependencies that are declared in the projects that installed in non-Composer ways(just copied into the file system).

These projects not known to Composer:

  1. Will all have info.yml files that have a core requirement in core_version_requirement
  2. May have dependencies on other drupal project in their info.yml file
  3. May have a composer.json with dependency on drupal/core
  4. May have a composer.json with dependencies on other drupal/* projects
  5. May have a composer.json with dependencies on vendor dependencies

package_manager uses the Composer Stager library to run the Composer operations in a staged version of the site

Possible problems that could happen when running Composer operations in the staged site with example project_a if it was not installed via Composer when

  1. install exact same project project_a via Composer, is installed in different directory
  2. install exact same project project_a via Composer, overwrites the existing project_a
  3. install new project project_a, but is actually other_org/project_a, is installed in different directory
  4. install new project project_a, but is actually other_org/project_a, overwrites the existing project_a
  5. install new project_b that has dependency on project_a but is actually, other_org/project_a installs project_a in different directory
  6. install new project_b that has dependency on project_a but is actually, other_org/project_a overwrites existing project_a
  7. install new project_b that has a version specific dependency on project_a, version conflicts, installs project_a in different directory
  8. install new project_b that has a version specific dependency on project_a, version conflicts, overwrites existing project_a
  9. update project_b which has new dependency on project_a, installs project_a in different directory
  10. update project_b which has new dependency on project_a, overwrites existing project_a
  11. Update drupal core, new version conflicts with core_version_requirement in project_a
  12. Update project_b, project_a has info.yml dependencies on project_b, version conflicts

Probably many more problems, these took 10 minutes to think up

Proposed resolution

  1. Prevent composer operations that will result in duplicate Drupal extensions. This has been implemented now in `package_manger` in contrib #3305568: Create a validator that detects duplicate info.yml files in the stage on apply →
  2. Do not allow any newly installed Composer packages to overwrite existing folders, see contrib #3305564: Create a validator to stop newly installed packages from overwriting existing directories on apply →

This 2 validations should stop the problem 1 to 10 described above.

Problem 11 & 12 are existing problems with using Composer and that fact that we declare dependencies in info.yml. You would run into this problem currently if you have any projects not installed via Composer

Remaining tasks

🌱 Plan
Status

Needs review

Version

11.0 🔥

Component

composer

Created by

🇺🇸United States tedbow Ithaca, NY, USA

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.

  • Comment 2 days ago →
    🇳🇿New Zealand quietone

    There hasn't been disagreement with the proposed resolution, only clarification. So, maybe there is agreement on the proposed resolution?

    If there is agreement, what are the next steps? Does this require documentation, and, if so, where?

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024