Talking Drupal #536 - Composer Patches 2.0

John (00:06)
This is Talking Drupal, a weekly chat about web design and development from a group of people with one thing in common. We love Drupal. This is episode 536, Composer Patches 2.0.

Andy Giles (00:11)
you

John (00:19)
On today's show, we're talking about patching Drupal, Composer, and Composer patches 2.0 with our guest, Cameron Eagans. We'll also cover configuration development as our module of the week. Welcome to Talking Drupal. Our guest today is Cameron Eagans.

Cameron is an engineering leader and full stack software engineer based in Boise, Idaho, with over 15 years of experience building and leading large scale software projects across a variety of industries. He's worked with organizations ranging from NASA and NOAA to NBC Universal and the ACLU. And he maintains several wide used open source projects in PHP and Drupal ecosystem.

He also maintains several widely used open source projects in the PHP and Drupal ecosystem that have been downloaded nearly 90 million, million with an ⁓ times to date. Cameron, welcome to the show and thanks for joining us.

Andy Giles (00:59)
You

Cameron Eagans (01:13)
Thanks for having me.

John (01:14)
I will note as the scheduler for this show, this show way overdue, because I think everybody and their mother uses composer patches. So we're going to talk about that in a minute, but I apologize for it taking us so long to get you on to talk with you. All right. I am John Picozzi, Solutions Architect at ePam. And today my co-hosts are joining us for the second week. Andy Giles, co-founder at DripYard.

Andy Giles (01:40)
What's

up? you

John (01:43)
And last but certainly not least, Nick Laflin, founder at Enlighten Development.

Nic (01:47)
Happy to be here looking forward to hearing about Compose Practice 2.0.

John (01:52)
And now

to talk about our module of the week. Let's turn it over to Martin Anderson-Klutz, a principal solutions engineer at Acquia and a maintainer of a number of Drupal modules and recipes of his own. Martin, what do you have for us this week?

Andy Giles (01:58)
you

Martin (02:05)
Thanks, John. Do you maintain modules that provide configuration files? There's a module that can help manage them. It's called Configuration Development, and it was created in April of 2024 by CHX, though recent releases are by Joaquin. Now it has an 8.x-1.11 version available, which works with Drupal 9.3.10 and 11, and it is actively maintained and has both security and test coverage.

The project has 36 open issues, seven of which are bugs, and it is in use by almost 2,400 sites according to Drupal.org. Now the module really provides three useful features. First, it can ensure that specific configuration files are automatically imported on every request, as though the contents were pasted into the Drupal Core single import form.

Second, it can automatically export specific configuration objects into files whenever the object is updated. You provide a list of file names and the module will derive the objects that need to be exported. Finally, it provides a drush command that can be used to generate all the necessary configuration files for a specific project. You put a list of the files into the project's info.yaml file and then with a single command,

A fresh copy of all the specified files will be generated and placed directly into the project's configuration folder. Now, for obvious reasons, this is not something you should ever have enabled in production. So definitely a best practice to pull this into your project would be using the require-dev composer command. But let's talk about configuration development.

Nic (03:37)
Did you, was this just a coincidence or did you just find out about this this morning from Slack?

Martin (03:42)
I did find out about this this morning in Drupal

Slack, yes.

Nic (03:45)
Yeah, so I think it'd be interesting to talk about one of the reasons why you would want this and that is helping keep your, if you have a contributor or custom module that needs, I think, optional or required config synced, it's a nice way to do that, right? Is that the use case you were using it for?

Martin (04:03)
Yes, exactly. Yeah, and there also was some discussion that thread about potentially using this with recipes, which I think is possibly even more useful. ⁓ There is an issue on the project to make it work with recipes. It is an MR that does currently require some work. So if that is something you'd want to use this project for, by all means, jump in and help that get ready to merge.

Nic (04:10)
Yep.

John (04:27)
Can we provide a more, I don't know, tangible example? Because I'm struggling a little bit here. Are we talking about, hey, I am a module developer. My module requires certain fields on certain content types. I can export, import the config and help with my development flow. Is that like that?

Andy Giles (04:43)
You

Martin (04:47)
Yeah,

I mean, probably a good place to start is the example where this came up. So there's an issue that I will confess has been kicking around for too long on the storage module, which we've talked about on the show, which provides its own view configuration for being able to manage all of your existing storage entities. Now that view was exported probably before Drupal 10. So

Andy Giles (04:58)
You

Martin (05:11)
hasn't been updated in the provided configuration file to follow the reordering that was done as part of it. I'm pretty sure it was Drupal 10. And so I think it was Unic who pointed out that after doing export, it'll show as being different, even though there aren't really any changes to the view. So having a module like this for a project like storage, could just before I, you know,

Nic (05:22)
Yep.

Martin (05:35)
do some kind of a configuration change, I can run a drush command to say just update the or regenerate the configuration file and then it'll automatically generate it out. Whereas previously the kind of workflow that I would do, which is kind of clunky is update, let's say the view that has, you know, that configuration imported, I'd go into through the Drupal UI and update it and then do a full site export and then have to pick through that to find the individual

view configuration file and then copy that into the proper place in the project. So having a single drush command or even potentially having the module itself configured to whenever that view gets saved automatically update the view configuration file is a pretty big convenience, I think, for developers who maintain these kinds of projects.

John (06:21)
Definitely cuts down on that workflow too because once that config, once that config updates, you do the export and then you can see it and get, you know you gotta include it.

That definitely makes a lot of sense. And.

Andy Giles (06:31)
Yeah, and I think the module's really helpful if you're doing migrations. So I'll typically create like a migrate module for the project I'm working on, and then I'll have all of the config in that module and then have config

dev will track that. So then as I'm iterating on the migration, it's tracking it and importing the config.

Nic (06:47)
⁓ that's what the request,

that's what the import is useful for. I was wondering what that part was useful for. That makes so much sense.

Andy Giles (06:52)
Yeah. Yeah. And then also if you have, there's like

a, you know, a series of drush commands that comes with it and you can import like a one-off config. So if you have a config somewhere that you want to import, you just drush CDI one, point it to the file and then it pops it in. So it's really helpful to kind of get things in and out like a one at a time.

Nic (07:02)
Mm-hmm.

Interesting.

John (07:12)
Wait, wait.

Drush CDI 1?

Andy Giles (07:16)
CDI1,

Nic (07:17)
That's the gesture command for the module.

Andy Giles (07:17)
it's like, yeah, config devil import one, I guess, is the acronym. And so, you you just point it to a single config file and then it'll bring it in.

Nic (07:27)
It's probably one because it's one file. If I had to guess.

Andy Giles (07:30)
Yeah.

John (07:31)
So there is no two three four

Andy Giles (07:35)
I think you can import a whole directory ⁓ with, but that's just the one that I seem to always use is because I want like a specific config file imported. Yeah.

John (07:38)
Got it. Makes sense.

I love every time I talk about the config system in Drupal, like I really do. I just love it. I love, I love how easy it makes things. but you know, with great power comes great responsibility. Anyway, Martin, thank you again for bringing us a super interesting module of the week.

Andy Giles (07:58)
you

John (08:03)
And if folks wanted to suggest a module a week, talk about this module a week, or just connect with you, how could they go about doing that?

Martin (08:10)
definitely always happy to have spirited conversations about potential candidates for module of the week in the Talking Drupal channel of Drupal Slack, or folks can reach out to me directly as man clue on all of the Drupal and social platforms. But I did also want to say a quick happy birthday to Drupal, which is turning 25 in two days from this recording. So congratulations to Drupal and the community and ⁓ 25 incredible years.

Nic (08:31)
⁓ yeah.

Thursday will be 25. My goodness. That's a long running project. Hopefully we get another 25 years out of this. I'm curious to know what Drupal will look like at its 50th birthday.

Martin (08:53)
That's right.

John (08:53)
I mean, I don't know. I feel like it's doing pretty good at 25 right now. It's AI native. It's got Canvas on the horizon here of... ⁓

being a layout tool in core. We just talked about config. A lot of things moving in a very, ⁓ very positive direction. yeah. it can, well, it could, anyway, yes, it can rent a car. It can also drive a car, maybe. Anyway. Hey, listen.

Andy Giles (09:12)
And it can rent a car.

Maybe.

Nic (09:21)
I wouldn't recommend it.

John (09:25)
Happy birthday to Drupal. I would say that there are going to be some parties throughout the world to celebrate this momentous occasion. So I look forward to hitting one of those up maybe.

Martin (09:37)
Yep, there's a few listed on the events page, community events page on Drupal.org, but of course, by the time people hear this, only our Patreons will have heard it in time, unfortunately, so.

John (09:46)
All right. Well, Martin, thanks again. And ⁓ we'll chat with you next week. All right. Cameron, before we jump into specifically Composer Patches 2.0 and all the great new stuff that's happening there, can you just give us kind of an overview of what Composer Patches does?

Martin (09:52)
See you then.

Cameron Eagans (10:09)
Sure, so I imagine we've all used Composer. It's kind of a way to describe in a declarative way the dependencies of your project. Composer patches extends Composer so that you can sort of declaratively say what changes you want to apply to those dependencies that are necessary to make your project run. I'm sure we've all had core patches or whatever that

Andy Giles (10:30)
You

Cameron Eagans (10:31)
that our modules

depended on. that's what Composer patches enables is changing dependencies in your project to fix bugs or add features or whatever without necessarily requiring upstream changes.

Andy Giles (10:43)
You Okay.

Nic (10:44)
And if you remember, this is in contrast to, you know, there's, there's a big mantra in Drupal, right? Don't, don't, uh, hack core. Right. And I think one of the big reasons for that was because you didn't, you didn't have

a way to know what changed before. I mean, with Git, could see some history and stuff, but you used to have to use the hacked module to like, evaluate a project and see what was changed. And I've certainly still seen.

Andy Giles (11:00)
You

Nic (11:11)
Occasionally see projects where people just directly change core and apply those changes each time. one of the huge benefits aside from, ⁓

Andy Giles (11:16)
you

Nic (11:19)
I think the declarative aspect of like, these are the changes I've made is one of the major benefits because I can, you know, on an old project or a new project that I didn't maintain, I can look at it see what, what issues that particular, project is, is importing and kind of track the progress and see if there's something I can.

contribute to, right? I think that's one of the biggest advantages of it being able to declaratively say, these are the changes you should look at when you're updating. These are the features you should test.

John (11:47)
I mean, I think also to your point there, Nick, like for me, it feels like a cleaner, right? More well organized way of replacing like the patch directory that everybody used to have in their projects, right? Like you would basically, you know, pull a patch, you drop it in this directory, you'd apply it with Git and you'd be like, hey, we patched, you know, this module or core or whatever it was, right?

Andy Giles (12:04)
You

John (12:11)
and you'd have a list of these patches in your directory. At least now you go into your Composer JSON file and say, oh, here's the thing. Here's a little title that tells you why this was necessary. And you have a link out to the patch, or you can keep the patch locally if you want to do it that way. But I don't know. It just feels better organized,

Cameron Eagans (12:31)
It

also gives you ordering of the patches, which is really important and requires some effort to do with the patch directory.

Nic (12:39)
yeah.

Yep. Absolutely.

Cameron Eagans (12:42)
Because you'd have to either name your patches like one underscore whatever the patches dot patch, you know, or, you know, script it apply them in the same order, matter what.

Nic (12:51)
Yeah. And you can provide more metadata too. Like one thing I've taken to doing is just when it's a Drupal patch, just providing a link back to the Drupal issue where it's being tracked.

John (12:56)
Mm-hmm.

Nic (13:05)
I no longer have to like, find, what was this one? Where was it? Like you can provide a title and a link. And so I do that for, even if it's a GitHub project, right? It's not a Drupal module or something.

John (13:16)
I will also say it makes updating modules a lot easier too because now, again, previously you'd have this patch folder and depending on how you organized it, maybe you know what patches went to what module and whatnot, but maybe you didn't. I don't know. Depends on how you did it, right?

They like one of my favorite things to do is like, composer update this module. And it's like, I can't do that. And you're like, I have a patch on it. Here it is. Write my composer file. Let me remove it. Like, I don't know. Just makes things better and cleaner. And I'm a big fan of that.

Nic (13:48)
So one thing that I'm curious about your bio, you mentioned that you're, you maintain some PHP projects that have been downloaded over 90 million times and composer patches alone was downloaded nearly 88 million, 900,000 something times. And it's used by many, many more communities than just Drupal. I'm curious, what is it like maintaining a project with

That many users, that many installs. Obviously each install doesn't equate to one single user, but what's it like maintaining a project that has such a broad base?

Cameron Eagans (14:24)
It's stressful, you know? And, you know, we'll get to this in a little bit, but that the... Like how widely this project is installed is one of the reasons it got rewritten for 2.0 in the first place, ⁓ which may sound a little counterintuitive, but we'll come back to that. But, you know, if you have a project that's used by like 10 people and you break a workflow, you might affect like...

Nic (14:36)
Hmm.

Cameron Eagans (14:47)
one or two people, right? If you have a project and it's used by millions of people and you break a workflow, you're breaking millions of people's workflows, right? And you know, it's cumulative install. So it's more realistically like thousands of people, but like, it's stressful. And having good test coverage and a good community around it makes it a little easier.

Nic (14:56)
Yeah.

Well, I, I'd like to dig into that a little bit because, um, how does the community aspect of this work? Because, uh, we're all from the Drupal community. You're originally from the Drupal community, think. Um, and we're all pretty heavily involved in Drupal where I'm used to that. And I feel like whenever I step outside of Drupal, sometimes there's a community, it's like hit or miss. Right. But usually if there's a community, there's like a separate hub for that community. So where.

Where does the community for like composer patches that ecosystem kind of live? it just in GitHub or is there a discord or like, how does that work? Or are you just talking about kind of like the Drupal community or the WordPress community or like the separate communities that use the tool?

Cameron Eagans (15:45)
⁓

Well, it's a little of both. So the primary users of the plugin are like the Drupal community and to a lesser extent the typo three community and Magneto, think, or Magento, I don't remember which one.

Nic (16:04)
Gentum.

Cameron Eagans (16:05)
But those communities have pretty well developed ideas of how they want to work and how they want their tooling to work. And being able to lean on that kind of shared idea is helpful for me. I don't have to invent everything from scratch. These people know what they're doing, so let's just.

sort of take the best out of all those communities and sort of codify them into a composer plugin. There's also other communities that use this plugin. WordPress is like, there's a few users who are doing WordPress stuff with this plugin. And they don't have quite as well defined ways of working.

But the fact that they are opening issues and reporting bugs and things like that, that's also helpful. I can imagine all day long how I want a patching plugin to work, but ultimately it needs to work for the people that are using it.

Nic (16:52)
I will just point out that saying that they don't have a well-defined way is a very kind way of stating how the WordPress community works currently with deployments and code management. I would personally say that the lack of a kind of standardized process for that is one of the greatest detriments, because I do WordPress development too. And the lack of like a standardized, like a...

Cameron Eagans (17:02)
Yeah.

Nic (17:16)
I just appreciate the Drupal community's deployment and development first attitude when it comes to that, because it makes things like this so easy. With WordPress, it runs a gamut. Some plugins don't support Composer whatsoever. Like you literally can't install it with Composer. They don't have a public access point. yeah, it's a, ⁓ it's a very different approach.

Andy Giles (17:36)
Yeah, and uh...

Cameron Eagans (17:37)
I built my first WordPress site

not too long ago. Like my website is WordPress. And that was the first actual WordPress site I built. And it was painful coming from the triple world.

Andy Giles (17:48)
So as somebody who's used your plugin since I stopped doing Drush Make to build my projects, I got to say thank you first and foremost. And then secondly, where did the idea come from for composer patches?

Cameron Eagans (18:00)
Drush make actually it was was the origin So in I think it was 2014 Now you know what it is so I started an NBC December of 2014 And NBC had an internal Drupal 7 distribution For their various brands, you Telemundo sci-fi, etc, right? ⁓

Andy Giles (18:01)
There you go, nice.

Nic (18:20)
Mm-hmm.

Cameron Eagans (18:22)
They have this Drupal 7 distribution. They've been working on it for a few years and Drupal 8 is in like an early alpha. And the goal that this team was given was to port this Drupal 7 distribution to Drupal 8 in the very early stages of Drupal 8's development so that we sort of like maximize the amount of time that we can use this application before we need to upgrade it to another version of Drupal.

But unfortunately, that was like right in the middle of all of the, if you remember from that time in the Drupal community, we were trying to figure out how to use Composer to work on things. We had some people just randomly submitting modules to Packagist. We had people with a repository stanza that was about nine miles long.

Nic (18:52)
Yep.

my goodness, I forgot about that.

Cameron Eagans (19:04)
Yeah, like individual Git repositories for each module in the repository, so your composer.json was not a fun way to work.

So I worked on two projects right around that time to sort of enable the team to work on an early Drupal 8 alpha. One of them was composer patches. So the Drupal 7 based distribution that they had heavily relied on Drushmake. There were patches for about every module we had imported and in core.

So it was pretty clear that we were going to need that kind of capability for the Drupal A distribution as well.

And we especially needed it for core because it was still in flux. So the first version of this was a couple days that it was a spike in our issue tracker. spent a couple days building out this proof of concept. And I got a little bit more time to clean it up and make it more broadly usable.

That's where the first version came from. And I think actually if you look at the commit log, the first commit is something around the lines of ⁓ initial import into Pub Central or something like that. And that was the name of the distribution at NBC. So it was like a subtree split out of that repository.

Andy Giles (20:03)
You

Nic (20:08)
⁓

And why, why was the decision

Andy Giles (20:18)
you

Nic (20:20)
made to do it on GitHub? rather than if it was a Drupal project and a Drupal thing, was it just because it wasn't a Drupal module and you decided to put it there? Was it because it was a composer plugin and composer was on GitHub? Was there a specific reason or?

Cameron Eagans (20:34)
Well, it wasn't Drupal specific for one thing. It was a composer plugin and the pattern for other composer plugins at the time was to live on GitHub. The other thing was that Drupal.org didn't have really a good place for this to live. We could call it a module, but it really wasn't a module. ⁓ I think at the time there was like a utility project or something like that that some people had access to create, but...

Nic (20:48)
Yep. Yep.

Cameron Eagans (20:57)
that it didn't really fit. So GitHub was

Nic (20:59)
Yeah.

Cameron Eagans (21:00)
kind of a better target.

John (21:02)
So I had a question in here to ask if it was a Drupal specific utility to start, clearly it was, because that was the project you were working on. How much of an effort was it to kind of broaden that to other composer-based projects, or was it just kind of worked the way that it worked, no matter what?

Cameron Eagans (21:19)
Well, I wouldn't say that it was made as a Drupal specific utility. There was nothing in even the very first commit that was pinned to Drupal. It was for a Drupal project at the time, but it was just plain PHP plugged into Composer. I apologize, I have spaced on the second part of your question. ⁓

John (21:37)
Hm. I was just.

curious, actually, I guess the second part of my question doesn't necessarily matter because it sounds like you just answered it. It was more PHP working with Composer. So I would imagine that other projects using Composer were able to just kind of pick it up and run with it as opposed to needing to do anything different or specific. ⁓ So let's focus in a little bit more on Composer patches 2.0.

Cameron Eagans (21:57)
Yep, pretty much.

John (22:04)
Right. so clearly, you know, 1.0 had come out a while ago, right. And it is very widely used as you, as we've, we've talked about, I'm curious, why you felt that a, it needed to be updated and B why, why now was the, was the time for that.

Cameron Eagans (22:19)
Yeah.

So, okay, so after we released composer patches publicly, we sort of added a few features and it got up to, you know, a one dot, I think like the one dot three-ish release was when I started thinking about 2.0. By then, a fair amount of the Drupal community,

John (22:34)
So

how long ago was that?

Cameron Eagans (22:39)
Oh, 2015, 16, somewhere thereabouts.

John (22:42)
OK, so you've been thinking about 2.0 for a while now. OK.

Cameron Eagans (22:46)
yeah, yeah,

Composer Patches 2.0 was like almost 10 years in the making. It was the Duke Nukem forever of Composer Patches releases. ⁓ So with as many users as I had in the Drupal community, the lack of test coverage, the lack of...

John (22:52)
Fabulous. Awesome. Okay.

Cameron Eagans (23:09)
well-defined, you know, that this is

what we do support and this is we don't support. Like there weren't any guardrails or boundaries to the project at all. And there was a, like, I actually struggled with a lot of guilt on that for a while. Like, you know, these things are broken and I don't really have like a safe way to fix them.

Andy Giles (23:20)
You

Cameron Eagans (23:28)
where I can guarantee that I am fixing somebody's workflow and I'm not breaking somebody else's workflow. So I started kind of...

Nic (23:36)
Can we pause for one second here and talk, maybe expand a little, because this is something I think I know some of these details, but can we expand a little bit on what you mean? Because yes, we know this is used by a lot of people, but I think most of the people listening to the show are really just using it in the Drupal way, right? They're finding a patch file or diff on Drupal.org. ⁓

adding that line to the whatever the, know, Drupal slash whatever the module name is, and then putting a little thing in theoretical. And at a high level, it sounds very simple, like, it downloads composer and then it downloads the project and then applies this patch and, and you're done. And if it doesn't apply, it says, Hey, I couldn't apply it. And you're done. I have a feeling just generally knowing how things work and based on what you've been saying, that there's a lot of hidden complexity and there's a lot of weird things that people do.

with this project. can you maybe, as you're answering this question, can you maybe step aside for a second and tell us like what kinds of workflows were breaking or what kinds of bugs were you trying to fix? Just so our listeners know some of the underlying complexity.

Cameron Eagans (24:41)
Sure, yeah. I mean, it wasn't anything particularly exotic or strange, right? was, if you have a project with a module and a patch on that module and you want to update the module and update the patch, you have to do one or the other first, right? So you're probably gonna update the module first. You go bump the version constraint and you run your composer commands and it pulls down the new module.

Nic (24:47)
⁓

Cameron Eagans (25:04)
I would expect that the old patch would fail. So you've updated this module, you haven't updated the old patch, so that first composer update fails. ⁓ So then you go update your patch. How do you get the new patch to apply?

Nic (25:14)
Yes.

You run install again, I assume. I mean, that's what I do. Right. Wait, how could you do it? You mean like a special.

Cameron Eagans (25:20)
Maybe, maybe. I mean, that works for like

90 % of people. That works for 90 % of people. And in other cases, they'll go run that composer install and it just won't do anything.

Nic (25:28)
Okay.

Really?

Cameron Eagans (25:34)
Yeah, and I had no idea why. I could never reproduce it, but I had like composer install logs from like dozens of people where, you know, these are the specific steps that I took and here's how I reproduce it reliably on my machine. And then like I couldn't come and figure it out and fix it. I was never able to reproduce those. No, no, I had no idea. Yeah.

Nic (25:51)
you ever figure it out or no? You've never figured it out? So it's just a mystery? God, those are the worst.

Okay. Okay. So you're worried about introducing new bugs like that, it sounds like or, or breaking something? Because? Okay. ⁓

Cameron Eagans (26:04)
Yeah. The conclusion

that I of came to was Composer Patches 1.0 tried to just handle everything with minimal intervention. It was supposed to be as declarative as possible, and there were a few config flags that you could put in your Composer.json, but for the most part, it was supposed to just work. And in that sort of just work,

Nic (26:18)
Yeah.

You accomplish that mission.

Cameron Eagans (26:29)
Well, I don't think I did in 1.0, but 2.0 is closer at least. ⁓

Nic (26:32)
Okay.

Cameron Eagans (26:33)
but the sort of like implicit behaviors, I think, were where a lot of those bugs came from. So my goal in 2.0 was, you know, we need to make some of these behaviors and workflows more explicit. you know what this plugin is doing and there's no question about, you know, has it done the thing or is it going to do the thing? Like when you tell it to do the thing, it should just do the thing.

Nic (26:39)
Hmm.

Andy Giles (26:54)
you

Nic (26:56)
So that also makes debugging easier for you because you can isolate what stage is breaking for a particular person, right?

Cameron Eagans (27:03)
Exactly.

Nic (27:04)
So

Andy Giles (27:04)
you

Nic (27:05)
that's one feature or maybe you could call functionality that's coming for Composer Patches 2.0. there other other than kind of stability or debugging or kind of just general refactoring? there other new features coming with 2.0?

Cameron Eagans (27:20)
Yeah, there's some interesting stuff. If you're interacting with it as a developer building other Composer plugins, there are some API extension points for adding functionality to Composer patches itself. There's a couple of nice command line commands that are provided to Composer so that you can... ⁓

⁓ So you can run the repatch process after you update your composer.json or whatever. There's also the patches.lock.json to sort of lock all the shot sums of your patches and store some extra metadata. I don't know if you've ever looked in your patches.lock, but there's even some information about...

like patch provenance, where did this patch come from? Why is it in my project? Which helps with debugging a little bit. There's a free form patcher. can write arbitrary commands.

Nic (28:03)
Okay.

So, so like, so like.

So when you say provenance, like it will tell you if it came from a mirror or something or local or do you mean something else?

Cameron Eagans (28:21)
⁓ so like the,

this patch was, this patch was defined in my root composer.json file versus it was pulled in because some dependency wanted it versus, you know, some other plugin defined some way to retrieve this patch. And here's where it came from.

Nic (28:36)
That sounds amazing. Yeah, no, that sounds really powerful. Also, if I recall correctly, there was a somewhat controversial direction I think that 2.0 took at some point. And I think you may have changed direction. Can you talk a little bit about that? Because I remember seeing it's one of the few times I think I was in the issue queue for composer patches.

Andy Giles (28:36)
You

Cameron Eagans (28:56)
Uh-huh.

Nic (29:05)
I don't even remember

what it was, but I reading through the thread. Can you talk a little bit about that?

Andy Giles (29:07)
You

Cameron Eagans (29:13)
Yeah, so Composer patches has a few different ways to get patches for your project. To resolve them is what it's referred to in 2.0. So you can look in your composer.json, you can look in your patches.json, and one of the things that 1.0 did that a lot of people relied on was that your dependencies

can define patches for your root project.

So you can, for instance, pull in a contrib module that defines a core patch. So like this version of this module requires this change to Drupal core. So I removed that functionality to get patches from dependencies.

Because it seems kind of simple. Like, well, we'll just look in this other place for patches and pull them into the main list. But that kind of opens a can of worms.

Nic (30:05)
Because that

requirement can come from a patch itself. So you have to like loop over it, right? Is that the issue?

Cameron Eagans (30:13)
it can't actually, ⁓ and we can, we can come back to that, but, you, can't actually apply patches to your like local composer dot JSON files. Cause the metadata that composer uses to figure out all your stuff is, is like that that's all pre-computed and loaded into packages.

Nic (30:14)
Oh, you can't.

Okay.

⁓ so it resolves it before. so that's just like

the vert. OK, so it's the same issue as the lenient plugin is solving because the version constraints happens before it sells. OK, that's good to know. That's a whole class of bugs that you probably wouldn't want to handle anyway. That sounds good.

Cameron Eagans (30:35)
Yeah, yeah, exactly.

Andy Giles (30:40)
You

Cameron Eagans (30:43)
Yeah.

but it's more like supply chain stuff, you know? So if, ⁓ if, if a module's repository got compromised or, even like some random PHP dependency you were pulling in that, that doesn't live on Drupal Network. if that repository got compromised, they could define a patch for Drupal Core that, yeah, I don't know, like enables PHP input for all of your comment fields or whatever. Right. Like it, it like,

Nic (30:46)
Yeah.

Yeah. Yeah. We

just saw that with NPM like six months ago. Yeah. We just saw that with NPM six months ago. Same, same issue. Yep.

Cameron Eagans (31:07)
You could really do some damage. Yeah.

Yeah. So you could really do some damage if you compromised some dependencies repository for one thing. And then the other thing is, what if your, what if your root project defines the same patch? You got to de-duplicate them. And how do you know it's the same patch? Well, okay, you can take a shot 256 some of it, but you have to get both patches first and then you have to decide which one you're going to apply and which one you're going to complain about. ⁓

Nic (31:13)
Makes sense.

Yeah.

Cameron Eagans (31:34)
You know, are you gonna silently drop the second one? Are you gonna tell the user the patch doesn't apply?

What if that dependency applies a patch that conflicts with one of your existing patches that isn't the same patch? It's really difficult for people to debug that kind of thing because the definitions for the patches weren't visible in the first place. They live in some third-party location.

Nic (31:52)
And so how did you make the decision to pull that feature back in? Because my understanding is that you heard the feedback from the community and decided to add that back in. Is that correct?

Cameron Eagans (32:03)
Yeah, yeah, I got a lot of feedback on that. People were not happy with it. They were not happy with workarounds about like, I had an idea for maybe we'll have a command line thing to pull in, like to just import the patches into your local patches.json or whatever. That kind of workaround wasn't gonna do it because people would forget to do it.

Yeah, it was mostly like we really can't live without this. And that was almost unanimous, I would say.

Nic (32:36)
interesting.

John (32:36)
I have a dumb, dumb question, point of clarification here, right? So does this process require that the module or whatever project you're including be using Composer patches to pull in those patches for those dependencies?

Cameron Eagans (32:55)
Yes. Well.

So your root project has to have composer patches. It won't work if a dependency says, I'm gonna add composer patches and then define this patch on core, right? Like the root project has to have patches enabled.

John (33:08)
All right. So I guess I meant,

yeah, I guess I meant that the other way around. Like if I'm building a Drupal site, right. My Drupal project, my, my, my project has composer patches installed and, and, and, you know, I'm, I'm installing my own patches. If a dependency say, I don't know, we'll just use web forms as an example, right. Defines patches using composer patches. Then this process would work, but.

what if I'm using another package or module that doesn't define patches in this way, then it's just, they're just gonna be ignored.

Cameron Eagans (33:40)
Yep. Yep, just ignored. It's kind of a, if the dependency defines packages, we'll use it.

John (33:48)
But that being said, is a composer patches is a pretty widely used kind of patching standard at this point for composers. So like a lot of people are using that as their kind of patching methodology, right?

Cameron Eagans (34:00)
Yeah, so the dependency patches was a thing. I came up with a way to make it a little bit more friendly in terms of maintenance. And that's what's in the repository today.

Andy Giles (34:11)
Cool and you went over this a little bit, but explain patches lock JSON and why that was such a big change

Cameron Eagans (34:18)
Yeah. So in ComposerPatches1, you could have an external patches.json, but functionally, it was the same as if you had just inlined all your patch definitions directly into your Composer.json. So the only real place where

there was any kind of like integrity checking in 1.x was does the composer.json match the composer.lock. So if you like updated your patch definitions, it would change the text content of composer.json and you'd get an updated SHA-256 or SHA-1. I can't remember which one composer uses for the lock hash. That was about it.

⁓ and that's kind of a problem because, ⁓ lot of people apply patches directly from say a get up or get lab issue, right? If you, or I'm sorry, a pull request, or if you go to a pull request and tack on dot diff or dot patch, it gives you a ready to use patch, but that patch, will change as that pull request changes, as the contents of that branch change. so the, patch that you added yesterday could be.

Andy Giles (35:00)
Can change. Yeah.

Cameron Eagans (35:23)
different today. And that's a problem for people who want their builds to pass reliably or to know what's actually going into production. So patches.lockedatjson, for every patch that you download, will, number one, store a copy of the patch locally in a cache so that it doesn't have to go re-download them every time. So it speeds up your builds a little bit. And then number two, it will

compute a checksum from that hash and store it in this patches.lock.json so that you know if it ever changes.

Nic (35:51)
And we will say very loudly and clearly right now, you should never be using these as your end as the patch unless you're just like testing it. Right. So I will when I'm testing a patch for a fix or something, I will use the dot diff or dot patch version. I'll test it. And then before I even push it up to Dev, I'm downloading that file to a local copy. And you should always, always, always do that. You should never

unless you're actively testing

Andy Giles (36:20)
You

Nic (36:21)
something, you should never be pointing to, an online resource for a patch like that, because like, like Cameron said, that can change and it can be, aside from being able to break your site, can be a security issue. It can be, I mean, there's all sorts of problems with it. ⁓ I'm glad you supported it because it makes testing these things a little bit easier, but you know,

you should never do this in production or even like a staging site. You should always use a local patch. That would be a flag. Actually, that's a question. Is there a flag that I can add to my CI that will fail any remote patches in case I forget to? Because I do occasionally forget and catch it in code review or something. That would be a nice flag. Maybe I'll make a feature request.

Cameron Eagans (36:58)
No.

No, there's not. I would be

interested in potentially adding something like that. But I would soften that recommendation personally. With the lock file, it's not as big of an issue in 1.x. You'll know if those patches change.

Nic (37:09)
Really? ⁓ that's true. That's true. Maybe.

Andy Giles (37:14)
Yeah, because I think traditionally I would put

like a Drupal.org patch that is not going to change. Whereas GitLab adding .diff that would change. So what is your, know, what do you recommend now? So do we download the diff, put it locally or with 2.0? Do we, you know, depend on the hash to verify changes? What do you recommend?

Cameron Eagans (37:37)
do what works for your workflow, which is kind of a non-answer, but it's no longer unsafe. It's no longer unsafe to depend on those .diff or .patch URLs. It's just probably going to cause you a headache because that pull request will likely change at some point. But at that point, at that point, the critical thing is that you're alerted to that change.

Andy Giles (37:42)
Right. Okay. Will change. And so the process now is it.

John (37:43)
It's the safe answer.

Andy Giles (38:00)
You're alerted.

Yeah. And so it has a hash. It compares it. You mentioned there's a cache too. Can you go over that again? Because the. ⁓

Cameron Eagans (38:07)
Yeah. Yeah. So Composer has its own download cache and we just reuse that. rather in 1.x it was reaching out to the internet and downloading your remote patch file every time. And then it would apply it to your patch or to your package rather. 2.0 it'll...

Andy Giles (38:13)
Gotcha.

But that's only local. So if you push this

to a CI pipeline, it's not going to have that cache. The hash is going to fail, and then you're going to be alerted that the build will fail. That's what should happen, right? Cool.

Cameron Eagans (38:38)
Right. Exactly.

Nic (38:38)
Well, well, I imagine

don't you cash in the same place that the composer cash live. So if you have a cash, a lot of my clients, set up a CI cash and we'll dump it like weekly or something. So if we have multiple builds in a day, it will be faster. So I imagine that patches are cashed the same location, right? Is that, yeah. So you still can get that benefit even on a.

Cameron Eagans (38:55)
There we go.

Yeah, so it'll either apply the old patch, it'll either apply the old patch, in which case you've already reviewed and approved it, or it'll try to approve or try to apply the new patch, in which case it'll complain loudly and you'll have to review and approve it.

Nic (38:59)
CIA if you set that up properly.

John (39:00)
Hm.

Andy Giles (39:12)
Cool.

John (39:13)
That's how I like my complaints, loudly. So 2.0 moves to git patching as opposed to the patching mechanism that was in 1.0, right? Why that change? Why was it important to move to git patching?

Nic (39:14)
Very nice.

Cameron Eagans (39:34)
Well, so the patch utility on your command line is very likely not the same between machines. Macs ship with BSD patch. A lot of Linux distributions ship with GNU patch. Some Linux distributions ship with like the version of patch that's included with Busybox, which is different.

There's a few other versions out there. But importantly, they behave differently and have varying levels of success in actually applying a patch. By contrast, every version of Git since, I don't know, 2015 or something is pretty bulletproof as far as...

patch application goes. It handles binary patching better, it handles renames better, it can handle conflict resolution a little bit better as different, you know, merge algorithms that you can try in case something goes sideways. And importantly, it's available pretty much everywhere in the same state in sort of a reliable way. So the intent was to make it

you know, going back to the, if you tell it to do the thing, it should do the thing mindset. We want it to apply the patch when you tell it to apply the patch. Git was kind of the best way to do that. I had considered other ways to do this. And you can actually still implement this with some of the extension points that are in 2.0. I had considered like shipping a cross platform.

build of GNU patch so that we had something reliable that just shipped with Composer patches itself. If you've looked at the Cosmopolitan C project, does, you can build a binary that runs on Mac, Linux, and Windows, all in one executable. ⁓ So that, yeah.

Nic (41:14)
That sounds like a lot of work.

Cameron Eagans (41:18)
So I worked with their maintainer a little bit to get patch running in that system. It just didn't end up being the right thing. You'd have to download a binary that's several megabytes with every composer install, and I didn't want to do that. I also considered it like a pure PHP implementation of patch. ⁓ It wouldn't be good, but it would work everywhere, kind of. ⁓ And that kind of is why we didn't do it. ⁓

John (41:29)
So I mean.

Cameron Eagans (41:47)
So Git was

really the only candidate.

John (41:49)
Yeah, so it makes sense, like, it's widely used everybody. And at least now everybody's kind of using the same thing, right, which I imagine makes your life as a maintainer a little bit easier because you're like, if you're having a problem, least I like it. Everybody's using the same, same sort of the same sort of process, right? What happens if you don't have Git? Does it require it? Does it say like, hey, you got to use you got to like install Git in order to use this? Like, how does that?

What does that look like? Got it. OK. All right. Yeah. OK. Makes sense.

Cameron Eagans (42:14)
Yeah, 2.0 requires Git. It's a hard requirement. You can disable that particular patch, like a plier, and add your own, but the core plugin requires Git.

Nic (42:29)
Interesting. Well, there's also a, before I ask the next question, there's an issue going through the Drupal issue queue that you may or may not want to chime in on, which is to, the idea is to

all of the test files from the release releases, right? So Drupal 12.0, if you download it from Composer and not the

Andy Giles (42:55)
You

Nic (42:55)
dev version, you're not gonna get any test files. And the idea is that there would be a way to update the diffs so that the diffs only have kind of the functional changes, not the test files. But I imagine there will be some confusion as that rolls out.

⁓ but one of the ideas is we want to be able to organize tests a little bit better, move them around, but we don't want to break thousands and thousands of patches doing that. So the only way to be, have more flexibility is to be able to kind of just shift things around without having them and get, ⁓ or in the, in the release, ⁓ police package, which, which actually brings me to a side question when you're

When somebody specifies a patch, does composer need to download a different...

asset for the original package or is it still because I know you can specify using source or like like a tar

Cameron Eagans (43:47)
Mm-hmm.

Nic (43:48)
Does

it need to download the source version of whatever package version you're downloading in order to apply it? Or does it have a way to handle it if it's just like a tarball?

Cameron Eagans (43:57)
No, not always. can... So if you already have a git checkout on disk, Composer patches will just cd into that directory and git apply your patch. If it was downloaded from a tarball or whatever, and Composer calls this like a distribution package, if it was a distribution package, it will cd into that directory, run a git in it.

Nic (44:11)
Mm-hmm.

Cameron Eagans (44:16)
and then git apply and then delete that git directory. ⁓ So it's kind of like faking it. ⁓

Nic (44:16)
Yeah.

Okay. It's

so funny. That's so obvious. As you're saying, like I, as you started saying it, I realized what the solution was, but I mean, it's clever. It's clever.

Can you tell us a little bit more about any new APIs or features that a developer might want to know and start incorporating into their workflow? For me, it sounds like the patches JSON is something to look into. Is there anything else that you're trying to get the word out about?

Cameron Eagans (44:46)
Yeah, so I guess the first thing is Composer Patches has like a proper documentation site now instead of just one mega readme. So that's docs.cwbegins.net. It's linked from the Composer Patches repository. But there's a whole section in there about the API. And there's kind of two...

Nic (44:52)
Okay. Okay.

Andy Giles (44:53)
You

Cameron Eagans (45:04)
Yeah, I guess sort of three things to be aware of. One of them is the patches.lock.json. We're kind of considering that like read-only for external uses. But there's some useful information in there. The other two things, in my opinion, are a little bit more interesting. So there's capabilities and events. And these are both things that Composer provides.

Nic (45:11)
Okay.

Cameron Eagans (45:25)
Capabilities are analogous to Drupal's plugin system. So in Composer Patches case, you can define a new resolver capability, a downloader capability, or a patcher capability. And respectively, are how do I know what patches to apply to my project? How do I know how to get them? And how do I know how to apply them?

Nic (45:33)
Okay.

So if you have like a private hosting location for your patches or something that needs some sort of authentication or something, you could create your own downloader plugin that handles the authentication. Okay.

Cameron Eagans (46:00)
Sure, or

I've seen projects where their patches are, it's a patch directory, but it's managed in like some corporate Perforce server or something. ⁓ And they have to jump through some moves to like pull that down first or whatever. You could define a downloader to go grab it from Perforce if you wanted to. ⁓ The resolvers would be things like.

Nic (46:10)
Okay.

Awesome.

Cameron Eagans (46:24)
I can find patch definitions in my composer.json. So that's one resolver. I can find patch definitions in my patches.json. That's another resolver. Or in my dependencies. That's another resolver. So those are the three core resolvers. But you could also say, I'm a module maintainer, and I want to test my module with the, I don't know, top 10 most commented things in my issue queue, and go write a resolver to go.

Nic (46:36)
Okay.

⁓

Cameron Eagans (46:49)
Like look at the Drupal.org APIs and pull those down or whatever, or, you know,

Nic (46:53)
interesting.

Cameron Eagans (46:54)
the, the resolver is what makes the decision on, you know, is the patch in route.

Nic (46:58)
Okay.

John (46:59)
feels like it could be an interesting way to do version testing for modules, right? So like, hey, all the patches that are tagged with like, know, Drupal 12, Drupal 11, whatever, go get those, apply them and like, let's see what happens, right?

Cameron Eagans (47:17)
Yeah, yeah, exactly. Yeah, if you write the right resolver, you can definitely do that. I know some people are doing like PHP 8.4 to 8.5 upgrades, and they have, for whatever reason, different patches on different versions of PHP. So you could write a resolver that selectively includes patches for different versions of PHP if you wanted to.

Andy Giles (47:40)
You

Nic (47:35)
⁓

That's pretty clever too. You've said a couple times now, we, who's we when it comes to composer patches? Who are the other contributors?

Cameron Eagans (47:49)
so that that's a that's a bad habit that I'm trying to get rid of actually. ⁓ so we in the cases where I've used it is likely referring to myself and the community have agreed, ⁓ that this is this is the way,

Andy Giles (48:00)
you

Nic (48:01)
Okay. Okay, I wouldn't

say that's a bad habit. I just wanna know if there was anybody in particularly wanted to shut up, makes sense.

Cameron Eagans (48:10)
Yeah,

there is actually, now that you ask, Dane Powell is actually the other maintainer on.

He committed a couple things and took over maintenance when like life got a little too much for me a little while back so He took over and sort of bridged the gap. So thanks Dane ⁓ He still has commit access actually so if I don't know if I win the lottery and never want to touch BHB again or whatever like This this plug-in can keep going

Nic (48:25)
awesome.

Good to know.

Andy Giles (48:39)
You

talked about capabilities. Can you give an example of an event and how we would use that?

Cameron Eagans (48:43)
Yeah, so events, there are a handful of them. I don't remember them all offhand, but there's a class in the project that lists sort of all the different places where you can hook in and respond. And this is more analogous to Drupal hooks than plugins.

So I know for sure there's sort of like a.

Andy Giles (49:01)
It looks like symphony too. So that's,

is that in composer core, this like patch infrastructure that's somewhat just like event subscriber oriented.

Cameron Eagans (49:10)
The event subscriber and event broadcast plumbing, that's all provided by Composer. Same thing with the capabilities. Capabilities are how most Composer plugins work, actually. You have to define a capability and a class that implements it.

Nic (49:23)
I see.

Cameron Eagans (49:25)
So the events are to hook into things that aren't easily replaceable by capabilities. So you could say like, before I apply this patch, I want to verify something. don't know.

Andy Giles (49:39)
Nice.

Nic (49:41)
You could also use it for

Cameron Eagans (49:42)
But there's, I want to say half a dozen or a dozen of them or something.

Nic (49:47)
like a notification system or something like, is there like a first time this patch is applied event or something in an environment? then you could publish a report or something, I presume.

Cameron Eagans (49:59)
There's not really the notion of the first time a patch is applied. It's just applied or not. ⁓ But yeah, mean, you could certainly subscribe to all of the pre-patch apply or post-patch apply events and gather them up and then show a report at the end of your composer run. Sure.

Nic (50:04)
You can still check that.

Very cool.

Cameron Eagans (50:17)
There were a couple of users that were doing this in 1.x. This actually existed for a couple of things in 1.x, it's much more robust in 2.0.

Andy Giles (50:27)
And so Core Composer is basically extending the same symphony libraries that we're used to in Drupal for the event subscriber stuff. mean, it looks basically the same. Is that right?

Nic (50:28)
to.

Cameron Eagans (50:38)
It looks the same. I don't know what they're using under the hood. Like my integration point is under a composer namespace, not a symphony one. So I'm assuming that it's probably a composer-specific thing.

Andy Giles (50:46)
Okay.

Okay. Interesting. Cool.

Nic (50:54)
Yeah.

Cameron Eagans (50:54)
but it

is very similar to the Symphony of Endispatcher.

Nic (50:57)
Yeah, it looks like Composer does use some symphony things, but it looks like they're all related to the console and process. I don't see that they're actually extending the event dispatcher at all from symphony, but maybe it's a dependency of one of the other dependencies that they're using. Who knows?

Andy Giles (51:12)
Cool.

Cameron Eagans (51:13)
Yeah, could be.

whole lot of,

use of these APIs, the capabilities are there.

Andy Giles (51:23)
Yeah, I started looking at the composer source code and then it's like almost like this weird rabbit hole of like how does composer use composer with ⁓ But yeah, anyway, so moving right along, know, I've got a lot of sites that I need to update to 2.0 and Obviously, you've got the new dock site, which is super helpful. What else should I be aware of? Like what are the big gotchas?

Nic (51:31)
you

Cameron Eagans (51:32)
Yeah.

For the most part, it should just work. You shouldn't really have to do a whole lot in terms of changing your patch definitions or anything like that. There's new stuff that you can sort of opt into. As an example, 1.x had the sort of compact patch definition where it was the description and the URL and that's about it.

In 2.0 you can have sort of an expanded definition where you have the title and the description, but you could also, if you wanted to, specify your own SHA sum for the patch. You can specify some extra information. There's a section in the docs about this, but you can say like...

the issue tracker URL where this thing came from. And that just gets attached to your patches, sort of extra metadata that gets stored in the log file. So you have like internal ticketing or whatever, can sort of say this patch came from this ticket. And then there was one other thing. ⁓ the patch depth. ⁓ yeah, so if you use like the patch utility.

Andy Giles (52:30)
Nice.

Nic (52:34)
Okay. Depth. Yeah, what is depth?

Andy Giles (52:43)
you

Cameron Eagans (52:43)
You can do like patch dash

p1 or dash p2 or whatever. That's the depth flag. basically what that does is it strips off leading components of the file path before applying the patch. So if your patch is changing something in like core modules system, a patch depth of three.

would be like I'm applying this relative to the root of the system module.

Nic (53:05)
Okay. Yep. Very cool.

Andy Giles (53:06)
I never read the man page and now I know how that works. always

just, you know, either apply a patch with git or if using the patch like p1, I just like, that's just what you use. I never actually delve into the docs there. So thanks for clarifying that. ⁓ Yeah. So the other thing, like I'll go ahead.

Cameron Eagans (53:21)
True thing. ⁓ So that was. ⁓

That was one of the things that actually went away in Composer patches too, is the depth guessing. So we use P1 all the time because that's what Git apply uses. Unless you specifically tell it to do something different. There's a like a utils class where there's a list of packages that have different depth values. So Drupal core uses P2 by default without you having to do anything. ⁓

Andy Giles (53:35)
Gotcha. you

Nic (53:47)
Okay.

Cameron Eagans (53:50)
And like other packages can go in and add to that list if they want to. You just open up a request. ⁓

Andy Giles (53:56)
Is that

P2 because it's in a web root typically, like all the modules and core and stuff is not in the root where your composer.json is?

Cameron Eagans (54:05)
It's an artifact of how Drupal started using Composer. So like that core directory is a subtree split. But the actual Drupal repository itself, like core is nested in a directory inside of that repository. So you need to strip off that sort of leading directory to get stuff applied relative to the root of the core directory. ⁓

Andy Giles (54:19)
Okay. Sure. Yep. Okay.

Cameron Eagans (54:30)
That's what most people were

Nic (54:30)
I'm learning.

Cameron Eagans (54:31)
doing in 1.x and it just kind of like just kind of worked because 1.x would guess which depth to use. But it would fail in situations where you were just like adding a file because that works at any p-value.

John (54:42)
I personally love the extra item there. I'm looking at the documentation right now and I'm like, extra, hold on a second. I can actually put a link to the Drupal issue in here, which previously I would just kind of extrapolate it from the path to the patch, which is sometimes very annoying.

But yeah, now being able to conclude that right in that patch definition is super helpful.

Cameron Eagans (55:09)
One thing I want to do maybe eventually, or maybe somebody will beat me to it is I think you can hook into an event that's like post patches resolve. So like we've already figured out all the patches that we're going to install. Right. And so I want to write up an event handler that we'll go through and look at all of the patches from Drupal.org.

Nic (55:10)
it

John (55:23)
. you

Cameron Eagans (55:32)
like try to parse out the issue number and then automatically append that information to the extra section in your patches.lock. So like doing that in an automated way is kind of difficult and I just haven't had time

to sit down and do it, but I think it's doable.

John (55:45)
That'd be cool. I also actually just had an idea like it would be cool if not to add more work, but if somebody in the community wanted to build this feature, like it'd be cool if it was able to kind of like, if you had that extra value in there, if it could say, Hey, I'll parse it. If the issue is fixed and this patch has been applied to the code base, like ask the user if they want to remove it. Right.

Nic (55:47)
That'd be fun.

John (56:10)
Cause that would like, I don't know. It would help me when I go to update a module and it's like, Nope, you can't update the module. And then I go, Oh, right. I have a patch. got to remove the patch and check to see if the patch has been applied, so on and so forth. In speaking of that, in speaking of that great idea, Cameron, I'm wondering, does Composer patches have a roadmap? Is there a 3.0 version kind of bubbling there somewhere? And if so, what's on the

Nic (56:21)
You You

Cameron Eagans (56:22)
Yeah, totally doable.

Well, based on how long 2.0 took to come out, I would be publishing 3.0 from the grave or some point in the next century or whatever. So I'm not planning

on a 3.0 right now. I don't really even have a roadmap for future releases in the 2.x series. It's more or less just what do people need? And I also need to sort of balance that with what can I maintain?

So that's part of the reason why we have the API capabilities in 2.0 is, you know, some features don't need to actually live in the core plugin. But as long as you have a way to do it, that's like, I feel like I'm sort of satisfying the bargain there.

Nic (57:14)
Yeah.

Andy Giles (57:16)
Okay. You

Nic (57:17)
Okay, and so it's BSD3, So fully open source is that.

Cameron Eagans (57:20)
Yes.

Yeah, do

Nic (57:24)
Accurate. And so if somebody wants to contribute, what's kind

of your preferred method? Is it kind of creating a fork on GitHub and adding a pull request for it? Should they open an issue to discuss it first? How do you want people to try to contribute back?

Cameron Eagans (57:38)
Yeah, issues are best. The best place to start, anyway. Let's talk about it first. It may be that the thing that you want to do is doable without changes to the plugin at all. ⁓ It might be you need to write a composer plugin or whatever. And that's something I can kind of get you pointed in the right direction on.

Nic (57:53)
Yeah.

Cameron Eagans (58:00)
But if it is an actual change to composer patches, like I'm certainly willing to talk about it and discuss how to approach it and whatever. And then yeah, a pull request is kind of the next step.

Nic (58:11)
Do you do paid support for people with more complex needs or?

Cameron Eagans (58:15)
I do. So that's mostly handled through GitHub sponsorship. You can also just email me and we can figure something out. But yeah, I'm happy to help if people need help.

Nic (58:20)
Okay.

Andy Giles (58:24)
Is that most of it?

Is that most of how you get funding for this is through the GitHub scholarship or do you have other funding sources that help support this? I it's obviously a critical tool for Drupal and we want to keep it around.

Cameron Eagans (58:37)
no, there's not really any funding for it. It's I don't, I don't even really do that much Drupal anymore. So, ⁓ or, or PHP for that matter. so yeah, I mean, there's not really any, any funding or official support or anything for it.

Andy Giles (58:42)
Yeah.

Nic (58:44)
really?

Andy Giles (58:50)
Just a passion.

Nice. That's Cool. Well, thank you again for that, for sure.

Cameron Eagans (58:51)
I mean, it's neat to maintain a big open source project. So like, I'm going to keep doing it as long as I can, but ultimately it's not really aligned with like my professional direction or anything anymore. So it's kind of when I have the time and energy to work on it.

Nic (58:54)
Yeah.

Which is fair enough.

John (59:08)
Awesome.

Yeah, I definitely, definitely echo that. Thank you. And again, sorry, it's taken so long to get you on the show, but Cameron, thank you for joining us.

Cameron Eagans (59:20)
Yeah, glad to be here. Thanks for having me.

Nic (59:22)
Do you have questions or feedback? You can reach out to TalkingDruple on the socials with the handle TalkingDruple or by email with show at talkingdruple.com. You can connect with our hosts and other listeners on Drupal Slack in the TalkingDruple channel.

John (59:34)
Do you want to be a guest on Talking Drupal or our new show TD Cafe? Click the guest request button in the sidebar at TalkingDrupal.com.

Nic (59:41)
You can promote your Drupal community event on TalkingDrupal. Learn more at talkingdrupal.com slash tdpromo.

John (59:47)
Get the Talking Drupal newsletter to learn more about our guest hosts, show news, upcoming shows, and much more. Sign up for the newsletter at talkingdrupal.com slash newsletter.

Nic (59:56)
And thank you patrons for supporting Talking Drupal. Your support is greatly appreciated. You can learn more about becoming a patron at talkingdrupal.com and choose become a patron.

John (1:00:06)
All right, before we let everybody go, Cameron, if folks wanted to get a hold of you, talk about composer patches or any of the other projects that you're involved in, how best could they do that?

Cameron Eagans (1:00:17)
You can send me an email that's linked from the About page on cwreagans.net or you can find me on Mastodon. Also on the About page on my website.

John (1:00:26)
Cool.

Awesome. Andy, what about you? There you go, Nick.

Andy Giles (1:00:32)
You can find me on drippyard.com or andyg5000.

Nic (1:00:38)
You can find me pretty much everywhere at Nicxvan, N-I-C-X-V-A-N.

John (1:00:43)
And I'm John Picozzi. can find me personally at picozzi.com at John Picozzi on all the socials and drupal.org. And if you want to learn more about EPAM, you can go to epam.com. Thanks a lot, everyone.

Nic (1:00:56)
And if you've enjoyed listening, we've enjoyed talking. See you guys next week.