UX: Indicate dependencies that are automatically enabled/disabled

[klonos]

When running bee en devel_generate, devel is also enabled because it is specified as a dependency for devel_generate 👍🏼 ...that's not being communicated to the user though:

bee en devel_generate

 [✔] The 'Devel Generate' module was enabled. 

I'd like this to be like so instead:

bee en devel_generate

 [i] The 'Devel' module will also be enabled, as it is required by the 'Devel Generate' module.
 [✔] The 'Devel' module was enabled.
 [✔] The 'Devel Generate' module was enabled.

...or:

bee en devel_generate

 [i] The 'Devel' module will also be enabled, as it is required by the 'Devel Generate' module.
 [i] The 'Devel' module is already enabled.
 [✔] The 'Devel Generate' module was enabled.

Similarly when disabling modules that are dependencies for other modules:

Current behaviour:

bee dis devel

 [✔] The 'Devel' module was disabled.

What I would like to see instead is something like this instead:

bee dis devel

 [i] The 'Devel Generate' module will also be disabled, as it depends on the 'Devel' module.
 [✔] The 'Devel Generate' module was disabled.
 [✔] The 'Devel' module was disabled.

In fact, "silently" enabling/disabling module dependencies may be seen as a bug. Drush prompts for this:

drush dis devel
The following projects will be disabled: devel_generate,devel.
    Do you want to disable the projects? (y/n): y

	Success: devel_generate,devel are disabled.

drush en devel_generate
The following projects will be enabled: devel, devel_generate.
    Do you want to enable the projects? (y/n): y

	Success: module devel enabled.


	Success: module devel_generate enabled.

[yorkshire-pudding]

@klonos - I'm not sure how we would do this given that all the dependency processing happens within core functions module_enable() and module_disable() which have no options to report on additional modules enabled or disabled.

For disabling, we'd somehow have to check whether a module was still required by another module or not before saying it was going to be disabled.

Do you have any ideas on how to do this?

[jenlampton]

Can we look at how drush handles this? Does it call module_enable() or do its own thing instead?

[elisseck]

Can we look at how drush handles this? Does it call module_enable() or do its own thing instead?

It looks like drush builds its own list unless i'm looking at the wrong spot: https://github.com/drush-ops/drush/blob/b27e30ebabc6a2c3ce56eaeaaa7fa67db7e9ee96/commands/core/drupal/environment_7.inc#L100

I think this feature is really important for practical usability and I'm happy (and have some time available) to work on the strategy we talked about in the dev meeting today which will be:

1. Copy what Backdrop core is doing for bee so we can get this feature in the short term (I don't think doing the calculation twice is really going to be much of a performance hit except in crazy edge cases).
2. Open an issue against core to move the "dependent" and "dependency" checks out side of module_enable() and module_disable() so contrib modules can have those bits available, and we can stop doing the calculation twice.

[yorkshire-pudding]

Discussion during the Dev meeting on 2024-09-26: https://www.youtube.com/live/uSG6jpHF8dk?si=pqKKtIKEyOhKUJSj&t=760 (I've added this link above)

Thank you @elisseck for raising this and for preparing a pull request. I've added an initial comment there but will give a more detailed review shortly.