Enabled modules as configuration [#1814336]

This is a feature request for the ability of exporting/importing and managing the list of enabled modules as a configuration.

Ideally we would be able to enable or disable any modules using configuration management. This would have to be aware of module dependencies and disable modules accordingly.

Comments

Comment #1

dragonwize CreditAttribution: dragonwize commented 16 October 2012 at 22:40

I have been on the fence about this functionality.

On one hand, which modules enabled are configuration and would be nice to have configuration manage it.

On the other hand, modules are easily environment dependent. We can use our tracking functionality is not as useful here as it is for other configurations. This is because we turn off many modules in dev that are enabled on live, analytics modules, caching modules, etc. Which means it would be really easy for these dev config to make it way to live.

My approach to this so far is that we have dependency and so if your configuration depends on a module, it will need to be enabled, either manually or automatically. This makes enabled modules not configuration but just a dependency. The issue with that approach is modules that do not have configuration to be dependent on fall into an edge case.

That brings me to thinking of how we really want to handle configuration management in D7. Unfortunately we can not do the really deep changes that the D8 CMI is doing so we do have some constraints preventing us from making the most optimal solution. I am sort of inclined to just say that we do the best we can while keeping something maintainable and understandable and know that there will always be somethings we have to handle in a different way.

Thoughts?

Comment #2

lucascaro CreditAttribution: lucascaro commented 18 October 2012 at 15:08

In our use case, we have several modules that don't have associated configuration or dependencies and IMO It would be nice to be able to keep track of enabled modules in code. I do see the problem with dev modules that shouldn't go to production environments though...

Is adding a setting for filtering development modules an option? I mean, just like admin_menu and its "Developer modules to keep enabled" setting, we could have a list of modules marked as "Environment dependent" or "Not trackable" so configuration ignores them and they don't get shipped to other environments.

Either that or the opposite, white-listing which modules we want to track, would be a step towards managing those modules that are configurations themselves.

Comment #3

dragonwize CreditAttribution: dragonwize commented 18 October 2012 at 23:40

The issue is that is not just a module that should be on in dev but not production but also the other way around. For example, in dev environments we do not run analytics for obvious reasons not to skew our data but we do turn them on in production. The same goes for config related to things like caching etc.

So we would need not only to know what modules to enable in dev and/or not enable in prod because they are dev but also the what module to still keep tracking on prod but not track it on dev. (complicated)