Closed (works as designed)
Project:
Drupal core
Version:
11.x-dev
Component:
extension system
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
31 Jan 2016 at 18:16 UTC
Updated:
22 Nov 2025 at 03:24 UTC
Jump to comment: Most recent
Comments
Comment #2
David_Rothstein commentedPossibly related? (Not positive if it is.)
Comment #3
markhalliwellSeems like there's a few ideas floating around that hint at roughly the same "ideas". However, I'm not entirely sure, at this point, whether this is indeed a duplication.
The other issues seem to be more focused on the "suggest install" idea (like: "hey, you might like this module too"). This is about ensuring "peer dependencies" are also always installed, just after (not before like it currently is: a requirement).
I think, if anything, we need to have a serious discussion (plan) on how to now define "dependencies" as a concept in Drupal. Only having a single "dependencies" entry isn't enough and is the only way to correlate extensions (albeit, currently in a very inconsistent manner). Drupal has grown up.
Comment #5
colanIt wasn't immediately clear from the other issue if this is about depending on one of the modules in a provided list. In other words, if a module requires certain functionality provided by a bunch of modules, where any one will do, are we talking about setting something up so any one of the modules is required? Or, as Debian would put it,
For example, I'm thinking of module that needs a Services authentication plug-in where I want either Services API Key Authentication or Services API Keys Authentication. I can't make them both required as either one will do.
So either this issue:
Comment #20
nicxvan commentedWhy wouldn't we do this with hook requirements?
Is this just for convenience?
Comment #21
nicxvan commentedNot exactly sure which closed status is applicable.
If someone had a clearer requirements that isn't covered by install requirements feel free to reopen.