Is this compatible with Recipes?

Created on 10 February 2025, 2 months ago

Problem/Motivation

Drupal relatively recently released the Recipes β†’ feature. Does this module play well with them?

Proposed resolution

If not, we should create a feature enhancement issue to ensure compatibility.

If it does, maintainers should document this capability on the project page.

πŸ’¬ Support request
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States jcandan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • 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 πŸ‡ΊπŸ‡Έ
  • πŸ‡ΊπŸ‡Έ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:

    1. Provide configuration directly in the recipe from a config folder. See developer documentation..
    2. Alter configuration through config actions, see developer documentation..
    3. Import config from an installed extension, see developer documentation, using one of two strategies:
      1. Cherry-pick only specific config items provided by the extension, or.
      2. 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!

Production build 0.71.5 2024