Support generating recipes

Created on 13 August 2022, almost 3 years ago
Updated 1 June 2023, about 2 years ago

Problem/Motivation

Currently we package configuration into modules. Per the Distributions and Recipes initiative β†’ , a new type of configuration provision is planned for Drupal core: recipes.

Proposed resolution

At the bundle level, allow selection of what type to create: modules or recipes.

Remaining tasks

User interface changes

API changes

Data model changes

✨ Feature request
Status

Active

Version

5.0

Component

Code

Created by

πŸ‡¨πŸ‡¦Canada nedjo

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡ΊπŸ‡ΈUnited States dave reid Nebraska USA
  • πŸ‡¨πŸ‡¦Canada mandclu

    I'd be interested in helping with this, but I'm not very familiar with how Features works under the hood. Could a maintainer point me in the right direction on where to start?

  • πŸ‡«πŸ‡·France andypost

    +1 to provide submodule to export as recipes

  • πŸ‡¨πŸ‡¦Canada mandclu

    Poking around in the code a little, it seems like the logical place to start would be in the addPackageFiles() method of the FeaturesManager class. I can see some potential approaches to making these changes:

    1. Overwrite the current method and assume that recipes are the way forward (probably only acceptable if this would be the basis of a new major version)
    2. Put code into a submodule that would decorate the current FeaturesManager class
    3. Add some kind of global configuration option to export recipes instead of standard modules
    4. Add a per-feature option to export a recipe instead of a standard module

    Do the maintainers (or anyone else) have a preference on the best path forward?

  • πŸ‡«πŸ‡·France andypost

    The module can just decorate FeaturesManager

  • πŸ‡ΊπŸ‡ΈUnited States thejimbirch Cape Cod, Massachusetts
  • πŸ‡¨πŸ‡¦Canada nedjo

    @mandclu If you happen to still be interested and available to start on this, I have some availability in the next few weeks to provide review and comments. While I'm not a current maintainer, I am a past one and have a good familiarity with the code.

    I'll start by commenting on some of what may be needed.

    At a high level, we have the advantage that we already model features fairly generically as a set of "packages", see the Package object and its properties. Currently, to generate feature modules, we parse these packages into modules. Our task here is to enable a second target format: recipes.

    Packages are associated with a Features bundle, see the relevant documentation β†’ and the associated FeaturesBundle config entity type.

    Each package can have a set of configuration items assigned to Package::config.

    In the current implementation, as you've noted, we parse the set of feature packages into extensions in FeaturesManager:: addPackageFiles(). We model most of the packages as modules, but optionally we special-case one package to be parsed as an install profile.

    Regarding your question about approaches:

    1. Overwrite the current method and assume that recipes are the way forward (probably only acceptable if this would be the basis of a new major version)
    2. Put code into a submodule that would decorate the current FeaturesManager class
    3. Add some kind of global configuration option to export recipes instead of standard modules
    4. Add a per-feature option to export a recipe instead of a standard module

    My personal take is: #3 is the way to go. Rationale:

    • Recipes appear to be here to stay. If feasible, our best approach is to introduce recipe support directly in Features rather than through a submodule.
    • The changes would be significant enough as to require a new minor release, but should be feasible within the existing major version. At first glance, it look like a lot of the work - possibly most - can be done within existing classes without deprecations. :: addPackageFiles(), for example, is a protected method that we're free to modify as needed.

    So, yes, concretely, we'd start by adding a new property to the FeaturesBundle object--perhaps ::targetRenderFormat or similar.. We'd add accompanying getter and setter methods to FeaturesBundleInterface. as is done in core per the relevant documentation β†’ . Values would be module and recipe. Perhaps we declare these in an Enum in FeaturesBundleInterface. We'd need:

    • At the UI level, a new radio element on the bundle configuration form to manage the new setting.
    • An update to set the value to modulein existing bundle configuration.

    From there, we can get a general sense of what's needed by looking look at our two different target formats - modules and recipes - and highlighting (a) how they differ and (b) how the parsing to modules is currently handled in Features (so we know where changes are needed). I'll give that some thought and follow up when I can with some further notes.

Production build 0.71.5 2024