Alternatives (alternative module dependencies)

"Alternatives" allows other modules to declare alternatives to their module dependencies in their *.info file.

Example use case / Usage instructions

The most relevant use case would be for alternative autoloaders like X Autoload vs Registry Autoload.

name = My module
description = Does something.
core = 7.x

dependencies[] = xautoload

; The following will take effect if you enable "alternatives" module.
alternatives[xautoload][] = registry_autoload

; Configuration for registry_autoload if it is used.
; This has nothing to do with "alternatives" module, it just a reminder.
registry_autoload[] = PSR-4

As long as "alternatives" module is disabled, the alternatives[..] setting in a module's *.info file will do nothing, and only the default dependency ("xautoload" in the example) will be accepted.

If both alternatives module and registry_autoload module are enabled, then the dependencies on xautoload will be replaced with a dependency on registry_autoload.

Difference to "Any" module

The "Alternatives" module was inspired from a feature request on "Any" module: #2956108: Ideas to simplify "any" module..

With "Alternatives", you only need to add the entry in the *.info file. You don't need hook_requirements() or anything else. You also don't need to require "alternatives".

"Alternatives" always prioritizes the original dependency over its alternatives.
Most users will probably end up installing the original dependency, because this is what they see by default.

"Alternatives" is written from scratch and shares quite little with "Any", but it would probably not exist without it. All ideas came while looking at "any" module. So, thanks to @markcarver for "Any"!

Admin UI / Escaping dependency traps

There is a form at 'admin/modules/alternatives', where you can mark specific modules as "to be ignored".

This way, you can escape a situation where some modules cannot be disabled anymore.