Display module dependencies on project pages

Moving to the right queue where this could happen.

I updated the issue summary with things mentioned in the duplicate #1299240: Expose the dependencies on the project page

http://drupal-association.ideascale.com/

Integrate Module Dependencies Visibility in a Project (48 votes)

Project Dependency already provides a function to determine the dependencies so I do not see that there is anything additional required by this project. Displaying the dependencies is up to the webmasters. So I am going to close this issue.

While not taking a position one way or another, I would like to point out the dependencies are not constant across releases so the thought of one block with the dependencies for a project is not possible. The dependencies would need to be for a particular release.

...I still think that this is perfectly valid. We can display dependencies for the latest recommended branches ("Recommended releases" in the download section), then fall back to "Other releases" if no recommended ones exist and finally fallback to dev versions if none of the previously mentioned categories exist.

...adding most of the things mentioned in the issue summary and comments from the duplicate issue #1299240

I spent some time considering how to do this. Project Dependency has stored some of the information in database tables and provides functions to retrieve the information. However, there is no outward facing part of Project Dependency. It has been regarded as a utility and produces no content. Furthermore, as previously mentioned, the dependencies are for a release and not for a project.

I considered several ways and places in the project pages to display this information. Since this module is not called for most of the project pages there are only limited places where this is possible and some people may say is impossible. I finally arrived at creating two blocks for the release page. For one thing, the release page has room unlike other possibilities that are already rather cluttered with information. The two blocks are all the components (modules) included in the release and all the dependencies of the release. The dependencies are divided into required and optional dependencies. I think the optional dependencies are test dependencies? I started to create a block with all the projects that require the project but since it is a release that has dependencies I am holding off on this to avoid slowing down progress on the other two blocks.

It is difficult to apply this patch and see the results so I am attaching a screenshot of what this looks like for an Ubercart release.

Some other notes. If no components are found then it indicates that the database table containing the information was not populated during the actual release. This could be due to problems that existed when the release occurred (such as perhaps during the transition of drupal.org from Drupal 6 to Drupal 7). I check to see if there are no components found and I try to populate the database table. This provides a user with a way to update the database table when the information is missing. I have not tested this because I have not found a release to test it.

Another note is that there are some releases that have problems. These may not have been apparent but they will be very visible once these blocks are displayed. An example I found on my development site is Ubercart 6.x-2.12 (although Ubercart 6.x-2.9 works fine). I think this is positive since it will help us flush out more problems but it could also result in a rash of issues filed. If the table displaying the components is empty I should probably add a note to file issues under Project Dependency.

The third note is this patch only provides the blocks. The drupal.org webmasters will need to enable the blocks for the blocks to actually appear.

Updated patch to avoid displaying blocks in local tasks (tabs) of the release node. Also, changed the components block to return a renderable array instead of HTML.

It's really nice to see this issue getting some love.

I cannot do an actual review and I am no UX expert, but I'd rather the dependencies info to be displayed in the main project page (someplace near the "Downloads" section) instead of being "buried" in the releases page. It's where this information is currently being inconsistently displayed to end users. If we place it anywhere else, then project maintainers are likely to keep their "custom" sections with this info and that would defeat one of the main purposes of this feature proposal. Also, most users download their version from the main project page and if there are additional modules they need to install, then the best place to communicate that IMO is there as well.

I think that the best thing to do would be to revamp the "Downloads" section altogether by placing each branch in some sort of tab/accordion/what-have-you and show their respective dependencies there too.

If you want it on the main project page, then this issue should be posted elsewhere. Project Dependency is not called on the main project page so there is no way to do this.

Dependencies are not always the same for every release. So they are for a release and not for a project.

I didn't mean a single dependencies block for the whole "Downloads" section. I meant something like so:

Downloads
 _______ _______ _______
|  6.x  |  7.x  |  8.x  |
|       |_______|_______|______________________________________________________
|                                                                              |
| Branch Information                                                           |
|   Maintenance status: Minimally maintained                                   |
|    Development status: Looking for co-maintainers                            |
|    Reported installs: 7 sites currently report using this module.            |
|    View usage statistics.                                                    |
|    Downloads: 514                                                            |
|                                                                              |
| Other releases                                                               |
|   Version            Download                          Date            Links |
|   6.x-1.0            gz (21.39 KB) | zip (27.7 KB)     2013-May-26     Notes |
|                                                                              |
| Development releases                                                         |
|   Version            Download                          Date            Links |
|   6.x-1.x-dev        gz (21.4 KB) | zip (27.71 KB)     2013-Oct-01     Notes |
|                                                                              |
| Depedencies                                                                  |
|   module_x   >   6.x-1.2                                                     |
|   module_y   >=  6.x-1.x-dev                                                 |
|   module_z       6.x-2.x                                                     |
|                                                                              |
| View all 6.x releases                                                        |
|______________________________________________________________________________|

View all releases

And when switching to the 7.x branch tab:

Downloads
 _______ _______ _______
|  6.x  |  7.x  |  8.x  |
|_______|       |_______|______________________________________________________
|                                                                              |
| Branch Information                                                           |
|   Maintenance status: Actively maintained                                    |
|    Development status: Under active development                              |
|    Reported installs: 1007 sites currently report using this module.         |
|    View usage statistics.                                                    |
|    Downloads: 514000                                                         |
|                                                                              |
| Other releases                                                               |
|   Version            Download                          Date            Links |
|   7.x-1.0-alpha1     gz (17.7 KB) | zip (20.74 KB)     2012-Nov-11     Notes |
|                                                                              |
| Development releases                                                         |
|   Version            Download                          Date            Links |
|   7.x-1.x-dev        gz (17.43 KB) | zip (20.72 KB)    2013-Nov-28     Notes |
|                                                                              |
| Depedencies                                                                  |
|   module_x   >   7.x-1.0                                                     |
|   module_z       7.x-1.x                                                     |
|                                                                              |
| View all 7.x releases                                                        |
|______________________________________________________________________________|

View all releases

This way, each branch can display its own dependencies in its own tab independently from the other branches/tabs.

As you can see this also opens the possibility of having per-branch maintainer lists and maintenance/development status as well as usage stats and what-have-you.

We can have the currently supported/active branch tab active by default. So, for now it would be the 7.x tab and once Drupal 8 is out, that would be the 8.x tab.

@klonos I dont think you fully understand its not just each major release. But also each point release 6.5, 6.6. Which can have different projects contained in the release. Therefor your screen won't work. I honestly do not think we need this on the project page, the project page is already very busy, we don't need it to be more busy.

Oh yeah I do. It's simply not reflected in the mochups. For multiple versions in each branch, the tabs would become:

 ___________ ___________ ___________ ___________ _______
|  6.x-3.x  |  6.x-5.x  |  7.x-1.x  |  7.x-3.x  |  8.x  |
|___________|           |___________|___________|_______|_______________________

Normally we don't have more than a couple of active releases per branch, but even so the tabs labels would be so small that we can accommodate quite a few of them.

I agree that the project page is kinda busy, but keeping each branch/version in a separate tab helps in hiding part of this noise and to concentrate on a single target...

Consider this: for each D7 setup users come searching for a single branch of the module in question: any 7.x release. What we currently do is throw a bunch of releases (6.x , 8.x) in their face while the majority only need info and download links for a single one. Now, if we kept each branch/version in a tab, we'd be helping people filter down to what they need to see while at the same time having the rest of the info available there only a click away for the ones looking for previous/next versions.

Also, as I already mention, having a single maintenance/development status block for all releases is not precise nor correct. A branch might be actively maintained while others not and we don't have a way to clearly communicate that.

klonos: 7.x-1.0-alpha1 can depend on 5 other modules, and 7.x-1.0-alpha2 can add 2 new dependencies. Then 7.x-1.0-beta1 adds a few more...

Impressive as this ASCII art is (!), I don't think the UI would work at all. :)

That said, the release nodes themselves are also busy/cluttered. I'm not totally sure this stuff should be displayed by default on all release nodes. Maybe a separate tab on release nodes for this?

I updated the patch so that there is now a Details tab on the release pages. This shows the components in the body of the page and the dependencies in the sidebar. Unlike the blocks the Details tab will appear if this change is applied to drupal.org so I will need the approval of the drupal.org webmasters in order to proceed. I also have attached a screenshot of the page.

I see no reason to restrict the possibilities for the drupal.org webmasters so I left the possibility for displaying the blocks on the main release page. Personally I prefer the blocks because at the moment I do not think the release page is very crowded and it gives the drupal.org webmasters more flexibility and control while keeping Project Dependency from directly providing content.

That looks really useful as I can download all dependencies in a bunch.

I checked the patch to see if it still looks okay. I noticed the details tab was showing up on nodes other than release nodes so I tweaked the patch to restrict it to just the release nodes. There still is the option to use a tab or blocks to display the information. Also, whether the information being displayed looks okay.

trobey, Is there a dev site you are working on where we could see this patch in action?

@tvn: I just had it locally but it did not take long to apply the patch to my dev site and enable the block. Here are two links:

https://pd-drupal.redesign.devdrupal.org/node/2361321

https://pd-drupal.redesign.devdrupal.org/node/2361321/details

I am thinking this would help with debugging issues like #2388213: Payment 8.x-2.x dependencies not checked out. It would save having to get my development site updated and my running a drush script to show the same information. In addition it will allow others to do the debugging. A drawback is people may start filing issues on Project Dependency because they now can see when it is wrong.

As I noted above I prefer to display this information in two blocks in the sidebar directly on the release page but feel free to suggest what you think would work best.

Since I am about to make a beta release I want to get close to a stable API. So I am going to add the blocks since they are by default disabled. Even if the blocks are not enabled for general users they may be useful for particular roles for debugging. By making these available it also removes Project Dependency from any deployment decisions since decisions involving multiple groups tend to get bogged down. This issue still is open for the code for the tab approach.

1. +++ b/project_dependency.module
   @@ -10,6 +10,190 @@ define('PROJECT_DEPENDENCY_DEPENDENCY_REQUIRED', 0);
   +  $content .= '<p>' . t('The selected release is the release that will be used for automated testing.  Optional projects are used for testing.') . '</p>';
   

   double space before "Optional"

2. +++ b/project_dependency.module
   @@ -10,6 +10,190 @@ define('PROJECT_DEPENDENCY_DEPENDENCY_REQUIRED', 0);
   +      'empty' => 'No optional projects',
   

   Not t'ified

I fixed these two items and committed them to the dev branch. I also am attaching an updated patch with just the code for adding a tab.

I see that at least some of this code is already on the D.o dev sites.
What do we need to test this further?

I'm also looking at #1323826: Make it easier to identify and discover ecosystem modules but would prefer to also see this issue in action...

The query is okay, although a new index on either (title) or even (release_nid,title) would be good.

mysql> explain SELECT components.name AS name, components.title AS title FROM project_dependency_component components WHERE (components.release_nid = 1541320) ORDER BY components.title ASC;
+------+-------------+------------+------+---------------+-------------+---------+-------+------+-----------------------------+
| id   | select_type | table      | type | possible_keys | key         | key_len | ref   | rows | Extra                       |
+------+-------------+------------+------+---------------+-------------+---------+-------+------+-----------------------------+
|    1 | SIMPLE      | components | ref  | release_nid   | release_nid | 4       | const |   36 | Using where; Using filesort |
+------+-------------+------------+------+---------------+-------------+---------+-------+------+-----------------------------+
1 row in set (0.00 sec)

mysql> SHOW KEYS from project_dependency_component;
+------------------------------+------------+-------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table                        | Non_unique | Key_name    | Seq_in_index | Column_name  | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+------------------------------+------------+-------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| project_dependency_component |          0 | PRIMARY     |            1 | component_id | A         |      158877 |     NULL | NULL   |      | BTREE      |         |               |
| project_dependency_component |          1 | release_nid |            1 | release_nid  | A         |      158877 |     NULL | NULL   |      | BTREE      |         |               |
| project_dependency_component |          1 | name        |            1 | name         | A         |       52959 |     NULL | NULL   |      | BTREE      |         |               |
+------------------------------+------------+-------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

I’d also like to see this formatted as a more-simple list like

• ctools 7.x-1.10
• sshkey 7.x-2.0
• …

I am confused. The query is on the release_nid column so I am not sure where adding an index for the title column helps? I do not have a problem with adding it but I just do not follow why.

The components and the dependencies are output as tables. I can output these as a list but is that for components, dependencies or both? Comment #27 is for components but the example in comment #28 is for dependencies so it is not clear. If I remove the table and use a list then the table header also is removed. Is it clear what is in the list without the header or do I need to add something in place of the header?

Adding an index on title will remove the Using filesort from the explain. A covering index on (release_nid,title) is the best possible index for this particular query, since both the WHERE and ORDER BY clauses are covered.

This came up at the DrupalCon sprints, realityloop is looking at this and also showing things which depend on a project, which is a fun UX problem. See also #1323826: Make it easier to identify and discover ecosystem modules.

I would like to see at least the release’s dependencies shown to everyone on the project page. The table adds a lot of visual weight and not much readability. I think a simple list would be self-explanatory enough - people can click through and discover projects, version numbers are hard to confuse for anything else.

Offhand, I’m not sure if components is something that would be useful to everyone or is more of a debugging tool. I’d keep it as-is, a separate issue for making that available to all can be filed if needed.

Attached is an example of how this might look, it makes for quite a long page with Views (the example used in the image), this is intended to be added to individual release pages.

I have another idea about how this could be displayed but it would be a big change to the module page and given dependencies are linked to releases here probably makes more sense for now anyway.

Given how long this list can be I wonder if using a table with a sticky header might be a good idea?

@tvn suggested these should be collapsable

@joelpittet suggested using fieldsets https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen...

The general approach looks okay. Kudos for understanding that dependencies are for a release not a project.

There are two types of dependencies: required and optional. Required dependencies are needed for the project to work. Optional dependencies are needed for automated testing. I think to display only required dependencies then the optional dependencies should be hidden. I may need to add classes to facilitate this.

Even if the immediate dependencies for a release are not changing the dependencies can change. This is because the immediate dependencies can resolve to a newer release of a project which has changed dependencies. Example: foo has a release that has a dependency on bar1. The most recent release of bar1 has a dependency on bar2. So the dependencies for the release of foo are bar1 and bar2. A new release of bar1 happens and it adds a dependency on bar3. Now, even though the release of foo has not changed, the dependencies have changed to bar1, bar2 and bar3. If a website has the old version of bar1 then the dependencies are different than for a website using the new version of bar1. So the dependencies of foo are not static. For the dependencies I am showing both the project and the release that would be selected by automated testing.

Some projects are used by a lot of other projects. Views, ctools, token, etc. For these projects it is going to be difficult to show all the projects that use them. Paging and filtering are probably going to be required. Currently I do not know of any easy way to generate the dependents. These can change with a new release of a project so they cannot just be stored to a table and retrieved.

I committed a change that adds the index and changes the listing to a simple unordered list. I probably should have done a patch but I was in the middle of some other things and committed it. The output looks something like the attached screenshot. I have not added a fieldset and this is only the dependencies. Any thoughts about how the dependents is going to be generated?

Do we have a dev site ready for this?

I updated the dev site @drumm pointed me to ... it's now on 7.x-2.0-beta1+2-dev

DEMO: https://dependencies-drupal.dev.devdrupal.org/project/hosting/releases/7...

Great .. this looks deploy worthy.

The only bike-shed thing I can think of the difference between the Components being a table and the Dependencies being a list.

I can change the components. The table shows the title and then the machine name. If we change from a table then the header row goes away. Is it obvious if I show the title followed by the machine name (perhaps with the machine name in parentheses)?

I deployed the work so far here.

This would be so great to have. And it seems it was very close to finished, what do we need to get this back on track? :)

Thanks catch, that makes sense.

Project dependency is no longer used on Drupal.org, its functionality was merged into project_composer, since the code was tightly-coupled.