Problem/Motivation

When looking at modules, one of the metrics to know about quality is how many depend on that module. Also this is a great way to discover modules that extend the functionality of that module. It would be really great if we could that dependency information on project pages.

There are multiple reasons i'm asking for this:

  1. An extra metric to see how well used a module is.
  2. Discovery of extensions for a module without the need of an explicit mention of 'ecosystem'.
  3. Create more parity with the general php ecosystem since packagist/github etc all show this metric.

The reason I ran into this was also because of the d10readiness initiative. We need to test projects that depend on core modules that are getting removed. To find good candidates for these tests this information would be VERY helpful.

Steps to reproduce

Eh.

Proposed resolution

I would propose something modeled after packagist:
packagist.org/packages/drupal/core-recommended/dependents

Remaining tasks

  1. Agree on solution
  2. Agree on interface
  3. Implement
  4. ...
  5. Profit

User interface changes

New link on the project pages to list dependends of that project.

API changes

None.

Data model changes

None hopfully, this information should already be available somewhere.

Comments

bbrala created an issue. See original summary.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (duplicate)

Duplicate of #760890: Display module dependencies on project pages.

catch’s picture

catch
he/him
Primary language English
commented
Status: Closed (duplicate) » Active

Looking at #760890: Display module dependencies on project pages more it mentions three things in the issue summary but only really does one, so it makes sense to have a separate issue.

catch’s picture

catch
he/him
Primary language English
commented
Title: Show "dependends" for modules » Show "dependants" for modules
Issue summary: View changes
drumm’s picture

drumm
he/him
Location NY, US
commented

Releases have different dependencies for different versions. The project page would have to pick a single release, or show copies for each release under the releases table. Anything that’s actually release-specific should land on release pages first, then consider the project page later.

We have had dependencies on release pages before. It was removed because it was impacting performance. If we do anything, it should only show immediate dependents, not walk the whole dependency tree.

Release and project pages already show a lot of information. Their primary audience should be people using the project. Should this really be on the existing pages, or a link to see it on a separate page?

We need to test projects that depend on core modules that are getting removed.

This would be a more-complex report. There are project and release pages for core, the straightforward implementation of this would show everything that depends on core, without going into components. Drupal Association engineering staff can always run these reports for core maintainers.

catch’s picture

catch
he/him
Primary language English
commented

Should this really be on the existing pages, or a link to see it on a separate page?

IMO the most useful thing would be a tab showing the latest release in each branch + the dependencies.

This would be a more-complex report. There are project and release pages for core, the straightforward implementation of this would show everything that depends on core, without going into components.

The specific use-case here is trying to find projects that depend on https://www.drupal.org/project/hal which has already been removed from core in 10.x (but is still in 9.x).

kopeboy’s picture

kopeboy
Primary language Italian
Location Milan
commented

I second catch, regardeless of the version, knowing which other modules are related is useful, both dependants and required (on which the module depends).