- Issue created by @jcandan
- πΊπΈUnited States trackleft2 Tucson, AZ πΊπΈ
Since "Recipes" is essentially just a list of commands to apply to a site (similar to how an administrator can use drush to change configuration), I don't see how this module wouldn't be compatible with that.
How specifically are you wondering if this module integrates with Recipes?
- πΊπΈUnited States trackleft2 Tucson, AZ πΊπΈ
I wonder if we should address the recipe question on the project page.
- πΊπΈUnited States trackleft2 Tucson, AZ πΊπΈ
One thing that I am not clear on is:
If a recipe alters a single line within config
Does that make the entire configuration overridden or can I merge upstream changes around the recipe provided config. - π¨π¦Canada nedjo
Just popping in as a former Configuration Synchronizer maintainer with a few quick thoughts in case they're useful!
Thanks @trackleft2 for those great notes and issue links. I'll add a few thoughts on how this all might look in practice.
First, recipes can be reapplied. They can also have different settings in terms of what happens on reapplication, see the developer docs on comparing configuration using strict. So, to some extent, recipes try to do what Configuration Synchronizer does--reapply config. What Configuration Synchronizer does but recipes don't as yet support is three-way merging into the active configuration storage. This difference probably means that, for the time being, there's still a valid use case for using both recipes and Configuration Synchronizer on a given site.
How?
A first step is probably to look at the distinct ways that configuration is provided. Recipes support several methods for adding or altering configuration:
- Provide configuration directly in the recipe from a config folder. See developer documentation..
- Alter configuration through config actions, see developer documentation..
- Import config from an installed extension, see developer documentation, using one of two strategies:
- Cherry-pick only specific config items provided by the extension, or.
- Import the full set of config provided by the extension (using a wildcard).
How do these different methods break down between Configuration Synchronizer and recipes?
As things stand, any updates for the first two - provide configuration directly and alter config through config actions - have to be handled by recipes and not by Configuration Synchronizer. That's because, at present, Configuration Synchronizer has no access to recipes.
Could that limitation be removed? I just opened β¨ Add support for recipe-provided config Active in case anyone wants to explore that question.
That leaves us with configuration that's provided by modules or themes but installed via recipes. Here, things can get a bit tricky, partly because our current approach includes an implicit assumption that all config provided by an extension is actually installed. With the advent of cherry-picking recipes, that assumption no longer holds.
I've opened #518274: Add more Dublin Core meta tags β as a place to look at what changes might be needed in our current snapshotting of config from extensions--as well as what would be needed to snapshot config that comes directly from recipes.
But, again, I'm just popping in, I've been out of the loop for some time, and I have no plans to do a lot of further commenting, much less to contribute code! I'm so happy to see this whole module set so capably and responsibly maintained--it's what we hope for when we move on, right? Please take these notes in the spirit they're intended, as quick reflections to draw on only if and to the extent that they seem helpful.
Thanks!