It's great to see active work in contrib to fill the gaps in D8 configuration management. Not surprisingly, there is a potential for overlap. This isn't necessarily a problem, but:
An example of potential incompatibilities is the normalization or stripping of config between its exported and installed states (see #2406037: Diffs - don't exclude dependencies). Currently, no two modules seems to approach this problem quite the same way:
What one module produces will be lost in another module or show up as false positives in diffs.
One solution would be to pull reusable routines into a module that other config modules could then depend on. However, none of the modules listed above is currently structured in a way that would facilitate this.
Relevant issues:
For Configuration Revert, given the aim of potentially merging into core in the 8.x cycle, introducing a contrib dependency would produce complications. Still, it's probably a question worth asking.
Comments
Comment #1
jhodgdonConfig Revert already has a reusable class/service that does the diffs and decides if two config items are different. The service is called
config_revert.config_diff
and the class is
Drupal\config_revert\ConfigDiffer
Let's discuss the specifics of what it should or should not be excluding on #2406037: Diffs - don't exclude dependencies and not here, since that is not the main point of this issue I think.
Anyway, I'd be happy to coordinate, in general. I think the ConfigDiffer is probably the main reusable part of the Config Revert module (do you know of more?). I'd be fine with this class/service moving into Core, or another **lightweight** module that the others could depend on.
But right now as Config Development is structured, on the project page it says "DO NOT USE THIS IN A PRODUCTION SITE". Until that philosophy is changed, I do not think that module is a good candidate for the base for the others. Config Revert is intended to be used in production, in the normal course of maintaining updates on a site, and being able to detect that there is new or updated configuration you might want to import after an update.
Comment #2
jhodgdonAnother note on Configuration Development is that, at least according to its project page, it is doing things ***at the beginning of every request ***. That is obviously not a module you'd want others to depend on!
Comment #3
nedjoGood points!
Also, Configuration Development is, explicitly, aimed at developers, so it's not an appropriate dependency for a module aimed as well at site builders and admins.
So probably the best course if anything is indeed a new "**lightweight** module that the others could depend on".
Comment #4
jhodgdonEither that or getting the common parts in Core. I think the Config Differ class/service from this module would be a good candidate for that, even if the rest doesn't get into Core in 8.0.x. Core could use it -- way better than the existing diff code in Core.
Comment #5
jhodgdonAt this point, this issue is not actionable, so setting to "needs more info" until it is.
Comment #6
jhodgdonNo further comments in 8 months... We can reopen this if there is something to do.
Comment #7
jhodgdonFYI I just opened #2599358: Split UI/Drush/reports into separate module at the request of Features/mpotter