Change record status: 
Introduced in branch: 
7.x, 8.0.x
Introduced in version: 


Dependencies are specified in the module .info file (Drupal 7) or .info.yml file (Drupal 8). For projects on it is recommended that dependencies now include a project name as follows.

Drupal 7:

dependencies[] = project:module (>=version)

Drupal 8:

  - project:module (>=version)

In this form the project name is recommended, the module name is required and the version requirement is optional. Since the project name is not required this is backward compatible with existing code. There is no effect on module installation or dependency calculation in Drupal core.


The dependencies were specified in the following form:

Drupal 7:

dependencies[] = module (>=version)

Drupal 8:

  - module (>= 1.x)

In this form the module name is required and the version requirement is optional.


A real example from Drupal 7 is the webform project containing the webform module. A webform_patched project was created that also contains a webform module. Specifying a dependency in the form

dependencies[] = webform (>= 7.x-3.20)

is ambiguous and results in problems. Specifying the dependency in the form

dependencies[] = webform_patched:webform (>= 7.x-3.20)
dependencies[] = drupal:system (>=7.40)

uses the project name which is unique so that the module is uniquely specified. Since project namespaces was added in Drupal 7.40 that also is added as a requirement. There are also numerous examples of modules that have been moved into and out of Drupal core and thus appear in both Drupal core and a contributed project. The php module is an example in Drupal 8 of a module that moved out of Drupal core into the php project.

Module developers
Updates Done (doc team, etc.)
Online documentation: 
Not done
Theming guide: 
Not done
Module developer documentation: 
Not done
Examples project: 
Not done
Coder Review: 
Not done
Coder Upgrade: 
Not done
Other updates done


kenorb’s picture

Raised new feature request for drush to support that syntax.

kenorb’s picture

Dave Reid’s picture

I reverted some of these changes, because in most cases in D7, adding the project to the dependency information when project name already matches the module name just ends up causing problems with anyone not using Drupal 7.40. That was not clear until I read the "Project dependency" section. I think it's safe to leave that syntax as more of a "special case" instead of the default for D7.

Senior Drupal Developer for Lullabot | | @davereid

Mixologic’s picture

Can you clarify what the problems were? The project/module data model is totally broken without it, and many things rely on this *not* being broken and ambiguous (namely the testing infrastructure and the composer façade).

I do not think that causing problems for the few site owners who do not wish to upgrade their core from pre 7.40 justifies discouraging this as a best practice.

As an aside, we were thinking of adding a warning to module pages that *didnt* do this as they were specifying ambiguous dependencies in order to encourage module maintainers to stop using the old method.

trobey’s picture

I thought we had the ability to specify versions including versions of Drupal core. If Drupal 7.40 is required is that not just specified by something like

dependencies[] = drupal (>=7.40)

If we cannot do this then I think there is a problem with the ability to specify version requirements since the version of Drupal core is probably the most important version of all.

There is a problem with version requirements because they are rarely used as I remember from spending a lot of time debugging project dependencies. This is because it is a pain to download multiple versions of dependencies to run tests to see which versions do not work. The result of this is that the only stable configuration is to keep all modules updated to the most recent version. We have an excellent system that prevents a Drupal 6 module from being installed on a Drupal 7 website and the resulting unpredictable behavior. But it would be obvious immediately if someone did manage to do this. Installing incompatible versions of Drupal 7 projects is usually possible because version requirements are not specified and it may not be obvious that there is a problem until real damage is done.

Many years ago I proposed that the testing infrastructure for allow manual testing against multiple versions of dependencies so that it is easier to determine the version requirements and that version requirements actually get used. has all the versions so it makes sense to use them for this type of testing. Until that is done the only choice we have is to keep everything at the most recent release.

Gaia Environmental Sciences

Mixologic’s picture

Sorry, I had to revert your revert, but I added additional instructions to hopefully prevent backwards compatibility issues. Im dealing with ambiguous namespace issues on a daily basis in both the composer facade as well as project dependency and testbots, and we want to prevent non-namespaced dependencies in info files. This isn't a special case, its more of an absolutely, do this, if you can at all help it and *only* leave it unnamespaced if there is an extremely compelling reason to, or if your module isnt hosted on