>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3337988. --> 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>bsnodgrass (he/him)</td> <td>Bob Snodgrass from St Charles IL, Chicago area, trying to keep in the loop</td> </tr> <tr> <td>heatherwoz</td> <td>Heather Wozniak from Four Kitchens, also looking to keep in the loop and continue learning about recipes</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Tim from the DA, saying hi :wave::skin-tone-3:</td> </tr> <tr> <td>Noel Rivas</td> <td>Noel, from Matrushka :wave:</td> </tr> <tr> <td>Laura Johnson</td> <td>Laura Johnson from Four Kitchens, looking to learn more about recipes :wave:</td> </tr> <tr> <td>UjjwalAhluwalia</td> <td>ujjwalahluwalia from Adcetera - Houston, TX.Helping in contributing.</td> </tr> <tr> <td>alexpott</td> <td>Alex from London :wave:</td> </tr> <tr> <td>ronaldtebrake</td> <td>Ronald from Open Social :wave:</td> </tr> <tr> <td>penyaskito</td> <td>Christian L&oacute;pez, penyaskito, Sevilla Spain. Hi all!</td> </tr> <tr> <td>sonfd</td> <td>Eric from Redfin Solutions :wave:</td> </tr> <tr> <td>thejimbirch</td> <td>Jim from Kanopi Studios :wave:</td> </tr> <tr> <td>sashainparis</td> <td>Alexandre from France. Getting in for real.&nbsp;(edited)</td> </tr> <tr> <td>bircher</td> <td>Fabian, hello :wave:</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>nerdstein</td> <td>@thejimbirch says we got the session accepted. We need to plan for it</td> </tr> <tr> <td>Noel Rivas</td> <td>What can be accomplished with recipes that could not be accomplished with builder modules?I don&rsquo;t know if the concept of builder modules exists or if I&rsquo;m making it up. They would be modules that stick to these rules:They are regular Drupal modulesThey are required as dev dependenciesThey provide optional configurationThey provide commands that let developers do stuff with configuration and other aspects of the siteSo, a dev would composer require --dev drupal/some_builder_module&nbsp; to use it only in the local environment (but it would remain listed in composer so that can act as documentation of the build history).Am I getting recipes and their purpose totally wrong?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@hestenet (he/him) a topic to discuss the purpose of Recipes is to address the question @Noel Rivas asks would be good</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Sure, I put that question in a thread wholesale.&nbsp;(edited)</td> </tr> <tr> <td>penyaskito</td> <td>Here to catch up: is there an easy way to find all ActionMethods ? I recently came through a use case where having recipes ready would be really useful, and wondering if it was covered already</td> </tr> <tr> <td>penyaskito</td> <td>reframing it for the initiative benefit and not mine: when we need to provide docs for recipes authors, is there some way we can autogenerate that through static analysis? might be doable and resolve this kind of questions.&nbsp;(edited)</td> </tr> </table> <h2>2&#65039;&#8419; Looks like we have a new face or two! What are the best entry points for someone to learn about the initiative and maybe get started contributing?About the initiative: <a href="https://www.drupal.org/about/core/strategic-initiatives-distributions-and-recipesProject">https://www.drupal.org/about/core/strategic-initiatives-distributions-and-recipesProject</a> page: <a href="https://www.drupal.org/project/distributions_recipesReadme">https://www.drupal.org/project/distributions_recipesReadme</a> docs: <a href="https://git.drupalcode.org/project/distributions_recipesIssues:">https://git.drupalcode.org/project/distributions_recipesIssues:</a> <a href="https://www.drupal.org/project/issues/distributions_recipes?status=All&amp;categories=All">https://www.drupal.org/project/issues/distributions_recipes?status=All&amp;categories=All</a></h2> <table> <tr> <td>heatherwoz</td> <td>I'm browsing the list of open issues and I'm curious about this one <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/distributions_recipes/issues/3294391" title="Status: Closed (fixed)">#3294391: Standardize name of distribution initiative</a></span> Is it complicated to rename an issue tag? I would have thought it's like renaming a taxonomy term, but sounds like there is more to it than that.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I think it just needed the attention of someone with the correct permissions - cc @drumm</td> </tr> <tr> <td>timplunkett (he/him)</td> <td><a href="https://www.drupal.org/taxonomy/term/197489/edit">https://www.drupal.org/taxonomy/term/197489/edit</a> is the term edit page. In theory, changes there should affect all of the tags. But there might be some special d.o case to consider, so I won't change it just yet</td> </tr> <tr> <td>hestenet (he/him)</td> <td>^^ I am 90% sure that if you have the perms that's all we do - but drumm can confirm</td> </tr> <tr> <td>drumm</td> <td>Is this a basic rename, or has the new name already been used and it&rsquo;s actually &ldquo;merging&rdquo; two tags?&nbsp;(edited)</td> </tr> <tr> <td>drumm</td> <td>If there&rsquo;s nothing at the new name, go ahead and rename it. If there&rsquo;s a collision, need to update all the issues.</td> </tr> <tr> <td>timplunkett (he/him)</td> <td>No collision. Renamed, will comment on issue</td> </tr> <tr> <td>timplunkett (he/him)</td> <td>Thanks to tvn for this page I still have bookmarked 7 years later <a href="https://www.drupal.org/drupalorg/useful-links">https://www.drupal.org/drupalorg/useful-links</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>:clock9: It's that time again!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.</td> </tr> </table> <h2>3&#65039;&#8419; Planning for the Recipe's Distros session at DrupalCon Pittsburgh in June&nbsp;(edited)&nbsp;</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Per @nerdstein</td> </tr> <tr> <td>nerdstein</td> <td>i think we should first ask who is interested in participating in the session</td> </tr> <tr> <td>nerdstein</td> <td>and, start to prep a demo of the features and progress</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I am interested&hellip; being a non-developer participant, my interest is more along the lines of how site builders use recipes&nbsp;(edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Also for the general audience I think it&rsquo;s important to describe similarities and differences in the way things have been done in the past. Long time people will get that, and new people would hopefully get a better appreciation for the purpose and complexities of modernizing distributions and recipes.</td> </tr> <tr> <td>nerdstein</td> <td>Cool, who else may be interested?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@thejimbirch?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Standard Install profile would be a great demo and something that has had some work done on it.</td> </tr> <tr> <td>thejimbirch</td> <td>Hi, yes.&nbsp; Right now I have accepted the session, but haven't worked on anything yet.&nbsp; Alex's deck that he used in Prague is probably a great starting point for us, then we can expand to update roadmap and progress.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/distributions_recipes/issues/3301370" title="Status: Closed (duplicate)">#3301370: Model core's standard install profile as recipes</a></span></td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@thejimbirch what is your take on how far/close the standard profile might be as a recipe?</td> </tr> <tr> <td>thejimbirch</td> <td>I'd have to dig back into that issue.</td> </tr> <tr> <td>nerdstein</td> <td>@alexpott - do you have a link handy for your slides?</td> </tr> <tr> <td>alexpott</td> <td><a href="https://docs.google.com/presentation/d/1RGR3BmjeDil8SLjGfhJoIvRVk3kWRMgCnQXPDgjdhis/edit?usp=sharing">https://docs.google.com/presentation/d/1RGR3BmjeDil8SLjGfhJoIvRVk3kWRMgCnQXPDgjdhis/edit?usp=sharing</a></td> </tr> <tr> <td>alexpott</td> <td><a href="https://docs.google.com/presentation/d/1RGR3BmjeDil8SLjGfhJoIvRVk3kWRMgCnQXPDgjdhis/edit?usp=sharing">https://docs.google.com/presentation/d/1RGR3BmjeDil8SLjGfhJoIvRVk3kWRMgCnQXPDgjdhis/edit?usp=sharing</a></td> </tr> <tr> <td>thejimbirch</td> <td>Thanks @alexpott!</td> </tr> <tr> <td>nerdstein</td> <td>@thejimbirch @bsnodgrass (he/him) want to meet up and stub out an outline?</td> </tr> <tr> <td>nerdstein</td> <td>@hestenet (he/him) can you find if there is a desired template?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>My availability: <a href="https://calendly.com/hestenet/30min?back=1&amp;month=2023-02">https://calendly.com/hestenet/30min?back=1&amp;month=2023-02</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>I'm not sure if the speaking template is up yet.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>This page will have it 'soon' <a href="https://events.drupal.org/pittsburgh2023/speaker-resources">https://events.drupal.org/pittsburgh2023/speaker-resources</a></td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@hestenet (he/him) does that mean you want to join us as well?&nbsp; My schedule might just be the most flexible, To keep it easy, we could look at the same time as this slot. Tuesday Next week. @nerdstein @thejimbirch</td> </tr> <tr> <td>hestenet (he/him)</td> <td>I consider myself optional &#128578;</td> </tr> <tr> <td>hestenet (he/him)</td> <td>But if you feel you want me for any support stuff, feel free to add me in</td> </tr> <tr> <td>nerdstein</td> <td>@bsnodgrass (he/him) you know where to find me :) I&rsquo;m free Tuesday afternoon in certain slots</td> </tr> <tr> <td>thejimbirch</td> <td>I will dig into this on Friday.</td> </tr> <tr> <td>nerdstein</td> <td>@thejimbirch any update?</td> </tr> <tr> <td>thejimbirch</td> <td>Thanks for the ping.&nbsp; I set up a meeting for next Tuesday, February 28th at 4PM ET.<a href="https://calendar.google.com/calendar/event?action=TEMPLATE&amp;tmeid=NzBtaDJzNmExbXNhN2l1dGE3bHMwNWVhcTMgamltQGthbm9waS5jb20&amp;tmsrc=jim%40kanopi.com">https://calendar.google.com/calendar/event?action=TEMPLATE&amp;tmeid=NzBtaDJzNmExbXNhN2l1dGE3bHMwNWVhcTMgamltQGthbm9waS5jb20&amp;tmsrc=jim%40kanopi.com</a></td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I can make that, can you send me an invite @thejimbirch?</td> </tr> <tr> <td>thejimbirch</td> <td>Can you dm me your email again?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Just saw this.. not a secret @thejimbirch it&rsquo;s <a href="mailto:bsnodgrass@net2community.com">bsnodgrass@net2community.com</a></td> </tr> <tr> <td>thejimbirch</td> <td>Invited</td> </tr> </table> <h2>4&#65039;&#8419; What can be accomplished with recipes that could not be accomplished with builder modules?Per @Noel RivasI don&rsquo;t know if the concept of builder modules exists or if I&rsquo;m making it up. They would be modules that stick to these rules:They are regular Drupal modulesThey are required as dev dependenciesThey provide optional configurationThey provide commands that let developers do stuff with configuration and other aspects of the siteSo, a dev would composer require --dev drupal/some_builder_module&nbsp; to use it only in the local environment (but it would remain listed in composer so that can act as documentation of the build history).Am I getting recipes and their purpose totally wrong?</h2> <table> <tr> <td>heatherwoz</td> <td>I think recipes will be more flexible and specialized for this purpose, and also easier to maintain in the long term. Once installed/applied, you don't need to come back to it in any way.</td> </tr> <tr> <td>alexpott</td> <td>One point is that recipes are purposefully designed to not have code and not be that type of extension point. This decision is based on experience of features / install profiles / distributions&nbsp;(edited)</td> </tr> <tr> <td>Noel Rivas</td> <td>Yeah, the difference of having PHP code (because I&rsquo;d argue that yaml is still code) and not having it is big. There are pros and cons to it, IMO.I&rsquo;m currently using this concept of builder modules (if anyone knows if a similar concept has been used before, please tell me) recently and found the ability to write Drush commands very useful, but that may also have security or other implications.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Sorry.. wrote outside the thread first&hellip;I would summarize it as a tool for site builders to put features together without having to rely on complex distributions and the sustainability issues and deprecations that came with them.Also tooling you allow developers to better support their site builds.</td> </tr> <tr> <td>Noel Rivas</td> <td>Re flexibility, maybe it&rsquo;s because I don&rsquo;t understand recipes deeply (I did read the docs but not an expert) but I find the builder module approach more flexible.Ease of maintenance is another good point.</td> </tr> <tr> <td>alexpott</td> <td>Recipes will not take away your builder module approach. FWIW features is UI to create builder modules.</td> </tr> <tr> <td>Noel Rivas</td> <td>Yeah, why we want to get away from distros, I totally get. They are hard to maintain and can be restrictive.I find the mixin approach more desirable than the inheritance approach of distros, if the parallel can be done.</td> </tr> <tr> <td>Noel Rivas</td> <td>Oh, totally. I wouldn&rsquo;t propose adopting the builder module approach in recipes; I see how they are different things.I didn&rsquo;t think of that before (duh) but right, Features creates that kind of module.</td> </tr> <tr> <td>Noel Rivas</td> <td>My original question wasn&rsquo;t a rhetorical one: I asked it to really understand if the same things could be accomplished with a builder module but without implying that recipes would then be pointless or suggesting their expansion into builder modules.</td> </tr> <tr> <td>Laura Johnson</td> <td>Yes I was wondering how we would include default content as part of a recipe. I guess a builder module could include default content, and that could be part of a recipe? Or do recipes have another way of including default content?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@Laura Johnson I think there is an existing issue for that. <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/distributions_recipes/issues/3292287" title="Status: Closed (fixed)">#3292287: Extend recipe runner to create content provided in the recipe's /content folder</a></span>&nbsp;(edited)</td> </tr> <tr> <td>Laura Johnson</td> <td>Ah, nice, thanks @bsnodgrass (he/him)</td> </tr> <tr> <td>alexpott</td> <td>Very similar things can be done by a module.with config in its config/install and config/optional directory. Modules can&rsquo;t leverage the config actions API yet - but there is no reason they couldn&rsquo;t.</td> </tr> <tr> <td>Laura Johnson</td> <td>Right, so they could if this happens (the proposed solution makes use of config actions API, correct?): <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/2094481" title="Status: Closed (fixed)">#2094481: Support default content entities</a></span></td> </tr> <tr> <td>alexpott</td> <td>@Laura Johnson we&rsquo;ve not really decided what the solution looks like. I think ideally we could lift and shift the default_content module into core. And start from there.</td> </tr> <tr> <td>Laura Johnson</td> <td>Seems like a good solution to me... I've used default_content for that on multiple projects. I've been wondering if there's a more widely used method.</td> </tr> <tr> <td>Noel Rivas</td> <td>Thanks everyone; this has been very informative.My recap of this thread so far:A builder module could indeed do most of the things recipes can do.Config actions are not available for modules but could be in the future.This concept of &ldquo;builder modules&rdquo; is basically what Features produces.Recipes have their place precisely because they aren&rsquo;t modules; they don&rsquo;t have PHP code and don&rsquo;t need to be maintainedThe method for creating default content from recipes is a pending decision; lifting the default_content module into core is one option being considered.</td> </tr> <tr> <td>sashainparis</td> <td>I did use it recently to build product oriented sites factory with plugins approach to override and secure default configuration delivery in the long run life cycle. Available to talk about it if you want to.</td> </tr> <tr> <td>Noel Rivas</td> <td>@sashainparis you mean the builder module approach? Sure, would love to hear about your experience. Did you run into any issues?</td> </tr> <tr> <td>bircher</td> <td>in this regard I think it is worth mentioning that we want to shift from an imperative php to a declarative yml. So profiles in the future are not php code and like modules but more like recipes are envisioned now (or one could say a profile is a collection of recipes that work well together, and a distribution is a profile with modules that provide additional upgrade paths)</td> </tr> <tr> <td>bircher</td> <td>I don't know if it belongs to this thread, but it made me think of the fact that we may want to distinguish between different capabilities of the recipe: Describe what some config should partially look like. (say a role with this id and name exists, but without caring about all the permissions, or another part can say a role with this id has permission x.) And on the other hand describe what to do to a certain configuration (say add a permission to that role).</td> </tr> <tr> <td>bircher</td> <td>the "partially describe" I mean similar to how config_ignore can ignore only parts of the config or config_split can patch another part of the config. (full disclosure, I maintain both of these modules)</td> </tr> <tr> <td>Laura Johnson</td> <td>That would be great.</td> </tr> </table> <h2>5&#65039;&#8419; Question about ActionMethods</h2> <table> <tr> <td>bsnodgrass (he/him)</td> <td>penyaskito&nbsp; [11:33 AM]Here to catch up: is there an easy way to find all ActionMethods ? I recently came through a use case where having recipes ready would be really useful, and wondering if it was covered alreadypenyaskito&nbsp; [11:34 AM]reframing it for the initiative benefit and not mine: when we need to provide docs for recipes authors, is there some way we can autogenerate that through static analysis? might be doable and resolve this kind of questions. (edited)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@penyaskito do any of these issues help?<a href="https://www.drupal.org/project/issues/distributions_recipes?text=Action+Methods&amp;status=All">https://www.drupal.org/project/issues/distributions_recipes?text=Action+Methods&amp;status=All</a></td> </tr> <tr> <td>penyaskito</td> <td>It helps as it has a similar issue that mine, so that makes me think my need could be solved with recipes.But: my idea was more along that I know that there is an action for grantPermission, so I can use it. But how can I discover all the others? Are we expecting people to grep ActionMethod on core? Or expend contributors time on writing docs? Or is something that we could automate?</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I certainly think it would be possible, I&rsquo;m not the right person to ask&hellip; (reminds me of ECA which supposedly can use all the actions in Drupal IDK though)</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@alexpott??</td> </tr> <tr> <td>penyaskito</td> <td>There are lots of uses cases when we don't want to provide config, but alter/amend existing ones. I can think e.g. existing grantPermissions / add block display to an existing view / add this block to a layout builder section</td> </tr> <tr> <td>penyaskito</td> <td>I would expect ActionMethods to be everywhere, which will be an indicator of this initiative success, but a burden to document.</td> </tr> <tr> <td>bircher</td> <td>they are all plugins, or rather: there is a plugin deriver that creates one for every method. If it would add additional context in the discovery, the manager could be used to document them</td> </tr> <tr> <td>eclipsegc</td> <td>hold on, what? There&rsquo;s a plugin deriver that generates based upon methods in a class?</td> </tr> <tr> <td>eclipsegc</td> <td>please explain further?</td> </tr> <tr> <td>penyaskito</td> <td>I think he is referring to <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/10.0.x/core/lib/Drupal[…]/Action/Plugin/ConfigAction/Deriver/EntityMethodDeriver.phpThat">https://git.drupalcode.org/project/distributions_recipes/-/blob/10.0.x/core/lib/Drupal[…]/Action/Plugin/ConfigAction/Deriver/EntityMethodDeriver.phpThat</a> looks pretty cool</td> </tr> <tr> <td>penyaskito</td> <td>and definitely answers my question</td> </tr> <tr> <td>eclipsegc</td> <td>looking</td> </tr> <tr> <td>eclipsegc</td> <td>and thx</td> </tr> <tr> <td>penyaskito</td> <td>I can do:$ ddev drush php-eval 'print_r(array_keys(\Drupal::service("plugin.manager.config_action")-&gt;getDefinitions()));'<br> Array<br> (<br> [0] =&gt; entity_create:ensure_exists<br> [1] =&gt; entity_create:create<br> [2] =&gt; simple_config_update<br> [3] =&gt; entity_method:filter.format:setFilterConfig<br> [4] =&gt; entity_method:filter.format:setFilterConfigs<br> [5] =&gt; entity_method:user.role:grantPermission<br> [6] =&gt; entity_method:user.role:grantPermissions<br> )</td> </tr> <tr> <td>eclipsegc</td> <td>Yeah, the method attributes bit is throwing me for a loop, had to look that up</td> </tr> <tr> <td>eclipsegc</td> <td>I guess this is the PHP 8.1 annotations replacement?</td> </tr> <tr> <td>eclipsegc</td> <td>That makes me less wary.</td> </tr> <tr> <td>bircher</td> <td>php 8.0 and yes attributes are going to replace doctrine annotations. since this is D10 only and D10 is php 8.1 why not start with attributes...</td> </tr> <tr> <td>eclipsegc</td> <td>absolutely</td> </tr> <tr> <td>eclipsegc</td> <td>8.1 attributes is ++</td> </tr> <tr> <td>bircher</td> <td>yes in 8.1 you can nest them...</td> </tr> <tr> <td>eclipsegc</td> <td>we do that with Annotations in D8, so that&rsquo;s good cause feature parity</td> </tr> <tr> <td>bircher</td> <td>yea but in D8 it is a dumping ground for all sorts of additional things.. that won't work with defined class properties... this is yet to be found out</td> </tr> <tr> <td>alexpott</td> <td>yet to be found outWell - it is discussed at length in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3252386" title="Status: Closed (fixed)">#3252386: Use PHP attributes instead of doctrine annotations</a></span></td> </tr> <tr> <td>eclipsegc</td> <td>Pretty sure I commented on this ticket</td> </tr> <tr> <td>eclipsegc</td> <td>apparently I didn&rsquo;t</td> </tr> <tr> <td>alexpott</td> <td>The attribute issue I really like&hellip; <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3311365" title="Status: Closed (fixed)">#3311365: Use PHP attributes for route discovery</a></span></td> </tr> <tr> <td>bircher</td> <td>@alexpott yes I was just looking for this issue</td> </tr> <tr> <td>bircher</td> <td>the solution for it is what needs to be found</td> </tr> </table>