Distributions and Recipes initiative overview and roadmap

Fleshed out "Team and resources" section with @mixologic's general categories from the Slack thread about your 5 min talk @ DDD. Does it need to be more specific than that? Do we want sublists with specific users for each category?

• fixed Panopoly typo
• changed wording about switching profiles to be more accurate. Acquia recommended using https://www.drupal.org/project/profile_switcher as part of Lightning EoL process to convert sites to use the Standard install profile. It's not easy,
  but it can be done.

A promising initiative. Some background material and comments drawing on my experience in this area, including a number of modules I've written or contributed to, some little more than proofs-of-concept and others more fully developed.

Allowing multiple distributions to be used on the same project

It's a laudable aim. Over the years a lot of thought and work has gone into what might be required to make it happen. I summarized some of this in Tips for writing interoperable Drupal distributions. While the article's a decade old and applied to Drupal 7, most of the core challenges remain. See also an 8-part blog series on "Managing shared configuration", starting with part 1.

Many of the key challenges can be derived from just a couple of simple problem statements of what interoperable distributions would presumably need to do:

1. Add permissions to a common set of user roles.
2. Provide theme-associated configuration such as blocks.

Problem #1 would require:

• Agreed upon standard role names--by implication, a specification for interoperable features. An early attempt was the Kit specification. See also Harmonize app/distro/feature component names (roles, vocabularies, and so on).
• A way to provide shared configuration without creating conflicting dependencies. See Managing Shared Configuration Part 7: Core Configuration and the Configuration Share module.
• A way to alter existing configuration since permissions are saved to user roles and various distributions would need to add permissions to the same roles. See #2383439: User permission handling and Managing Shared Configuration Part 4: Configuration Alters Currently there are at least 4 different approaches in contrib. Interoperable distributions would need to converge on a single solution, ideally one in core; see #2960941: Provide an API for persistent configuration alters, including for extension-provided config.
• A way to update existing configuration, since the permissions required by a distribution could change over time. See Managing Shared Configuration Part 5: Updating from Extensions. Currently there are two main approaches: (1) Update Helper and (2) Config Distro + Configuration Synchronizer. Ideally, part of standardization would be choosing a single model since no given site owner wants multiple competing solutions to the same problems. See Configuration Management with Drupal Distributions.
• A way to retain site-specific customizations, such as an override to a given permission. See Managing Shared Configuration Part 3: Respecting Customizations.

Re problem #2, see Drupal distributions, blocks, and subthemes and the Skins module.

Crediting people who participated in the discussions so far outside of the issue, list from @alexpott.

Crediting continued.

Done crediting.

I missed DrupalCon this year so coming into this late. This is super exciting. It honestly sounds like the kind of problem we were trying to solve with Features (and Apps) back in the day (reusable pieces of functionality).

I agree with nedjo on many of the hard problems. There needs to be a well-defined way for a site to use a recipe and decide if it wants to get new updates to that recipe in the future, or if it wants to fork/override it.

One problem with Features was that they would get reverted, losing local changes, breaking sites, requiring a need for an override mechanism.

In D8/9/10 with core config management, a module can provide starting configuration, but once the module is installed, updates to that configuration are ignored unless they come in via update hooks by the module. And updating config in an update hook could have the same problems as Features losing local changes or breaking sites.

As a site builder, I'd want a way to browse recipes (Project Browser), select the ones I want, then either "lock" them or not if I want to receive updates and improvements. But that might conflict with how a developer (vs site builder) would want to control recipe versions via composer and semantic versioning. The idea of mixing recipes rather than being tied to a monolithic distribution would be great.

Hi There,

Just read the intro and it sounds like an excellent idea. Especially for use cases like universities sites, where you have multiple sites with similar code base and don't want a lot of maintenance burden.

The only piece missing here seems to be front-end components. For example, if I have a recipe with one or more React components it would be good to pull in front-end deps as well.

What everyone thinks about it? I am not digesting it well and bit confused about if Recipe is a "decoupled component or piece of functionality" or it's like the installer script?

Also, if I am reading correctly distributions are collection of recipes or something like traditionally how we have we install and then carry on from there?

Any light on above questions would be appreciated.

@amjad1233 Because the goals for this features have been discussed for 10+ years, the information about this is spread across many issues and channels.

https://www.drupal.org/about/core/strategic-initiatives-distributions-an... is the summary of what is and isn't in scope for this as well links to where the work is being done and how to get involved.

The easiest way to discuss how this impacts/relates to front end components would be to join https://www.drupal.org/project/infrastructure/issues/33013 or open an issue in https://www.drupal.org/project/distributions_recipes

Since you are also in higher ed, I've reached out to you directly as well. There are several people from higher ed involved, but we can always use more people/perspectives.

For example, if I have a recipe with one or more React components it would be good to pull in front-end deps as well.

I think #2873160: Implement core management of 3rd-party FE libraries is the relevant issue for that. That issue is independent from the Recipe initiative. If it ends up getting solved via Composer, then Recipes will be able to benefit from that. If instead of Composer, we decide to use npm or similar, then we might want to define how recipes can identify their npm dependencies (presumably via a package.json file). Per #2873160-111: Implement core management of 3rd-party FE libraries, I hope we can find a solution there that doesn't require Node.js on the server in order to be able to install recipes via Project Browser, but I don't know if we'll be able to.

Thanks @kreynen & @effulgentsia I really appreciate your input. The strategic initiatives page is a valuable resource. Also, the issue #2873160 seems like a place to start with and port over some knowledge to Recipes initiative. I found a link to next meetup and will try to attend it to discuss this further.

My main objective is to have one front-end component (not to confuse with React component but could be one) as example or at least tool set in the recipe framework's "core", to give other users a way to build up and share their library.

Especially, in education arena where re-usable components are very viable scenario. In a way keeping the philosophy of mix and match.

To give you a scenario,

In the most university websites, I find courses/programs listing and filtering view a common thing.

Imagine how good it would be to put that view as a backend and a barebone React component which someone can download via composer and override it with their own requirements. Like how we have at https://study.uq.edu.au/study-options/programs

In addition to that, they can add new functionalities and share it back to the community. It's same approach as Modules but again but this example, however config is not sort of "ejected" after initial installation, here if, I add a common type of filter, like text search, other people can easily receive through recipe updates for the view as well as the React component I shipped.

I mean just receiving update for views config does not make sense, because then I am going back and updating my front-end component to alight with the changes pushed. In which scenario, why don't I just use a module ? So I sort of don't have to comply with the updates...

Marking as "closed (outdated)" in favor of the strategic initiative documentation found here: https://www.drupal.org/about/core/strategic-initiatives-distributions-an...

Until the initiative has been completed, this issue should be kept open. The other closed (outdated) ideas issues are for abandoned ideas, not active ones.

Should the title include [META]?

Phase 1 has been completed and merged into Drupal core. Additional work continues in the initiative space to help move Starshot forward.

I think this can be considered fixed now that it is in core. Certainly there is no further work required in the ideas queue.

Amending attribution.