 This is Core Conversations, Composing Drupal's Future. It's just going to be me, Larry, and Klausi. So we'll decide what we're going to do. Exactly. Awesome. That's the decision-making process. All right. I'm going to be surprised that it's not more interesting. Well, we're up against two really awesome sessions right now. Another composing session? No, there's Angie. Angie's doing Angie, Aquia, whatever, is. Upgrade your module to D8. Upgrade your module to D8. And there's the Be Hat Lab going on right now as well. Yeah, it's front-end package management. Yeah. I have no idea. Are you asking me to justify you leaving my session? Oh, no, no, no, no. Totally not. Yeah, no, I don't think so at all. So, OK, well, I am going to get started then. This is Composing Drupal's future. Look at that. It's got stuff in it. I probably should have filled in. I'm Chris Vanderwater. I'm with Commerce Guys. I'm a senior developer there. I am at Eclipse GC on Twitter. I'm also the Drupal 8 Blocks and Layout Initiative owner, commonly known as Scotch. I do a little bit of maintaining of C-Tools whenever I can get around to it, and a little bit of maintaining of my own module, Context Admin, when I feel like it. So those are just some quick about me. Welcome. I want to talk a little bit about the objectives that I have for this conversation, because what I'm suggesting here is kind of crazy to a certain degree, and kind of sane on the flip side of that coin. But at the same time, I think it's good to lay out some objectives that I would like to see both for the conversation and if ultimately we end up doing this for Drupal in general. So the things that I really want to hit here are componentization and what that means to me in terms of Drupal and PHP in general. Interoperability, both with our own components and with other components. And then what I hope that ultimately leads to, which is the ability to give us more influence in the greater PHP community through exporting our code and our culture to them, and ultimately our expertise. So let's talk a little bit about componentization here. Symphony has a definition for this, and I looked for a little while to find it. And so I'm just gonna read this to you. Symphony's definition of components is this. Symphony components implement common features needed to develop websites. They're the foundation of Symphony full stack framework, but they can also be used standalone even if you don't use the framework as they don't have any mandatory dependencies. That's a very interesting kind of mission statement almost for the code that they're building. And so I looked around and I said, well, does Drupal have one of these? And I didn't find one at first, so I made up my own. So that's where there's a question mark here. I said maybe Drupal components provide common features needed for a modern CMS. They provide the foundation of Drupal, but can be used standalone with limited dependencies. There is actually a definition for this if you go looking within Drupal component, which I happen to have open right here. So the official Drupal's statement of what a component is is this. Drupal components are independent libraries that do not depend on the rest of Drupal in order to function. I am reading from a readme in Drupal core, by the way. What are you doing? Mail's telling me I need to be doing stuff probably. Go away. Okay, that's what I get for not closing everything. Components may depend on other components, but that is discouraged. Components may not depend on, blah, blah, blah. You can read this. It's in, here, I'll show you where it is. It's in core lib Drupal component. Readme.txt, right? Suffice it to say we have one. And of course, why me? So, I kinda wonder what PHP's definition is for this. I couldn't find one. But I bet it's something having to do with this work standalone and you can just use it, right? Because that's what the rest of our good examples here are kind of getting at. So, let's talk a little bit about Drupal 7. We've kind of done this before. To a certain degree, includes were kind of components. Some of them were swappable. You could write your own include file that had all the exact same function names and then swap out certain things like, say, maybe session or there were a few of these. Password. Password was the more common one. I actually wrote a module to do that for you and was very scared when I stopped hashing passwords and just saved them clear text. Yeah, yeah. Modules are kind of sort of this idea, right? You know, at least if you think of it in terms of Drupal, when you go asking for a module, you say, I expect this self-contained bit of code. It may state that it has some dependencies on other stuff but it's gonna slot into the system that I'm choosing to use and it's just gonna work there. So this is conceptually not that different. So to a certain degree, we kind of invented this before PHP got around to it and I'll show how PHP's gotten around to it here. In Drupal 8, we have very consciously chosen to begin componentizing things. And so the real components live in Drupal component which was the read me I was just reading from and then there are extensions of those and some more standalone things like database TNG that live in Drupal core. And ultimately, I think we can probably start to really seriously componentize all of these things because what these encapsulate to some degree are a no assumptions feature component of a system like Drupal and then our Drupal core code is basically the Drupal assumptions layered on top of that. And that's actually kind of a valuable thing. What we haven't done is we haven't really begun replacing it with regard to modules. Modules are still modules are still modules. We have a .module file. The .module file can have hooks in it. More importantly, when you look at a module, modules can have classes in them and these classes can be componentized in the exact same way that code within core can be componentized. The problem is that they aren't abstracted enough to be reused. They exist within a Drupal module, so they are bound to Drupal. And as we've shown with a few interesting pieces that have gone into Drupal 8, that doesn't necessarily have to be the case. For example, date module doesn't really exist because we have a date component now. There may be a module that interfaces it to Drupal. I don't know, I think there probably is for fields and those sorts of things. But in terms of really beginning to adopt what the rest of PHP is doing, you look at Symphony and their bundles and they're not the only people doing this, but they're the one we're going to identify with the most. Symphony bundles are very, very close to being Drupal modules in many respects. Only they have some advantages we don't have, like being able to generate a class map because all of their bundles are inside of their composer documentation. So I'm standing up here asking a couple of questions and amongst them is, do we even need module files? In Drupal 8, the answer is yes because we haven't gotten rid of hooks. But in Drupal 9, maybe not. So let's talk a little bit about interoperability. If we didn't have any modules, how do we operate? Both with ourselves and with the rest of the world? Because we've done this for so long, that becomes a really important question to answer. And so the first step in doing this is to really begin conforming to a namespace-based class namespec, right? And we're doing that in Drupal 8. In fact, our modules are doing it now. If you open up a class that's inside of a module, that class has a full namespace based upon that module already in there. So views, for example, if you've ever looked at a views class of which there are many, they will have a namespace on them that tells you this came from views, right? I don't need to get too detailed with that. Just suffice it to say you can just look at any individual class and have a really good idea where it came from because they have independent naming mechanisms built in. And this is something that was developed outside of Drupal. We just adopted it. So when I start talking about componentization, this is what I'm talking about. These things, which are already namespace, they can't, by design, collide with anything that's not just named identical up at that very high level. And there are some interesting things to help you separate that apart, too. We can leverage symphonies of event dispatcher or something similar. Event dispatching is basically giving classes the ability to respond to hooks instead of having a dot module file that responds to hooks. And that's really compelling on a number of levels, especially because it means that every class in your library of classes could potentially respond to a given hook. It's not likely that it would. And only classes that implement certain interfaces can. But what it means is that a collection, which we think of as a module, could actually subscribe multiple times to the same event. We cannot do that in hooks right now. You have switch statements, and you have to follow logic and figure out what's going on. And we did a lot of things to mitigate that during the D8 cycle, but there's still plenty of it there. And a full-on adoption of the event dispatcher out of symphony gives us the ability to do away with dot module files, by and large. And it gives us the ability to really begin packaging up our individual software components in such a way that they could be run outside of Drupal, which brings me to my next point. By doing this, we set our code free. We begin to, when you look at our info files, which have become info yaml files, but whatever, they state their dependencies. If you look at a composer file, it states its dependencies. It's basically just a metadata wrapper that's most important job is to state its dependencies. That's what an info file really is, right? It's a metadata wrapper that tells you its dependencies. So you never end up with something you can't actually run. So I mean, in these terms, composer, PSR0, packages, which I haven't talked about at all, but I will, these replace something we invented almost a decade ago. And we adopted it most of the way for Drupal 8 if we adopted it all the way during the next cycle. We could find ourselves in a situation where we can actually begin to use our code on something that's not strictly Drupal. And so I asked the question, if database TNG were out in the wild and plugins were out in the wild and entities were out in the wild, and you could just pick one up, grab any of the additional Drupal dependencies it might have, and drop it into a non-Drupal project, would you? More importantly, if somebody not in the Drupal community found a full featured system that did what they wanted and it just happened to come from Drupal, would they use it? And if they did and had a problem with it, who would they call? Which is where we get to exporting our code and exporting our culture. I think it's a really important point that we make these easy to include. And luckily, between composer and packages, we can do that. For those of you who may not know, Packagist is a site that keeps track of various composer components. And composer leverages that site when fulfilling the requirements of those components. So if you've ever used something like Drush PM Download or DL or Drushmake, anything like that, it's actually more akin to Drushmake than it is anything else. Because you can have a single composer JSON file that says, I need these things. And then you run composer install. And it grabs all of those things. And anything in that that says, I need these things. It goes and it gets those. And it proceeds to do this until it has all of the various dependencies that are required. And then it dumps that all in a place that it knows about. And boom, you have all your code and you can begin developing. Yeah, that's what I just said. So these systems all leverage the class auto-loading and namespacing I was talking about earlier. Packagist, composer, gives you the actual code base. But it's pulling these code bases from all over. Some of this might come from GitHub. Some of it could come from Drupal.org. Some of it could come from a Git server that just happens to be public to the world. So long as it is, we can get it here. So it means that if it's easy to include, which these tools make, and the rest of PHP is using these tools, then when they find them, I think it will be natural for them to include. And so packages specifically can help you find out whether a namespace already exists. And you can create code in a different namespace. And people can begin browsing for it. It's like a module browser. But it's for all of PHP. Guzzles in their symphony components are in their doctrines in their aesthetics in there. Why aren't Drupal components in there? Right? Why are we the only people benefiting from our code? And of course, if people begin to include our projects in theirs, they will come looking for us. And they will probably begin contributing, at least to the projects they're using, if not to other projects that expand on it. Because if entities is dependent upon plug-in, and they find entities, and they find plug-ins, at some point they're probably going to want to contribute to both of those things something. So I've had the good fortune of picking Angie's brain a little bit on this. And the next two slides are really like, I put these there because I had a long conversation with her. And she had a lot of objections. And I think that they're really valid. So I'm just going to show my cards completely here, because I don't really want to be holding anything back. When we start discussing this, we're really talking about packaging core. Because the way we package core is completely different than how we package any install profile that exists on Drupal.org. It's completely different than how pretty much any Drupal project anywhere is packaged. And what we'd be talking about is basically a package standardization of sorts, which means we're going to have to write some serious tools. We're going to have to change the way we're doing things. It also means if we begin to take code and extract it out of Drupal and make it available to the rest of the world, that we have some serious problems with regard to our existing core gateways. I maintain to a certain degree that we already have this problem because we've included third party code. But the fact remains, I continue to use the plug-in system as my example, because from day one, we designed it to be able to live outside of Drupal core. And I have some really great examples of it doing so. But from a documentation perspective, if I were just in charge of that Git repository, I could technically do anything I want. I wouldn't, but I could. So if I didn't document stuff properly, or it weren't performant, or there were an accessibility issue, composing Drupal's future? Composing Drupal's future, or are you looking for the lab? H. Needless to say, the gateways exist for a reason. And we probably need to come up with a way to continue to conform with them, even if we begin abstracting code out. And if we have multiple Git repositories that the documentation people have to deal with, they're not going to be super happy with me. So we have some hurdles to get over here. In addition to this, I'd just like to point out that maintenance and ownership of the code base becomes a bit of a topic. And I just want to say, first of all, it's not about control. It's about iteration. If I have my way, and I got to separate plugins out from Drupal 8, that'd be like, let's say 1.0.0. By virtue of the fact that anyone on the planet is using that, I've kind of already given up control of it. To a certain degree, really, all I can do is to begin to fix bugs. I might be able to add new features so long as they don't break backward compatibility, but I can't go breaking something in there. Otherwise, I'll help break sleeves. What I can do is create a new branch and do a 2x while Drupal 8 runs on 1x. And if I find that I've hit the end of that lifecycle and I begin a 3x, and we get that to stable before Drupal 9 chips, I got a full iteration into the plugin system before Drupal 9 got out. That's a good thing, not a bad thing. By the same token, if it's stable enough and doesn't go anywhere, there's really no harm in just staying on 1x. So we have to begin thinking about long-term support releases, because that's essentially what these are. You look at the development lifetime of a Drupal release and a 1.0.0 code, a 1x code of something that we extract from Drupal, has to support Drupal 8 long-term. Because that's at least a three-year commitment, at least. Probably more like a five- or six-year commitment. I'm getting nods. So that's kind of where I'm at at this point. I'm hoping you all have some thoughts that you would like to share. One thing I want to clarify. Are you talking about taking stuff from Drupal Component and moving it out to develop in a separate repository? Or are you talking about what Symphony does, which is everything's developed in a single repository, but they do some git magic so that every commit, the components get pushed out to their own repositories that are read-only, and those are listed on packages. I think that that is an implementation detail. I'm not horribly swayed one way or the other. I think the big benefit of them being separate repositories means that you can literally put lieutenants in charge of them. I don't know whether we can do that with submodules. I'd say that's more the implementation detail. The main difference is if it's a common repository, then it follows our development cycle, which means we can still enforce all of the gates on that code. If it's a separate repository, then we can't enforce those gates. Whether that's good or bad is a separate debate. Right. So I think that that's kind of into the difficult problems side of this, that I don't really have answers for. I'm more interested in throwing out questions and seeing what the answers are three to six months from now to a certain degree, especially on the really like that stuff. I don't have answers to, right? And no one in here is a core maintainer. So, and I mean, they're the people who are gonna have the experience to know just exactly how much of a problem this sort of thing might be in their development cycle. But by the same token, I think it's worth discussing because the ultimate objective here has to be one of, like I said, it's not about control, it's about iteration. And I think this is true for Drupal Core as well. Because if we begin to componentize what we already have sitting there, and I say put lieutenants in charge of that, who are already like very invested in that code and can be trusted to maintain it for a given release, then what we end up with is a whole bunch of people who are taking care of a whole bunch of problems and keeping a unified API on the edges. And it turns Drupal into basically an interpretation of how those components should work together. It reduces the size of Drupal Core significantly, which means we can iterate a whole lot faster. People keep talking, oh, we want a one year development cycle, good luck. But I'm offering you something that in the long term might buy us that, right? In the long term, if we invest what it takes to begin abstracting these things out into standalone components that either provide a cohesive, this is what I do, or are a Drupal interpretation that extends that, we've greatly reduced the amount of code we have to maintain within Drupal Core while not really forfeiting any of the benefits of Drupal Core. So yes, it does bring about some specific objections with regard to how do we maintain this, how do we test it, how do we, but we might be able to get away with just nightly builds, pulling everything from everybody and know early and often whether somebody broke something, right? A lot of other systems do nightly builds across all of the stuff that they're working on. And I think we could probably put something very similar in place. I really thought what I proposed was more radical than this. I guess you were saying this is not something that could be done in total Drupal 9 cycle. But is there thought, maybe I'm totally wrong, but this is really like it's, the core packaging needs to change on Drupal or not an easy thing for any means. And the habits of core developers need to change to actually start running Composer install as part of their process. So they should probably be doing that at this point anyway. But it doesn't need a restructure of how, like what the layout of what Drupal would be anyhow because there's the Composer installers module and you can actually, you can still drop them into the same places. Basically so you could strip out modules as they exist now and forget about that, proving people what the benefits are of actually componentizing in a different way, which is like, hey, let's do how we always do and let's just strip all these out into separate modules, some packages, and then use Composer installer and drop them rigged where they always are. But now you can have people in charge of, basically people in charge of the intense of those modules, it's now up to them how they wanna start thinking differently and working differently and putting, separating their pieces out so that maybe people outside the Drupal community can use and it doesn't have to be a whole cohesive, let's move everything as a single unit. Right, I think we're gonna have to stage out the code that we can extract over a period of time because as you begin to abstract code, determining whether that's a cohesive piece that is useful is really, I mean, that takes a little bit of effort. You think like, let's take a user, for example. If there were a user class or interface or something like that that the entire PHP world could just say, we're using this, right? You would have user interoperability across like everybody's platform. Now it's not likely that that's going to happen but you begin actually considering that as you start to abstract our own user module out and you say, oh, we have session stuff. Are we gonna use symphony sessions? Are we gonna roll our own session that sits on top of the symphony components? What are we gonna do here? We have accounts and we have permissions and what's the difference between authentication and authorization and the list goes on and on and it's like that's a lot of work and I was only really talking about user, right? We didn't even talk about entity which is dependent upon. I guess it's just more so that. Or fields. That you can think about our order of operations. Is it that we make each of these components useful to everyone else and then think about changing how we package it and build it or is it that we just like without making it useful to anyone else at all in the get go, we can separate them into packages and then. I mean, that's what modules are to a certain degree. Let that fuel people to want to rebuild it in a different way and it can happen a lot sooner, I guess. But what's the difference between that and just maintaining the status quo? I think using a package manager really catalyzes a lot of changes that, and people don't, they don't get on board until they actually start using it. Right, so you're saying use composer but don't bother with making it work with anything but Drupal? Not yet and just assume that that would be driven by the fact that people see the benefits and they realize, oh, I can just separate this out into its own package. Sure, sure, I mean like to a certain degree that makes some sense, there is a hard problem that I haven't mentioned yet with regard to this and I've been thinking about it a little bit. But if you look at say, who in the room has installed symphony full stack? Like four people. So if you look at symphony full stack, they do this thing where they have bundles. Bundles are exactly what I'm talking about, right? And that's great, but from the perspective of like modules and the things we do with them, we do some really crazy crap with modules. Like we can segment the modules you're using per site. We can segment the modules you're using per profile. We can just drop them into a common spot. You can have the same module exist in all three of those places and we only use one. Depending upon the site you're running or the profile. Depending upon granularity. I mean, we support multi-site. So, you know, this is an interesting thing because like if you look at symphony setup, at least as far as I understand full stack thus far and I don't claim to be an expert there. They just have like a source dirt that you toss all this stuff into. And like the disadvantage is that everything I just said like totally isn't gonna work in that case. But the advantage of it is that they know exactly where all their classes are at all times. If you look at our module system and the way it works in Drupal 8 right now, the namespace classes we have access to are all added later. Composer doesn't know about them. And so we can't get the full benefit of things like building a class map and knowing where every single class is and not needing to do a file exist check on every single class before we load it. So, you know, there are little things like that and we probably have to make some concessions. But like those are the sort of things that are gonna ultimately end up being like the hairy implementation details of componentizing our code. Larry. So an earlier step that I think is more important. You can use Composer with a module today in Drupal 7. And I have written modules for Drupal 7 where most of the logic is in a standalone PHP library written for that project. It's up on packages. And then there's a Drupal module that just bridges to it. And that's it. So you're really suggesting like leveraging modules as adapters? Modules as a glue code to bring in a third-party library. Problem. Module. What's that? Which module does that have? Rotten Tomatoes. There's PHP library that does the actual talking to the Rotten Tomatoes API using Guzzle. I didn't actually do it the best way I could have in hindsight, but it does work. And then there's a Drupal module that does all right using that data, dump data from Rotten Tomatoes into Drupal. I'm doing exactly that for the Diablo 3 API right now. Sweet. Notice our priorities. Yes. But, and here's the problem. Core doesn't provide any way even in Drupal 8 for modules to pull in Composer libraries like that as a first-class operation. And the big challenge to doing so is Composer assumes you have shell access. Drupal cannot assume you have shell access to install a module. Right. That's a problem we need to solve. Even if we do nothing else in terms of sharing code with the rest of the world, that's a problem we need to solve to encourage module developers to write less Drupal-specific code. Yeah. I wish I had an answer to that, that was easy, but I don't. If anyone has one, please share it because I'd love to have one. I think there's, So, the way Composer works, you have a make file essentially, a Composer JSON file that specifies this is what this package is and here's its other dependencies and so forth. And you install packages with Composer by running a command line tool that downloads the files, puts them in the right place and sets up an auto loader that knows where all of them are. That's great if you have shell access to run that Composer command. Drupal by design lets you install a module by just FTPing it in with that's the only access you have. Or by going through the UI and just dropping a URL into a web form and it downloads the module for you and installs it using some weird, funky, screwy logic to keep it secure. Ish. Ish. Yeah, the ish is the problem because if I want to install that Rotten Tomatoes module then I can't really do so unless I have shell access because right now every module has its own Composer file. I have to go into that module directory and run Composer manually and then install the Composer auto load module. Actually, can't you just do that from core? And if you do that, doesn't it go down and look for composer.json files everywhere? No, with Drupal 8. I'm pretty sure I saw KMP demo exactly that. It recursively looks at Composer.json files referenced from the Composer.json file. But if you have. Okay. Yeah, if you today in Drupal 8 have the Composer.json file that ships with core and one down in a module somewhere and you run Composer install in the root directory that module is not even relevant. Okay. Because it's not being referenced from that global Composer file. So I would love to use Composer more but Drupal being at the top rather than being itself a library the way it is in a way Symphony would be an application framework I don't know how to get around these problems. Well, and I really want to. And you know, there are a couple other things that are worth mentioning here. Like the second Composer knows about your code. You can load it. Whether the module that it belongs to is turned on or not. Now we don't have this problem in Drupal 8 because as I said, module namespaces are added to the auto loader later. They aren't in Composer. But in a system where Composer is actually managing that which is what I'm proposing you could have code that you didn't have enabled. But you could say new and give it a class name and that would instantiate. And that's, I mean like on the one hand that's like OMG on the other hand it's like well it's a class that's in your library of code whether you have code that is actively executing it or not and appropriately dependency injecting it and all these other things that you would get by turning it on is a completely different discussion. But it's worth mentioning that that is a change. Like you can't do that in Drupal today. You can't say give me some class out of this disabled module. I mean you could I guess if you manually included the file but because that's what Composer's doing for you at that point is it knows where it exists whether it was turned on or not so it can manually include the file. Does that make sense? One other note the Drupal component directory exists exactly for this reason so that we could do the exact same split logic that Symphony's doing that was very deliberate and that's why that split exists for that purpose. And that is probably worth showing. I can take the blame for writing that read me file. Okay, which is why you knew about it. Let's see core lib Drupal. Why didn't I capitalize that? What in the world? Okay. Yeah actually I'll show you exactly what Larry's talking about. So this is the component library. You may not be able to see this. Maybe that's better. So we have like annotation, archiver, bridge, date, time, diff, discovery, and so on. Really like, excuse me for a moment. Peh, I think I committed. Okay, sorry. So yeah, that's great news for me. So yeah, so anything in here could ideally be separated out. I've been working towards getting the plugin system, the annotation system, and the utility system all separated out. And I know what my evening is going to consist of since that patch landed. But we could do that with any of these assuming that they've been kept pure and don't actually make calls to other Drupal classes or anything like that. And by and large, the coverage on making sure that doesn't happen in here has been pretty good. I think the people who have been heavily responsible for creating these directories have generally been consulted before patches went into them and they've reviewed them and said, no, you can't do that or change it to this or stuff like that. So by and large, I think that this is a really good first step for us. What upsets me and probably Larry is that, there's a lot more here in core. Amongst them, database, which is like almost perfectly usable outside of Drupal core. It needs a little bit of love to migrate over to component, but there are a lot of things in here that to some degree could be seriously considered for having stuff abstracted out of them and put into component. And what you see here is, you'll see there is actually a plugin directory here. And the plugin directory in here is going to extend a whole bunch of things that were provided by component and they're gonna provide a bunch of Drupal assumptions on top of them. That's pretty like sustainable way to go about build a component, add Drupal's assumptions, build a component, add Drupal's assumptions. It's worked very well in the couple of places that we've used it thus far. And I think there's probably a lot of code sitting inside of core that just was not, that the people doing it at the time were either under too big of a deadline to bother abstracting it to that level or didn't feel comfortable trying to conform to it. I don't know because I wasn't involved in a lot of these, but there are a lot of these that could probably ultimately move into the component library given a bit of effort. And you can see how much code we've already done in Drupal 8 that is moving this direction before we've even touched modules. And if I go up here, like we still have an includes directory with a whole bunch of stuff in it. And much of this ultimately, not all of it probably, but a lot of it ultimately wants to be moving into that class based componentized architecture that is reusable. I find myself being interested in what is in utility. How many lines is this? Oh, it's 25. So someone file an issue to replace all Drupal var exports with static calls to variable export. And we can get rid of this file, right? I wonder why this exists. But there's gonna be quite a bit of that sort of stuff because we've just got some cruft from trying to build out these sorts of systems. Let's see, I said I was going to, that's in core vendor, right? Yeah. So these are all of the real legitimate components we actually have in Drupal today. And, well, that's not entirely true. I've got that on a separate tab. Yay. These right here are all the components that we actually have within Drupal 8 today. So we have, I didn't know I could do that in them. There we go. So we have a bunch of symphony stuff. And then we have twig, of course, and doctrine and guzzle and ascetic, some stuff from symphony CMF and so on. So when I look here, this directory was generated directly in response to the file we just looked at. And so, you know, we have a symphony directory. And in the symphony directory we have class loader and debug and we're in fact, we're gonna have a couple of things in here that aren't in that require statement because they were subsequently required by other symphony components. So interesting things there. But what Larry was talking about was that if we look in here, there's an autoload PHP, right? And so I can look at that. And this is a generated file. We are generating PHP and Drupal 8. And this is just returning this generated class as static method gitloader. And so if we go into Composer, you're gonna find that we have a number of PHP files here that have been generated. And so the one it was looking at was autoload real, which has that crazy class name again, and it's gonna have the gitloader, which does all of this sort of stuff. But most importantly, we have this namespaces dir, which actually knows where all your classes for a particular namespace live. That's really cool. You wanna see something cooler? This is a class map of every class that exists within any of our vendors. It knows exactly where they live. And so when you ask for a vendor class name, it doesn't even have to do a file exists check on these. It already verified there there. It just loads the file and hands you the class. I'm not even out of the Ds yet. It's long. I'm like 257 lines in. It is 2,286 lines long. Right, so there are a lot of classes in here. If you think of those each being as one class for one line, which is what it is. So that's not including any of the modules classes. No module classes in here. So we don't get the benefit of them being in the class map, which is exactly one of the benefits we would get from adopting this sort of a strategy. So let's see, why does that keep coming up? We've got about 15 more minutes, I think. Anybody have any additional comments they wanna toss out? Just seeing that class map, I think we removed the ability to disable modules nine, Drupal eight. So it should be easier for us to build a class map, right? Well, we still have the problem if we don't actually know where the class exists, like where the module exists, because there are like a dozen different places that technically can exist. We know and the class maps only for your code base, not for your site. If we can figure out how to build a class map per site, then we might be able to get away with that. Exactly, site is actually what I meant. Yeah, that's true. I'm just gonna troll you. Okay. Licensing, discuss. Oh! Anybody else? So an awful lot of the code that we have included is MIT, right? Yeah. Some of it's MIT, some of it's BSD. Some of it's MIT, some of it's BSD. All of it's dual-licensed GPL, though, for us, isn't it? No? Okay. I have two. Yeah. But some of it is. Like they did for Symphony, didn't they? No? Symphony's straight up MIT. Okay. So yeah, there's a war raging and we are caught in the middle. And I have no clue who's site I'm on. So, you know, I think it's one of those things where, you know, I've thought about this a lot with plugins and plugins was birthed out of Drupal 8. And even if I thought, hey, MIT's great, which I'm not sure I do, but supposing I did. I don't think I can likely ever make that MIT. You have to ask me. Right. And CHX is probably not on board, which is fine, right? I mean, like, you know that going in. You say, okay, we're building stuff for Drupal. It's GPL 2+, so I know. Oh, that's actually another thing. I've wondered for a long time whether we were, you know, two or two plus or whatever. Yeah, edit it anyway. Hey, look at that. Right. Anyway, I think at the end of the day, you know, Drupal components are probably gonna need to be GPL 2+, right? Like, that's just what makes sense. And if we end up getting to a point where modules go away and we're adopting this more componentized frameworky approach, then we may find ourselves with a mixture of code on any given site beyond what's already defined for Drupal 8, right? We may find that, you know, it's not like the need for Drupal.org goes away and all of the sort of code maintenance that we've done there, because that's still very valuable. And I think that, you know, we're going to continue hosting things there and those things. Obviously, you're going to continue to be GPL because we strictly say if you're uploading it to our Git server, it's GPL 2+, right? I mean, that's what you agree to. So anybody who continues to think of what they're doing as being Drupal is just gonna continue to use that license. And anybody who decides to go out onto GitHub or, you know, Bitbucket or I don't know where, like they're gonna have to actually make that decision for themselves. I'm not sure it actually ends up affecting us a whole lot because I think, you know, that that should probably sail the decade or go or something, right? Unless we decide to just redo everything as three, you know, there's not a lot of a licensing discussion to have around Drupal-specific components. We're abstracting them out of Drupal already. How much effort would it be to go around and find every single person who's to blame for that code before we abstracted it into a component and then get them to agree to something else? No, it's GPL 2+. I know the licensing session is somewhere else, but does, my impression was that if we don't need to store the other external libraries, it doesn't matter what they are. So if we're only storing the composer files, doesn't that get around it? Or does it, does anyone know when we build it, we host a tarball with the build version? Is that technically against? You deserve this, Larry. So, MIT and BST license code are non-copy left licenses, they're permissive licenses. So technically speaking, it is legal for us to redistribute that code under the GPL if you wanted to. We still have the MIT copyright statements that they come with and our license file says, includes these other libraries under their own licenses. So, if you put a gun to my head, I couldn't actually tell you if technically speaking, you're getting them under MIT or GPL when you download from Drupal.org, I will tell you it doesn't actually matter to anyone who's not even more of a pedant than I am and that's saying great deal. The bigger question is more if Drupal starts breaking out our code into components, either the ones we have now or if we start writing new ones in the future, do we think about saying, hey, this new components we are about to write, we want to make under MIT or LGPL or something so that it can be used by more people? Maybe, maybe not, you'll find very loud, very angry people on both sides of that question, but if we start developing any of these outside of the existing Drupal repository, that question becomes a valid question to ask. Yeah, I mean to a certain degree, this is a holy war and I, you know. That's why I said I'm trolling you by asking. Right, yeah. And I am apathetic and I am not sure I have a God in this war. So, you know, yeah, I guess to a certain degree, I can see both sides of it. You know, you just have to figure out which one you think is short-sighted and go with the other. I think the easy answer for right now, the easy step we can take is throw a bunch of composer JSON files into all of the Drupal component libraries and do the same kind of split symphony does that doesn't take any effort at all, doesn't change our development process in the slightest, but still gets the code out somewhere. Yeah, I think that that's a really good discussion to have offline because I was intending on just creating my own repos and tossing composer JSONs in there and just keeping those repos up to date with Drupal core. Let's just file a patch against the core and yell at trees a lot. I'm okay with that. I guess we documented that. So yeah, any other questions at this point? We have about 10 more minutes. So I mean, you can troll me further. We can end early and you can go seeking coffee. I can stand up here and show you plugins. I mean, we could do a whole bunch of things. Modules would need a whole lot more effort. It's not, it like, there are implications with regard to namespacing and other stuff there. No, it doesn't, it drops, can I, like, can I say? Yeah, there's a project called composer installers and it's basically someone creating something to allow composer to allow you to drop things like Drupal modules into place and drop things like type three, whatever they're called, plugins, type three. So it's for like, this one installers repo helps you resolve this problem for like pretty much every framework out there. Interesting, I know nothing of it but I'm super interested to see it. It can be like a zero effort, like this can just everything be turned into components. And sorry, that's what I was talking about before when I was saying like we could just split it and not rearchitect anything and just let that incentivize the change in how we think about the modules. Okay. The problem there is again the how do you install it without a command line? If we install all of our modules by telling people, hey, go to the composer JSON file and the root directory, add a line to it for the module you want to use and rerun composer install, then what you're describing would work wonderfully. Well, yeah, but this- We can't actually say that, yeah. This actually gives you the ability to use composer in order to compose your modules together, but like just because we added composer.json files to all of the repos for modules does not mean that Drush DL stops working or any of our other solutions, right? True, it's more a matter of just adding that composer.json file doesn't actually have benefit, I think. I guess that depends upon how robust this solution is, because if I can do something like say, I want you to get this module and I want you to put it in this directory that's the module's dir inside, the contrib dir inside of the module's dir inside of, you know, the open atrium profile, then I could begin building class maps off of that data. If we could actually use, you know, the composer JSON file and replace Drush make with, hey, go edit the JSON file in Drupal root and say that's not hacking core, then that might be a very interesting thing to do. I don't know if that would work or not. I guess there are just a lot of really interesting things that could be done at this point. I was completely unaware of this, but this opens up a lot of interesting ideas. Because it's right now like the installer's project, composer installs, isn't very, I'm not sure if this is on. It isn't very robust. Talk more directly into it. Oh, gotcha. There you go. I don't think it's very robust and it pretty much only takes one install path and no one's really been like the maintainer's doesn't use it. Well then we need to commit an upstream patch, I mean. Yeah, yeah, so right now it could work if we're saying, hey, we just wanna treat core modules like this, we're gonna test out this approach, we're using composer and core already, like contrib would be a whole, you know, we need to fix up the installer's thing and make it so it could actually have two different modules, directories that it can drop into. Anyway, yeah. Okay, cool. Well, I'm gonna let you all go like five minutes early. So thank you for coming and I appreciate it. Oh, oh, and please tell them I did a good job. Oh, this is sprinting. This is, what did you think? Oh, look at that, it's got animations. All right, yeah. So I guess I do have a couple more minutes. So yes, please tell them I did a good job, go take the survey, I could use the karma and then there is a sprint on Friday. So I was asked to tell you all this and I will happily do so because you should absolutely be at the sprint on Friday. We'll be doing lots and lots of stuff. We have tasks for every skill set, mentors available for new contributors. I'm not gonna do any more of the sales pitch, you all know it.