>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3337987. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <h2>Transcript</h2> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Tim from the DA, kicking things off</td> </tr> <tr> <td>kreynen</td> <td>I&rsquo;m here. Kevin Reynen - University of Colorado</td> </tr> <tr> <td>ccjjmartin</td> <td>:wave: Chris Martin, Engineer at Four Kitchens, I am looking to learn more about the initiative and see if there are places I can contribute.&nbsp;(edited)</td> </tr> <tr> <td>sonfd</td> <td>Eric from Redfin Solutions</td> </tr> <tr> <td>heatherwoz</td> <td>Heather from Four Kitchens. Also looking to learn more about the initiative and starting to think about how we can convert the distro our company uses to start sites to a recipe-based format.</td> </tr> <tr> <td>emofsnead</td> <td>Hobbiest who is building an auto-deployable base site generation with local-host Gitops for middle schoolers and wanted to listen in .</td> </tr> <tr> <td>alexpott</td> <td>:wave: Alex , core committer and recently mostly not doing recipes recipe initiative lead&nbsp; - still catching up with the recent work others have been doing.&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Bob here from St Charles IL, Chicago area</td> </tr> <tr> <td>navneet0693</td> <td>Navneet here, maintainer of Open Social &mdash; learning more and catching up on things.</td> </tr> <tr> <td>thejimbirch</td> <td>Jim from Kanopi here as always to try to help!</td> </tr> <tr> <td>bircher</td> <td>Fabian, not much bandwidth for coding at the moment but happy to review</td> </tr> <tr> <td>Noel Rivas</td> <td>:wave:&nbsp; Noel, from Matrushka, trying to wrap my head around recipes, their current state and their future</td> </tr> <tr> <td>briangilbert (realityloop) (he/him)</td> <td>Brian from Australia :wave: maintainer of Foundry</td> </tr> <tr> <td>hestenet (he/him)</td> <td>:clock9: Time is fake, but nevertheless, we're having a meeting! :joy:This meeting:&#10148; Is for distribution developers, initiative contributors, the Drupal Association and anyone interested in the initiative.&#10148; Usually happens every other Tuesday at 1600 UTC.&#10148; Is done over chat.&#10148; Happens in threads, which you can follow to be notified of new replies even if you don&rsquo;t comment in the thread. You may also join the meeting later and participate asynchronously!&#10148; Has a public agenda anyone can add to.&#10148; *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a &#128100; emoji. To take a comment or thread off the record, start with a &#128683; emoji.ping: @mixologic @Kingdutch @bircher @briangilbert (realityloop) (he/him) @navneet0693 @Tiago Barreiro de Siqueira @Mohammed Razem @finn @dww @Aaron McHale @alexpott @kreynen @thejimbirch @dbosen @smccabe @thenchev @bsnodgrass (he/him) @shawndearmond @nerdstein @konfuzed @dimkritsotakis @Rajab Natshah @sean.e.dietrich @UjjwalAhluwalia @joegraduate @m.stenta @leslieg @jpoesen @guptahemant @penyaskito @Marios Anagnostopoulos @rakeshjames @Lisa Ridley @sonfd (go to the meta issue to add or remove yourself from the list: <span class="drupalorg-gitlab-issue-link drupalorg-gitlab-link-wrapper"><a href="https://git.drupalcode.org/project/infrastructure/-/work_items/3269687" class="drupalorg-gitlab-link">https://git.drupalcode.org/project/infrastructure/-/work_items/3269687</a></span>)</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2> <table> <tr> <td>ccjjmartin</td> <td>I am looking to learn more about the process of rebuilding a profile (distribution) using recipes.&nbsp; Looks like you just created #4 which should address this.</td> </tr> <tr> <td>ccjjmartin</td> <td>Are recipes considered a "project" on drupal.org or do they have their own place to live?</td> </tr> <tr> <td>ccjjmartin</td> <td>My understanding is that recipes are used for installing a set of modules and configuration and then then are not updated (at least from the recipe) going forward, should recipes be uninstalled or removed from the codebase after initial setup?Maybe a separate question but kind of a part 2 to that, if uninstalled do we have a log for knowing which recipes (are these versioned?) were installed on a site throughout history?</td> </tr> <tr> <td>ccjjmartin</td> <td>Any plans for theme level integration?</td> </tr> </table> <h2>2&#65039;&#8419; Who has been trying out the current recipe stuff? How's it going for you? What are the biggest barriers?</h2> <table> <tr> <td>sonfd</td> <td>We&rsquo;ve been using it, but so far with only fairly basic stuff. A couple things I&rsquo;d like to improve:1. Recipes are all or nothing.It would be nice to pull one config (or more) from a recipe if it&rsquo;s a dependency rather than requiring the whole recipe. For example, install a field from another recipe, only if a field with the same name doesn&rsquo;t already exist.2. If I include a recipe with composer, and the recipe requires modules or libraries, I must keep the recipe composer installed, or manually transfer dependencies into project&rsquo;s composer.json.It would be nice if long term dependencies, e.g. modules, libraries, themes, got automatically moved to the project&rsquo;s composer.json.3. More config actions.Planning an MR to add a simple_config_append option, for example.</td> </tr> <tr> <td>heatherwoz</td> <td>#2 seems pretty important. that's one of the drawbacks of using distributions, if it becomes unsupported and you need to break the dependency. I don't think an old or unsupported recipe would create the same problems, but I could imagine site owners wanting to clean up the cruft after a recipe is installed and no longer needed</td> </tr> <tr> <td>emofsnead</td> <td>@sonfd&nbsp; Have you done your exploring in a container environment locally with a GitOps workflow to the host at all?</td> </tr> <tr> <td>emofsnead</td> <td>@sonfd&nbsp; And have you done any scaffolding or overrides at all?</td> </tr> <tr> <td>sonfd</td> <td>@emofsnead - Sorry, I don&rsquo;t know what you&rsquo;re asking</td> </tr> <tr> <td>emofsnead</td> <td>@sonfd&nbsp; Just some understanding of the test situation you have been trying for context</td> </tr> <tr> <td>emofsnead</td> <td>@sonfd&nbsp; The scaffolding specific question is because some hosts offer templates of Drupal with a local (e.g. Lando) and do it between the coordinated container systems with a scaffolding.&nbsp; So in my auto-build work I either need to do some overrides to the scaffolding or tweak select files between environments to avoid update overwrites.</td> </tr> <tr> <td>sonfd</td> <td>Ok. I don&rsquo;t really understand where you&rsquo;re going, but I&rsquo;ll try to give some more context.We have some private composer packages. For example, we have a composer package for a recipe. This recipe has a dependency on the context module because it provides a context. The composer.json looks something like this:json<br> {<br> "name": "my_stuff/my_component",<br> "type": "drupal-recipe",<br> "license": "GPL-2.0-or-later",<br> "description": "Provide some stuff.",<br> "require": {<br> "drupal/context": "^5.0"<br> }<br> }I require the recipe with composer, e.g. composer require my_stuff/my_component, then I apply the recipe, e.g. php core/scripts/drupal recipe /path/to/recipe/my_componentBut now the recipe is applied so I no longer need it in my codebase. But I can&rsquo;t remove it with composer because I&rsquo;ll also lose drupal/context because it was installed as a dependency of my recipe.Currently, I have two options:Carry the recipe around with my project forever even though it&rsquo;s already been used up.Manually composer require all dependencies at the project level then composer remove my package: composer remove my_stuff/my_comment</td> </tr> <tr> <td>sonfd</td> <td>This issue is noted in the Implementation Tasks section of the Recipe doc (it&rsquo;s the fourth item).</td> </tr> <tr> <td>sonfd</td> <td>Also noted as the last item in Phase 2 of the roadmap</td> </tr> <tr> <td>emofsnead</td> <td>@sonfd&nbsp; Got it!&nbsp; So you are just applying the composer require ...recipe say on a branch of your site you pulled local, run it, and them stage/test and release it to the host?</td> </tr> <tr> <td>sonfd</td> <td>Yes, I am working locally and then deploying configuration</td> </tr> <tr> <td>sonfd</td> <td>e.g. with git and drush deploy</td> </tr> <tr> <td>emofsnead</td> <td>Understand.&nbsp; My only issue with the scaffolding part of the question is that some container hosts are doing some file updates across the local-host that you need to deal with.&nbsp; But again, that may be an issue with the host and not an issue for this initiative.</td> </tr> <tr> <td>sonfd</td> <td>Which scaffolding question? (I have never understood what you&rsquo;ve meant when you&rsquo;ve said that in this thread. Sorry I&rsquo;m not seeing a connection. :disappointed: Are you talking about like composer require on my mac and then the files getting synced into a docker container that serves my local site?)(For additional context, I&rsquo;m working locally with ddev)&nbsp;(edited)</td> </tr> <tr> <td>Noel Rivas</td> <td>I&rsquo;m in the process of rewriting a distribution. The goals of the rewrite is to improve developer experience and make maintenance easier.As part of this process, I&rsquo;m interested in using recipes as part of the solution. The less code is left to be maintained in the finished sites, the better.I attempted to write and run a couple of recipes. I found two challenges:Figuring out the actual steps to writing and applying a recipe was confusing and I may have gotten it all wrongAfter writing a couple of recipes, trying to apply them resulted in errors (exceptions from somewhere in Core, IIRC?) so I paused testing. Got stuck but I&rsquo;m looking forward to wrapping my head around the current state of recipes.&nbsp;(edited)</td> </tr> <tr> <td>emofsnead</td> <td>An example might help.&nbsp; Imagine that a recipe says it wants to write something to the local settings php file to call some yaml settings file doing something else.&nbsp; Well that works fine in round one.&nbsp; But if you need to refresh the local-host connection, and the host uses a scaffolding install, the local settings php file can be overwritten and anything you did via the recipe to modify it is reset.&nbsp; You can do a scaffolding overwrite in your composer.json or you can set up a second level of settings.xxx.php being called at the end of your settings.php file which won't be overwritten.&nbsp; I do the later but document the option in my design logic so far.</td> </tr> <tr> <td>sonfd</td> <td>Oh! I understand now - thanks! :) I think that&rsquo;s maybe outside the scope of a recipe, but I could definitely be wrong!</td> </tr> </table> <h2>3&#65039;&#8419; Anyone want to put a stake in the ground about any contribution goals you'd like to achieve?</h2> <table> </table> <h2>4&#65039;&#8419; What do people need to know who want to convert distros to recipes? Should we start a docs page?</h2> <table> <tr> <td>heatherwoz</td> <td>I'm still reading up and learning about the state of this initiative. It's probably there if I read more closely, but can someone give me a quick summary - is there support for recipes now in Drupal 9.4 or 9.5? Does it require D10 or any patching?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Right now because the initiative is still in development you need to apply a patch, which is described here: <a href="https://www.drupal.org/project/distributions_recipes">https://www.drupal.org/project/distributions_recipes</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>Some examples: <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md#an-example-drupal-recipe">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md#an-example-drupal-recipe</a></td> </tr> <tr> <td>alexpott</td> <td>We really need to fix the issue that came out of Prague</td> </tr> <tr> <td>alexpott</td> <td>Because anyone who starts now will get frustrated when we change how recipes interact with each other</td> </tr> <tr> <td>kreynen</td> <td>We&rsquo;ve been experimenting with an Install Profile + Recipes, but we were really pushing the &ldquo;factory reset&rdquo; as a benefit of this approach.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@alexpott What issue are you referring to?</td> </tr> <tr> <td>bircher</td> <td>I think how recipes depend on each other</td> </tr> <tr> <td>Kingdutch</td> <td>I think from my p.o.v. our current distribution is quite configurable (borrowed from Thunder) which makes the install a bit of a &ldquo;pick your own adventure&rdquo;That&rsquo;s definitely something I&rsquo;d want to retain when migrating to recipes (i.e. an installing user can choose which recipes to enable/disable at install time). But maybe that&rsquo;s already there?</td> </tr> <tr> <td>kreynen</td> <td>@Kingdutch I believe everything is still CLI</td> </tr> <tr> <td>Kingdutch</td> <td>@kreynen that&rsquo;s fine, that&rsquo;s our primary interface for automation anyway. We currently use the fact that installer forms can be controlled through Drush arguments to get our flexibility</td> </tr> </table> <h2>5&#65039;&#8419; What kind of project should be use to store recipes on Drupal.org?</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Right now, I believe the answer is the 'General' project content type when adding a new project.(cc @alexpott for other guidance, perhaps)</td> </tr> <tr> <td>alexpott</td> <td>We&rsquo;re going to need our own project type. These are very distinct from modules / libraries etc</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah, eventually we will</td> </tr> <tr> <td>hestenet (he/him)</td> <td>But folks have been using generals for the early attempts, right?</td> </tr> <tr> <td>alexpott</td> <td>Seems fine to me&hellip; like there&rsquo;s no harm AFAICS</td> </tr> <tr> <td>hestenet (he/him)</td> <td>'k 'k</td> </tr> <tr> <td>emofsnead</td> <td>Wouldn't most recipes be built as combinations of modules?&nbsp; Seems like putting it in Modules but then having an indicator like 'dependencies' that pointed to the combination available as a recipe would make it easier for people to find in a single search.</td> </tr> <tr> <td>heatherwoz</td> <td>Recipes seems like its own thing to me</td> </tr> <tr> <td>alexpott</td> <td>The recipes themselves are not modules though.</td> </tr> <tr> <td>heatherwoz</td> <td>What does it take to get a new project type established?</td> </tr> <tr> <td>alexpott</td> <td>(not going to repeat the same mistake as profiles/distributions - which are both collections of config and modules themselves)</td> </tr> <tr> <td>hestenet (he/him)</td> <td>@heatherwoz Something we on the DA side need to prioritize. We have an issue for it, but it's been lower on the list.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Especially since this initiative is still in relatively early stages, want to make sure we understand any special requirements for the project type.</td> </tr> <tr> <td>alexpott</td> <td>We need to finish the API plumbing and what recipes look like. Then we can work on the d.o plumbing. We&rsquo;re not that far off but there are 2 issues to fix.1&#65039;&#8419; Default content2&#65039;&#8419; Determining how a recipe says if this does not exist get it from this recipe.</td> </tr> <tr> <td>emofsnead</td> <td>Seems like most training type materials are about modules and cause new users to look there in a search for what they want to 'do'.&nbsp; So if a recipe is a combination that allows you to 'do' much more, there should be a relationship to the modules searching at a minimum even if not completely folded in.</td> </tr> <tr> <td>alexpott</td> <td>&hellip; maybe project browser to the rescue &#128578;</td> </tr> <tr> <td>emofsnead</td> <td>Project browser is a good idea.&nbsp; And the GitPod opportunity for a one hour hands on that they are using is excellent.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I am wondering if project browser has an issue for incorporating other projects&hellip;</td> </tr> <tr> <td>thejimbirch</td> <td>Mentioned in this issue.&nbsp; Recipes could be a replacement for Project Browser's Use Case:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-4"><a href="https://www.drupal.org/project/project_browser/issues/3246006" title="Status: Postponed">#3246006: Define filter for "Use Case"</a></span>#comment-14799087</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>That was pretty early on, I don&rsquo;t think it&rsquo;s been discussed recently. The general consensus was to include other types of projects at some point. I can ask at our next async meeting to see where it best fits&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Recent focus for project browser has been getting categories settled and prioritizing usability improvements.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>This is an open issue for this initiative to make it ready for Project Browser <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/distributions_recipes/issues/3317618" title="Status: Closed (duplicate)">#3317618: Create ProjectBrowserSource plugin</a></span></td> </tr> <tr> <td>G&aacute;bor Hojtsy (he/him)</td> <td>Yeah project browser must support recipes when/as they become available &#128578;</td> </tr> </table> <h2>6&#65039;&#8419; Question: If it is correct recipes are used for installing a set of modules and configuration and then then are not updated (at least from the recipe) going forward, should recipes be uninstalled or removed from the codebase after initial setup?</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Raised by @ccjjmartin</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Follow up question: if uninstalled do we have a log for knowing which recipes (are these versioned?) were installed on a site throughout history?</td> </tr> <tr> <td>alexpott</td> <td>There&rsquo;s a lot about this in the docs already. the tldr; is that recipes are to be treated as ephemeral and stateless.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Note that most of the docs are in-repo at this point: <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md</a></td> </tr> <tr> <td>ccjjmartin</td> <td>Thank you</td> </tr> <tr> <td>emofsnead</td> <td>Once you address the 'content' question remaining in Phase 1 I am not sure how removing a recipe after initial set up would be logical.&nbsp; Seems like some could be but not all?</td> </tr> <tr> <td>alexpott</td> <td>The recipe is just a set of instructions to do things. There is no dependency on anything in the recipe.</td> </tr> <tr> <td>emofsnead</td> <td>I am still wondering even now about the boundary elements of menus/taxonomy/blocks which are in the database and handled by structure_sync to put into yml for config export/import to be handled.</td> </tr> <tr> <td>alexpott</td> <td>Demo content will be marked as such and can be removed regardless of whether you have the recipe around on not.</td> </tr> <tr> <td>emofsnead</td> <td>But Demo content is different than those structure_sync config items that are stored in the database</td> </tr> <tr> <td>alexpott</td> <td>once the configuration is created it is not relevant that it came from a recipe. It&rsquo;s now the site&rsquo;s configuration. This is actually the same for modules FWIW.</td> </tr> <tr> <td>Kingdutch</td> <td>I think the way I view this is that we (recipe authors/distribution maintainers) will have to make decisions on what is &ldquo;just default config&rdquo; versus &ldquo;config we own&rdquo;. The former would go in a recipe, the latter would still go in a module.The biggest improvement over how we do things now is that we can get rid of some of our modules that are basically just thin shells around contrib to change default distribution.We (Open Social) haven&rsquo;t discussed yet but I could see centralizing some &ldquo;owned config&rdquo; updates to a single or handful of modules since I expect with recipes to have fewer of such config items</td> </tr> <tr> <td>emofsnead</td> <td>@Kingdutch&nbsp; I hear you.&nbsp; That said, I don't know why something like the issue structure_sync handles isn't more elegantly folded into core.&nbsp; The workflow the way it is now for config management is a little nuts.</td> </tr> <tr> <td>Noel Rivas</td> <td>Wouldn&rsquo;t a module with zero runtime code, used as a dev dependency (so it&rsquo;s used at build time but never deployed in production), be functionally equivalent to a recipe?That is, assuming I&rsquo;m correct and the configuration provided by modules remains in the site even if they are uninstalled, unless the module explicitly removes or reverts it.</td> </tr> </table> <h2>7&#65039;&#8419; Another question: Any plans for theme level integration?</h2> <table> <tr> <td>hestenet (he/him)</td> <td>from: @ccjjmartin</td> </tr> <tr> <td>emofsnead</td> <td>I would think the theme level would be the most straight forward; just a custom theme under a base theme and the CSS and JS, and maybe TWIG overrides.&nbsp; The fact I understand Olivero isn't offering a sub-theming might be a side issues but I don't think that is necessarily a recipe specific issue.</td> </tr> <tr> <td>ccjjmartin</td> <td>With this question, I was thinking that twig templates could in theory live in a recipe then be copied from the recipe into the theme but then the question of "what theme" to copy it to would be involved.&nbsp; This would likely be related to the config that a recipe installs, new node type, then a new node template to go along with it.</td> </tr> <tr> <td>emofsnead</td> <td>Yeah, with the goal of being able to use on an existing site, you almost would have allow a recipe to detect the existing base theme and then offer a user interaction choice on using their current base theme, installing a new base theme and the recipe's subtheme, or do none of the theming part of the recipe at all.</td> </tr> <tr> <td>ccjjmartin</td> <td>This idea would tie a recipe to a specific theme or a recipe would have to list the themes that it supports and offer alternative templates copied around to installed (supported themes).&nbsp; I like the idea of a ready to use recipe for our distribution (theme and all).</td> </tr> <tr> <td>ccjjmartin</td> <td>On a smaller level, having something like paragraph types in a recipe would mean we could install the configuration related to a component ... and with the twig file, it could be themed upon install.&nbsp; For a distribution it seems like it would be ok to get opinionated on how the template file looks / what theme is supported.</td> </tr> <tr> <td>emofsnead</td> <td>For an initial install that is most straight forward and likely a key priority for simplicity.&nbsp; It is just the case of applying a recipe over top of existing that you probably need to be clear on where it will work with what base themes and then either detect or prompt at install for a user choice.</td> </tr> <tr> <td>thejimbirch</td> <td>Since a recipe is meant to be installed and then disappear, twig templates/theming would have to be provided by a module or theme.</td> </tr> <tr> <td>emofsnead</td> <td>This is sort of going to get into the question of the recipe authors requirements versus the initiative.&nbsp; I love the idea of having component selection options and with the most popular themes there are lots of active development to select from.</td> </tr> <tr> <td>emofsnead</td> <td>Got you on the install and disappear.&nbsp; But seems like the initiative then needs to be clear on the expectation it has for theme developer or module driven theme generators as part of the end goals.</td> </tr> <tr> <td>thejimbirch</td> <td>There is a lot of documentation in the repository that tries to provide that clarity.</td> </tr> <tr> <td>thejimbirch</td> <td><a href="https://git.drupalcode.org/project/distributions_recipes/-/tree/1.0.x">https://git.drupalcode.org/project/distributions_recipes/-/tree/1.0.x</a></td> </tr> <tr> <td>ccjjmartin</td> <td>Seems like it also comes back to is a recipe meant to be part of a distribution or replace distributions completely?</td> </tr> <tr> <td>thejimbirch</td> <td>replace</td> </tr> <tr> <td>ccjjmartin</td> <td>Replacing completely would make it abstract and thus we should be less opinionated about what goes in it.</td> </tr> <tr> <td>emofsnead</td> <td>Interesting dichotomy.&nbsp; A new user probably wants a recipe to be totally opinionated.&nbsp; The initiative less opinionated.&nbsp; Leaving the recipe developer as the solutions point.&nbsp; Seems logical.&nbsp;(edited)</td> </tr> <tr> <td>thejimbirch</td> <td>@ccjjmartin So far there has not been any effort into the theming layer.&nbsp; See Roadmap here: <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md#what-can-a-drupal-recipe-doI">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe.md#what-can-a-drupal-recipe-doI</a> have been envisioning a Recipe that installs the config for an Accordion paragraph, and would require a small module that contains a template and library.&nbsp; So a modular approach, muck like Emulsify and Compound.</td> </tr> <tr> <td>ccjjmartin</td> <td>Yeah, the Emulsify CLI could install a component and that could be the solution here for Emulsify based sites, so at least for our one single distribution (Sous) this problem can be solved, that leaves the larger community using different themes without a solution though.</td> </tr> <tr> <td>emofsnead</td> <td>As I said in my intro, I am working on an "auto-build" and the way I had been approaching it is to have a base CI/CD GitOps workflow as the core recipe.&nbsp; Then using a 'Make' script to select what I would term application area recipes that start to get increasingly opinionated.&nbsp; Those would then continue with scripted selection option for any theme choice base cases logical for the application area; from simply Olivero to more raw Bootstrap depending on where the person was on their level of understanding.</td> </tr> <tr> <td>Kingdutch</td> <td>I might be happy if recipes skip theming entirely. I think Drupal as a whole is moving to decoupled first more and more, which also makes themes a concern in a smaller number of cases (sort of)If I look at the current state of Open Social I wished we would&rsquo;ve moved more templating into modules rather than our theme. I&rsquo;ve come to grow the opinion that if something is structurally needed and newly introduced it should probably be in the module, then the theme can swap it out.If modules use standardised fields and themes know how to handle those then we may also get a greater interchangeability of themes.I&rsquo;ve run into quite some instances where I wanted &ldquo;business logic&rdquo; to decide how to display something and that business logic was too complex to dump into a theme and a better fit for a specialised module. However, because we had the actual structural visibility in a theme rather than the module actually having the changes take effect was relatively difficult.I can imagine that&rsquo;s an opinionated and controversial take of maybe a niche problem though :upside_down_face:</td> </tr> <tr> <td>thejimbirch</td> <td>I think it is that complexity, and the complexity of adding support for it in Drupal core is one of the reasons it is not on the roadmap.</td> </tr> <tr> <td>thejimbirch</td> <td>That being said, please post your thoughts:<span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-5"><a href="https://www.drupal.org/project/distributions_recipes/issues/3338019" title="Status: Closed (won't fix)">#3338019: [META] Should Recipes support theming?</a></span></td> </tr> <tr> <td>bircher</td> <td>I think the distinction is pretty clear: recipes can do what you can do in the UI. they can enable modules, create content, change config, enable themes and place blocks; they can not write modules or write to write templates to a theme folder.That said, recipes will also interact with composer, so downloading modules and anything else that can be a composer plugin can do are on the table for people to go nuts with</td> </tr> <tr> <td>bircher</td> <td>and of course we also have the config actions so your recipe can install a module that provides more actions and they can do all the code execution you can dream of.</td> </tr> <tr> <td>bircher</td> <td>down the line we can think of actions that have some user interaction, but I would keep that for a much later phase...</td> </tr> </table>