Contrib.social

Add support for recommends[] and fix install profile dependency special casing

Open on Drupal.org →
Created on 7 June 2010, about 15 years ago
Updated 9 November 2023, over 1 year ago

Problem/Motivation

Install profiles specify modules to install as dependencies[]. These are not enforced as hard dependencies though and can be disabled. ( #808162: update.php fails when optional modules disabled → for background). If a distribution wants to keep the install profile module around, tough luck. There's no mechanism right now to discern between "the install profile module is recommended" and "the install profile module is required to make the distribution work". This limits distrbutions as for the latter purpose another module needs to be maintained, confusing users and making the life of the distribution maintainer harder.

Proposed resolution

-Convert dependencies[] to hard requirements for install profiles.
-Removes all special casing that undoes it
-Ensure dependencies[] behaves the same for modules and install profiles
-Introduce support for recommends[]. This will install any module that is available in the modules system (just as dependencies[] does) but these modules can later be disabled/uninstalled. (Note: If a user git clones an install profile the dependencies will not be downloaded and this could lead to errors during install if dependencies were not downloaded. See comment #39)

Remaining tasks

-Re-roll patch in #26 replacing modules for recommends
-Add recommends[] support to module_enable()

User interface changes

-Add indicator in the UI to show that x module recommends y module.

Original report by catch

Install profiles specify modules to install alongside them as dependencies[], however they're generally not enforced as hard dependencies, see #808162: update.php fails when optional modules disabled → and linked issues for background.

To fix this, we need to

* ensure that install profile dependencies are shown on admin/modules (note: #293223: Roll back "Hide required core modules" → has been committed)
* update the core install profiles to always use hook_enable()
* document the API change for existing contrib profiles.

When the original patch went in, the idea was to use .info files to gather dependencies for Drupal.org packaging, however as far as I know this now uses .make files, so it shouldn't affect that at all, although it'd be good to have that confirmed, I've only half-followed the packaging work.

**Summary built from comments by catch in #37 and David_Rothstein in #39.

📌 Task
Status

Needs work

Version

11.0 🔥

Component
Install  →

Last updated 23 days ago

No maintainer
Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • API change

    Changes an existing API or subsystem. Not backportable to earlier major versions, unless absolutely required to fix a critical bug.

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 →
    🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

    The last comment was in early 2018, 6.5 years ago, in #85.

    The comment before that was in late 2015, 8 years ago, in #79.

    Since then, the world has changed quite a bit. The Drupal ecosystem is no longer figuring out how to adopt Composer. It has adopted Composer!

    Stopping to rely on Drupal's own *.info.yml files now seems more realistic: ✨ Replace .info.yml with composer.json for extensions Postponed .

    Which means that it's realistic to not add recommends[] to *.info.yml and instead rely on composer.json's existing suggest? 😊

  • Status changed to Postponed: needs info over 1 year ago
  • Comment over 1 year ago →
    🇬🇧United Kingdom catch

    I'm not sure there's anything really to do here now that #2952888: Allow install profiles to require modules → unless we wanted to implement composer.json suggests support in the UI somewhere? Moving to needs more info.

  • Status changed to Closed: works as designed about 1 month ago
  • Comment about 1 month ago →
    🇳🇿New Zealand quietone

    Since @wim leers comment 1 year and 6 months ago there hasn't been any comment supporting the proposal. Nor any to the idea in the last comment to "implement composer.json suggests support in the UI somewhere". Therefore, I am closing this issue.

    If there is something of interest here, such as the suggestion in #97, then either re-open the issue or open a new issue and reference this one. If the choice is to use this issue then add a comment and make sure to change the issue status to 'Active'.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024