Find a new home and service for module_enable(), module_disable(), module_set_weight(), etc [#1893690]

Follow-up to:
#1331486: Move module_invoke_*() and friends to an Extensions class
#1893680: Rename 'module_handler' service and ModuleHandler classes

Problem

module_enable(), module_disable(), module_set_weight(), etc have been left out from the ModuleHandler service, since it deals with "enabled" (active) modules only.

Goal

Move those extension management functions into a proper service.

Details

These functions are responsible for changing which extensions are participating in the application.
DrupalKernel contains some similar functionality already, but moving these functions directly onto DrupalKernel would result in infinite recursion.

Comments

Comment #1

catch

he/him

English

CreditAttribution: catch commented 21 January 2013 at 11:15

There's a circular dependency here in that these functions depend on drupal_*_schema_*() which in turn depend on hook_schema()/hook_uninstall() etc. which in turn depends on the hook system. We may need a service which only deals with $module.install hooks (which have a different execution path anyway) to break that dependency.

drupal_*_schema_*() also depends on the db_*() schema manipulation wrappers. I've opened an issue to discuss removing those at #1894396: Mark db_*() wrappers in database.inc as @deprecated for 9.x although an injected database object would be enough in this issue.