Contrib.social

[policy] Move composer/composer from a dev dependency to a production dependency

Open on Drupal.org →
Created on 15 October 2021, over 2 years ago
Updated 9 March 2023, over 1 year ago

Problem/Motivation

There are 2 reasons that Automatic Updates in core will require core to have a production dependency on the composer/composer package:

  1. For people on hosting accounts that disable shell_exec and friends ( #3218119: [policy, no patch] Do automatic updates need to be supported on hosting plans that disable "proc_open" and friends? → ), the only way to invoke composer commands is through the PHP API.
  2. The automatic updates module needs to inspect things from composer.json and composer.lock ( #3238647: Create an API for easily accessing relevant Composer information → ), and the composer/composer package provides the API to do that.

I'm opening this issue to get feedback on whether Drupal core having a production dependency on composer/composer is ok. If it's not, we'll need to figure out some alternative, though I'm not really sure what.

I'm filing this for Drupal 10, though if we get the module to beta in time for inclusion into 10.0, then if we also want to include it into 9.4, then the question applies for 9.4 as well. Meanwhile, if we don't get the module ready in time for 10.0, would we want to move composer/composer to a production dependency in 10.0 anyway, rather than having to make that change in a minor release (e.g., 10.1)?

For now, this is just a policy question. A patch to actually implement this change can happen in a followup.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Closed: won't fix

Version

10.0 ✨

Component
Composer  →

Last updated about 19 hours ago

No maintainer
Created by

🇺🇸United States effulgentsia

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

  • Needs release manager review

    It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

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 over 1 year ago →
    🇺🇸United States phenaproxima Massachusetts

    I think we should close this issue as outdated.

    We're already nearly done removing our runtime dependency on composer/composer and ripping out the ComposerUtility class which relies on it. So if composer/composer is moved into core's runtime dependencies, it won't be by Automatic Updates Initiative.

  • Status changed to Closed: won't fix over 1 year ago
  • Comment over 1 year ago →
    🇺🇸United States effulgentsia

    Agreed.

    There's still the question of #3218119: [policy, no patch] Do automatic updates need to be supported on hosting plans that disable "proc_open" and friends? → , but:

    1. We don't know in 2023 how big a percentage of sites actually have that limitation, and we shouldn't add support for it until we have evidence that it's a non-trivial amount.
    2. If we need to support Automatic Updates on sites that don't have proc_open enabled, there's other issues we'll need to solve too. It won't just be a matter of using Composer's PHP API and everything magically working.
    3. If we need to support Automatic Updates on sites that don't have proc_open enabled, we shouldn't necessarily have to make composer/composer a runtime requirement for everyone else. We'll need to come up with a solution that only brings it in for the few sites that need it.

    Therefore, closing this for now, and it can be re-opened if/when another need for it arises, whether that's Automatic Updates related or something else entirely.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024