 Yes. Well, if you're here on time, you're important, so my book. Okay. So we're all here for using subtree splits to spread Drupal into everything, which this has actually expanded a little bit. But I'm going to be talking only about Drupal 8 and Drupal.org. I'm not going to be talking about Drupal 7. I know quite a bit about it, but that's a whole different presentation. So my name is David Barrett. I'm David W. Barrett on Drupal.org. So if you want to Drupal, greet me, feel free. I'm a software engineer for Gulf Channel, who sponsored my trip here. So I'll put their logo up here. This session came out of an issue I started for the Drupal.org infrastructure team, and whenever you're creating issues for them, be careful what you wish for because they might email you and ask you to speak in front of a bunch of people. So I need to give a little bit of clarification. Because every other session you've probably gone to, they refer to Drupal. They're talking about the entire Git repository, or they're talking about the tar ballers that you can download. But I'm going to make a little bit of a clarification, just to make our lives easier, that when I talk about Drupal, I'm talking about everything except for what's in the core folder. When I talk about Drupal Core, I'm talking about everything in the core folder. So it's just going to make our lives easier. Otherwise, it's going to get way too confusing too quickly. So I'm also going to talk to you, like you don't know anything about Composer. So if you do a lot about it, like many people I see in here, that's fine. But if you've used or heard of any of these other dependency management systems, like Node Package Manager, or Bauer, or Bundler, this is a very similar conversation. But if you haven't heard of them, it's okay. Because we do dependency management in Drupal, and we've actually done it for a very, very long time, as long as I can remember at least. So I just took this example from the module info example, but the really neat widget, and it has two dependencies, views, and panels, and everyone has tried to install module, and it needs some dependency, and you have to go find it and download it. But that's really the magic of Drupal module development. So I don't have to rewrite the entity API every time I'm going to use it, I can just depend on it. And I think that's really, this is going to sound really nerdy, but I think that's one of the greatest features that Drupal has that other systems do not. Or they don't implement it nearly as well as we do. And it's been relatively unchanged for quite a long time, too. But a lot of people will talk about how composers just like Drushmake, and I've never used Drushmake, so I don't know. So for me, I think of modules. Okay, so we already talked about composer. Composer is a tool for dependency management in PHP, so it's way more generic than just Drupal modules or just WordPress plugins or whatever dependency management tool you want to use. It can be used for PHP libraries. It can actually, there's plugins to use it for other JavaScript libraries and things like that. But I would argue that composer, while it's written in PHP and it's really for PHP, it's probably one of the better dependency management systems of any of them that I've seen. And I can get to more of that why if you want to know later. So I'm going to kind of split this up because, and I came up with these terms, because it's going to make it easier to understand these different Drupal.org issues that we're asking of the infrastructure team and into consumers and providers and sometimes both. So I consider, if we go back to this Drupal module example, this module is consuming views and panels, but every module is also a provider because any module can depend on yours. So in this case, we have a module that is a provider and a consumer. Does this make sense to everyone? Okay, so we're good on the definitions. Okay, but in our world of composer, consumers are just projects that consume libraries via Composer. And so I'm going to show you what this looks like in a very easy, simple example. If you were to create, just put in a folder, a composer.json file and add, you just, it's pretty basic syntax you require and there's a namespace, which is Guzzle HTTP and Guzzle, which if you haven't used the Guzzle library before, it's Phenomenal Curl Rapper for handling HTTP requests with PHP, it's a lifesaver. So I highly recommend it. It's actually one of the Drupal dependencies. So you can go ahead and start using this now if you wanted to. And I do. But, and we want any version in the 5.0 series. So that can be 5, 1, 5, 2, any of those. Okay, so and here's a pro tip for you if you don't want to mess with editing JSON at all. You can generate or update an existing composer file by just running composer require, the same package again, and the same version constraint. And where it gets all of this data from is, or where I got this from is from a website called Packagist, it's package.org. It's very similar to how we have a repository of, you know, thousands of modules. They have thousands of PHP libraries available and they have the versions for them and it's very similar to the way we handle modules too. And so, back to our composer.json file, the way we would get guzzle is by just running composer install. And then we, the magic happens. And for me, these dependencies were loaded from cache but if you look, like, a lot more than just guzzle was installed. And this is the nice magical thing about composer is that it's recursive and it downloads all your dependencies for you. So you don't have to go looking for this module's dependency and then another module's dependency on and on down the rabbit hole. It does all of that for you. And so, for instance, guzzle required a library called ring PHP and ring PHP require a library called promise and on and on. And it goes backwards up the tree. And for me, I had already done this when I ran this so it was loaded from cache. I didn't even have to go out to the web to find it anymore. But I believe every time it checks any packages just to make sure that nothing's been changed. Okay, so after I run that, I now have other stuff. I have a composer.lock file and I'll talk about that in a vendor directory. And vendor directory is actually where all of guzzle is and all of those other dependencies. But let's first talk about the lock file. So the lock file is a JSON file that is auto-generated by composer and you don't ever need to touch it for the most part. Unless you have git conflicts, that would be the only reason. But if you notice something, it has a specific version. So just like in my output on the console, it says 5.2.0 and I have a specific git commit hash that was given to me. And what will happen is if someone downloads my repository and they run composer install, it will, the most part will ignore that composer JSON file that we created and it will only look at this lock file. And the advantage in that is that all of the people you share your repository with will have the exact same version of the dependencies. Yay, we don't have to deal with mismatch dependencies. So that leads to the question of why have the vendor directory at all? You could just remove that from your repository. Everyone will run composer install and get the exact same version of the dependencies. You could do this on a remote server. I've done that before too. And it works pretty much beautifully. I've had really any issues. You could have your test bot run composer install and I'll get more into that. But this is actually recommended by the guys that made composer that you would just remove it from your repository. And this is how you would use that library now. And you would just require, I forgot to mention this, but composer also because it's so lovely with PHP also includes a PSR0 and PSR4 autoloader. So you just require the autoloader and then you can just start using the library immediately. And obviously all of the dependencies will be loaded as well. And if you look at the eight repo there's a file called autoload.php and you'll see where we're requiring the composer autoloader. And that's how we're loading all of the outside dependencies. So when we talk about getting off the island, well in my humble opinion, composer pretty much single-handedly did this for us. And I could not fit all of our dependencies on a single slide. So I just picked some to throw up there. But there are a lot. So if you open core composer.json, you'll see all of them. There's symphony components, there's PHP unit, there's a bunch of stuff. And that's how we're managing all of that. So I'm gonna start going through these proposals that are on, some are on Drupal.org and they have issues. Some are, I can just see them coming. So they're in David Barrett's head and probably other people's heads. So I'll kind of explain those and what we're going for. So this is the first one, which is remove the external dependencies from the core repo and let composer manage the dependencies instead. A lot of people, including myself, want this one to pretty much go first because this makes our life on all the other issues so much easier. And the last time I counted, there's 15 megabytes or so of dependencies in the vendor directory. So if you wanna do things like move the vendor directory or update dependencies, they are huge patches. And it's really hard to wade through that and make sure nothing else has changed. And if we remove the vendor directory completely, the patches are much smaller. There's just changes to composer.json and composer.lock. Obviously that will require some work from the info team because there's two systems that we'd need to be updated. The packaging script that takes Drupal in terms of into that zip and that tarbol, it would need to be updated to CD into core and rank composer install. And also what the test bot would have to do this every time before. This sounds crazy, but it's actually exactly what Symphony and Larvel and Guzzle and everyone else that provides tarbols and zip files does. We're actually pretty unique in having our vendor directory in the repository. I can't think of another major project that does. We've made aware of this one, which is to move PHPUnitMink to RequireDev, that's the title of it, but there's other Dev dependencies. And I'll show you what this looks like. Basically there's a special place rather than the requirements, which are the requirements of your project, the dependencies of your projects, there's development requirements, which could be PHPUnit, Bing, Behat, it could be all kinds of things. And so these things are things that you want in development, that you want in contribution, but you don't necessarily need them for the actual running of Drupal. I think this would be really helpful for a lot of reasons. First of all, we can include development dependencies that don't have to go into Drupal. So there's more tools and things that we could use. We could update them more often. And also, it makes Drupal smaller for most users. It makes it smaller on their server and it makes also the zip and the tarball smaller, so there's less bandwidth being used. And this is the change that would have to be made there, which is just to the packaging script, not to the testing bot, but basically to CD into core, Composer and so forth, we'd add the no dev flag, which basically skips all those required dev dependencies. And the informative that one of the biggest reasons why they made Drush able to install on a per repo basis, you don't actually have to install it globally anymore. That's pretty new. Is that they could get all the Drupal contributors on the same version of Drush. And the way that would look is it would look something like this. So we would require dev Drush. And this is nice because we're not including Drush in every single installed Drupal. We're only including it for the people who want to develop with Drupal. And they're doing this explicitly. That would reduce a lot of the, there seems to be, or what they informed me of was there's a lot of, this doesn't work right through Drush and there's just a lot of mismatching of versions with Drush, just like you would have with PHP unit. Because you can install PHP unit globally, but we've included with Drupal so it makes all the testing work a lot better. Okay, so I'm gonna talk about providers now. And this is when a package, typically a library but doesn't have to be, that can be consumed by another package or project. So how do you make something a provider? It's really easy. You just give it a name. I took this name from the Gezzle project so this is exactly how there shows up and this is how I'm able to consume it. But to be fair, the packages.org website also requires a description. So we'll give a description as well. So this is what the core composer.json looks like. We have a name, a description and a type. And typically that type is a library and by default that's what it is. We actually made this up but it's something other than a library. And we couldn't think of some other bucket that Drupal fit in so it became its own thing. But this gives people a way to kind of come to our island right, because it's great here. We have pinnacleadas and you know. So in a lot of the times we're talking about people we're talking about us getting off our island and it's like maybe our island's not so bad, you know? So that's how that works. You're probably asking yourself why would you ever want to do that? Why would you ever want to consume Drupal? It seems like a lot, but we'll get to that. And this is what that would look like. If you did want to do that, it would look like you would require Drupal core and something in the 8.0 series. And if you look at the root in our 8.0 repository, that's exactly what you'll see. Okay, so, but I forgot to mention this. If you installed it just like this, as I described before, what Composer would do is it would put it in the vendor directory, just like Guzzle, right? Because that's where everything goes, the vendor. But Drupal doesn't work in vendor. So there's this nice little plugin that's maintained by the Composer guys that what I described, a Composer plugin that installs packages of a specific type in a specific directory. So they have all of these types defined, and like they have Drupal module, they have WordPress plugin, they have a bunch of other ones, and it will install those where they need to go. So we worked with them to get Drupal core supported, so we'll dump it into the core directory. So what that looks like is you just require the Composer installer's version, and we need at least that version is what we're saying, which that's when they added Drupal core support, and that will install it in the core directory where we need it to go. So it's a really best practice to give every Composer file a name. I do this just for semantic reasons, but you may share it once in a blue moon, but I do this anyways. But there's a special type called project, and that means that this is a project, it's not a library, it's not Drupal core, it's project. And there are some special commands that work with projects, but basically the gist of it is that it's a starting point, is what the ones you see shared. So if you see type project, they usually intend this to be a starting point, but it could also refer to your own project. So this is some example of what's kind of happening, and why I gave that clarification at the beginning, was that you have projects, which are starting points that require frameworks. And so symphony standard requires symphony, letter val requires letter val framework for us, and maybe these naming conventions are bad, don't know what else to call them yet, Drupal requires Drupal core. And if you look again in the root composer.json file, you'll see that it's a type project, it's a starting point. Okay, so this is proposal number four, is to permanently split Drupal and Drupal core to separate repositories. That would make us like symphony, like several other projects, but that's a lot of work. And I think myself and a lot of other people realized how much work that was, because it basically required that every patch that's out there would have to be rewritten to basically move down one directory, instead of being core it would be root. So probably not gonna happen for a long time, is what we came up with. So the next one, this is the reason why we're all here, is number five which is create and maintain a subtree split of Drupal core. I'll go into more detail about this. But if you look at symphonies.github, github.com slash symphony, you'll see all of these repositories that are marked read only. And what they are is they're symphony components that are in the symphony repository, but they used to get to, and they automate this process to create subtree splits of these components. And the reason they do that is because you can now consume these components with Composer without having to take all of symphony, okay? And that's actually why we're able to use those components. If they didn't do that, then we wouldn't have them. Because if you don't know this, we're not using all of symphony, we're just using specific components. So if you go on to packages, this is what packages looks like, Jury's actually has an account now. Yay. And there are two, we have two packages. One is Drupal Drupal, which is the root of Drupal, the project. And the other one, the big one, is Drupal core. And this is actually a subtree split of Drupal core. It's maintained, and I'm gonna put off this one by T. Stoykler. And so this is what the repository looks like. It's on github. It's obviously not being maintained by Drupal.org. I think he doesn't see a tree split every time there's a release on his laptop. So this is something that we would like done because if I go back here, I mean, we've installed it 2300 times just off of this little test subtree split. And I think that this is only gonna expand. So keeping up with that and Drupal.org maintaining that, I think is a huge win. Making it more of an automated process would be huge. And I don't think it needs to be every commit. I'm not really sure what Symphony does. But even if it's every release, that would be huge, but probably like nightly every release. I know it takes a long time to create those splits. So I think that's every time it's not loaded from cache. This is what I understand. But yeah, it's a little iffy. I'll get to another. I think it's a little, probably a little inflated, but. Okay, so this is number six, which is to split each component into a read-only repository like I was talking about. A lot of people don't know this, but if you go into core lib Drupal component, this is a segment of the readme, but there are 16 components that are ready to be shared. And I say ready, they're beta like Drupal beta is, but they can be shared and they could be included in other libraries or other CMSs, for instance. Like it's crazy to think like we use symphony components when symphony could use our components or WordPress could use our components. Like how great would that be? WordPress is built on Drupal. But to show how crazy this is, like these are the top most popular installed packages from packages. So I don't know how they come up with this data, but several of these are symphony components that are just subtree splits of their repository that are decoupled components. So if you look at the top one, the top symphony component, I mean this is the symphony event dispatcher which has been one of our dependencies. And I mean it's been installed like 10 million times. So it's kind of happened, but if you look at a lot of libraries you'll see symphony components in there or they'll be requiring libraries that require symphony components. So let's talk about Contra. And this is where it gets really hairy. Okay, so back to my widget module that I created. Let's say that I wanted to work with the Twitter API. And if anyone's worked with OAuth 1, it's not fun. But there's this great plugin for a Guzzle called the OAuth Subscriber. And it helps you make OAuth 1 request. And I'd highly recommend it because it works well for me. But if I wanna require this in my module, I would probably just put this in Composer, right? That'd make sense. I mean I can't include it because Drupal.org doesn't allow that. So okay, so I'm gonna put it in there. So how do my users load it? Well, in Drupal 7 and a little bit in Drupal 8, they would use a module called ComposerManager. And this gets recommended a lot. And I think there's a little bit of confusion about what it does. But what it does is it takes all of your modules, Composer files, and it generates one, a single one, off of all of those. So it would take that OAuth Subscriber and put it in your root, composer.json file. Which worked pretty well in Drupal 7. I'm kinda weary that it's not gonna work in Drupal 8 because we already are using Composer. So I think that's where it gets a little hairy. But it gets really hairy when you try to, when you wanna manually edit something. Like if you wanna manually edit your root composer to add a custom library or to add patches or something like that, obviously the generated file gets overwritten. So that can get a little hairy. So what's the alternative? Well, you just load the whole module, right? If I load the whole module, Composer will download the module, put it in the right place with Composer Installers, and then it will also download my dependencies for my module. And if you notice the version number looks really funny. That's because the 8.x-1.0 version numbers that we use in Contrib are not composer compatible. And it only works with the WXYZ version numbers. So four digits with dots in between them. And I've talked to them about making some sort of plugin that would interpret other version numbers, but it doesn't seem like that's gonna happen. So, but to get around that, the Drupal Composer community, basically they took packages, which is an open source project, and they forked it and it's going to look like this. It doesn't yet, but it is up there and it does work. And basically every Drupal module is on there and they generate a composer.json file essentially for each module that has the module's dependencies and they've also translated the version numbers. So the version number I used is what is ready for from, it comes from this website. So I highly recommend this too. This is what this would look like adding it. So you just add the repository, it's type composer and that's their URL. And it will, whenever you load a Drupal module, it will go here first before it looks at the official packages. So the webflow informed me of a issue which was that there are no web hooks for releases on Drupal modules. So there's no real way of knowing when someone releases something other than going and checking and that causes a lot of strain. Also there, I'd have to get with him with exactly why this is, but there's some data that they're actually scraping off the page rather than using the APIs and I think it's because some of it's not available through the APIs. So some web hooks would be nice and some better APIs and for Drupal.org. And also the official packages supports web hooks as well. So we've been talking about the Drupal package and the Drupal core. They don't stay up to date very well in packages because we're not submitting a web hook to them yet. Okay, this is number seven. Instead of translating the version numbers, what we could do, and this is a huge issue if you wanna look this up, it would take you forever to read, but switching to semantic versioning for Drupal contract extensions like modules. So that way it follows the same logic that Drupal core does. Makes perfect sense. I think it would be great for the community not technically a composer requirement because we have Drupal packages so I bowed out of that one, but I think that would be immensely helpful. It would also be a huge amount of work for the Drupal infrastructure team. Oops. So number eight is to move this packages that we're running, which I think is right now it's being hosted, John's donating the hosting for it, but if we move this to Drupal.org, then it can be officially used, it can be put in our root composer.json, we can better use it in documentation, we can kind of direct more traffic there when people wanna use modules with composer. The last one, and this gets another hairy one is allow contract developers to define subfolders, should be anything, modules or libraries that should have subtree splits created for them by Drupal.org. And we already see, if you download a module, it has subfolders or it has submodules rather, and those could be subtree split out, which would be nice, right? Because you don't have to like load the entire module, you just need that submodule, but also libraries and doing components like Drupal core does would be huge and automating that process would also be huge because this keeps people kind of on Drupal.org, it keeps us in our infrastructure and people are looking on our website for these libraries and components that would be fantastic. I think it would also help Drupal.contrib become more library focused rather than this module. It would become more of a module first design. If you wanna look at a good example of this, which they kind of moved away from Drupal.org because it didn't suit their needs, was the 8.0 version of commerce because they went library first and they also, all their submodules are loaded with Composer as well. So they're gonna run into this problem because what happens when someone just wants to install their module without Composer, and that's gonna become an issue and there's been a lot of conversations about whether we replace the whole Drupal like a module system with Composer or whether it's possible to create a user interface for that. And so that's still ongoing, but basically, as far as I know, the Composer kind of group has kind of reached an end of what we can do for Drupal 8.0 without infrastructure's involvement because most of the things like I talked about, it really requires infrastructure, so. And I think that's it, so if you have any questions, comments or you can now hurdle your insults. Thank you for our speaking, but all of the proposals involves having the entire Drupal community to drastically change the way everything is structured. So do we have any plans to push it that way? Because one thing I can think of is that since Drupal is an open source community and Dries and many of the Drupal community members have been pushing, saying that there should be sponsorship from corporations, shouldn't companies like the Golf Channel or NBC be supporting some of the development board to push the structure to be more packages rather than just Drupal? Yeah, you asked a lot of great questions. Let me see if I can get them all. Well, first of all, I do recognize, and this is a huge discussion, because this is kind of a matter of opinion, but data says something else. The opinion is that, well, everybody should just use Composer and use the command line. And data says that that's not the case. The minority actually uses Drosch or the command line, the majority just download the zip and install Drupal that way. So I think there's a lot of work that needs to be done to kind of maintain that compatibility with that. As far as corporate contributions, I don't know if I'm the person to answer that question, but I know that it's a lot of work. And it's something that everyone's gonna kind of have to help figure out before contra modules can effectively use outside libraries in Drupal 8, because I don't know how exactly that's gonna happen unless they use Composer. So that's kind of my fears that there's gonna be all these modules that are out there that require third-party libraries, and there's gonna be a lot of people who are just like, I don't know how to do that, a lot of site builders. So. Thank you. You're welcome. Yes, hi. I just need a little clarification. So you did say that you could use Composer to install Drupal, like you wouldn't just go into the vendor directory, did you not? Correct. Okay, good. Yeah, I'll look at the notes. I'll figure it out from there. Well, so are you suggesting that the module, the contra modules go into the vendor directory? No, Composer installers will put them in the modules directory for you. So Composer installers will, it'll put core in the right directory, it'll put your modules in the right directory, so that'll all happen for you. You can actually customize it if you want it, like if you wanted it in like profiles, in a profile, if you wanted that, but otherwise I think it just goes in modules slash, which is where the contra modules go in Drupal, yeah. Right, so does that require modifications on my part to get that to work? No, that only requires depending on Composer installers. That library will handle all of that for you. Okay, so I wouldn't put that in my Composer JSON, sorry for the specificity, I just thought, I mean, I like this, I think it's cool, but it's not just change for change sake, it's really a good idea. Yeah, so if you look at the core, if you go to the Drupal A repo, and you look in the Composer.json file that's in the root, you'll see where, well, we haven't added the repository for Drupal packages, but if you added that, then you could just rely on other Drupal modules, yeah. How does Composer handle... Okay, so they actually, if you go onto, if you Google Composer version schema or something like that, they have all of these different version schemas or constraints you can use, and they have some for semantic versioning, which makes life a lot easier, but some projects don't adhere to that, they adhere to other versioning schemas, so you kind of have to know what the library is doing and you can adapt your constraints to however you want. So, for instance, if you wanted just the Drupal 8.0 whatever security, you could do like 8.0.star and that would, that you'd be stuck at 8.0 point whatever the last point releases, and it won't go forward. So yeah, so when you run Composer install, or, oh, yeah, update, okay, it pulls the existing update status and all of that. Infrastructure we've built up around there. Yeah, it works the same way as if, and this is the thing that's a little, you would have to understand about, if you decide to go, I'm gonna use Composer, is that the only thing that's gonna update is the core folder. Everything else you're responsible for updating, which hopefully there shouldn't be that many changes because there's only a few files, like index.php for instance, but it will update that folder just as if you were to download it and drag that folder in, I mean that's what it's doing, and it's also gonna update all cores dependencies, so it's gonna update whatever they've defined in their Composer file. Yes, whatever they've defined in their Composer file. So my background is in release management and being able to reliably reproduce a given set of code. So if our package script on Drupal.org runs Composer install, and it gets, for example, 5.0 squiggly is the latest 5.0 release from this library somewhere. A month later, I'm trying to reproduce this bug. I run it again. Now that latest release has been revised, now I'm getting version 5.0.8. And there's no good way for me to know what actual version got packaged, how do I reliably reproduce that, et cetera, et cetera. So this is maybe my back in the old days, but my superstitious fear of going to this kind of model in general is that it becomes much harder to reliably know what version of what code is everybody talking about. So I offer that as a concern. That's a great question. And so the composer.lock file is what saves your life because it pins your dependencies to a specific commit hash. And what you're gonna do is you're going to, you're gonna put that into version control. So now you know exactly what commit hash you were at of that dependency at that specific point in your version control. So when you run composer install, I think I mentioned this, but it ignores what's in composer.json and it only looks at composer.lock for the most part. There are some instances where it looks at it just to make sure it's in sync, but it's going to like, for instance, let's say you ran composer install and you got 5.0.0 and you run composer install again later and they've come out with like 5.6, it doesn't care. So we'll just run 5.0.0 again. Until you run composer update and that's the magic command that updates your.lock file. And then you commit that to version control and you know what you were updated to. Is that answer your question? And composer is kind of unique because a lot of version control systems don't have that lock file. They just let you, you would run into that exact problem if you were running a lot of the other ones. And also the nice thing about composer is it takes the version numbers off of the git tags rather than the whatever the maintainers put in the version spot of their file. There is no version spot. You don't define that. The library doesn't define that. It just pulls that off the git repo. So Drupal core, it comes with a whole bunch of modules. Node module views now, which is awesome. Do you foresee this subtree split happening on the Drupal project to where you could download Drupal core's version of Node from Drupal.org slash project slash node? I think that would be incredible. I think that's the next kind of step after the components because I think the components are probably more important. But yeah, the modules being available like that I think would be super helpful because then people can kind of if they wanted to build a system that had a API that was compatible with Drupal, they could use those modules in that way. What modules do you see? What Drupal modules do you see useful outside of Drupal? Well, that's a good question because I would have said none except for that I was using the serialization module and that's a very simple module in Drupal core that could completely be, it's just a collection of classes. I'm not even really sure why it's a module but it could be used outside of core. Yeah. So it really depends if you wanna support all of the APIs that that module needs and that's up to the person that depends on it. And do you see what are your thoughts on profiles? Cause right now you set up like you have profiles slash standard, we have profile, I think testing is in there as well. I could be wrong. Install profiles, yes. And distributions as well. How do you see that happening? I mean, in an ideal world, the install profile would be able to just define all the models that it needs or the libraries or whatever its dependencies are. And then when you download, just like with Drupal core, when you download the distribution, you also get all the libraries or you would run composer install if you get cloned at. But yeah, I envision it working the same kind of way that so Drupal in the way we know it is just a distribution. And so if you think of the core directory being that dependency that all of these distributions would require. So just like a symphony standard, they call that a distribution of symphony. It's just one of them. I don't think there are any others actually, but that's a, I look at it the same way. Awesome. You're doing an awesome job with this. Thanks so much. I started collecting a lot of questions while trying to keep it short. Working on the Drupal CI stuff, I definitely saw a need for the sub tree splits of core because they had copied the whole plugin architecture from Drupal core into the Drupal CI console app. And so it was like, oh, that would be nice if we could include that via Composer so I can see right away that that would definitely have some value. One issue that we kept running into was dependencies and subdependencies relying on different versions of different modules that were incompatible. We had one that relied on Guzzle 4 and one that relied on Guzzle 5 and it just wouldn't work. So how does dependency management like that work if you have modules that are old or un-maintained that rely on old versions of libraries? And would you envision those like checking in lock files or would you envision those having? Well, the lock file is ignored on anything other than the root. So if a library checks in a lock file, that's ignored. But really what should be done, and this is kind of what Symphony did because they ran into that problem, is they kind of created a wide of a range of dependencies that they would support. And they actually added the, for testing purposes, they added the, there's two flags in Composer one which will give you the lowest requirement that you support and will get the highest. So they run all of their tests on both the lowest and the highest that they support. And as far as like old un-maintained modules, I mean, that's a problem with any module that requires a third-party library. You could, and you know, there's different work, there's different work surrounds that people have. Like they will, they'll just bypass that Composer file and stuff and just, if you know what you're doing, you can get around that. But it would be better just to contribute to that module and be like, you need to support this. But if you don't test it, I don't know how you know whether it's supported or not. Cool, I have one other question. There's a lot of discussion on one of the threads about the Packagist and people having its own namespace around Packagist.org now. And there was a lot of people that expressed a strong vehement desire to not move Packagist over to Drupal.org and have our own self-hosted version to keep everything on basically the Symphony Packagist repository. What can you say about that? Like, I think, I don't know who made the point. They basically expressed everything I was thinking, which was that I'm all for that but we have a version numbering problem. We can't put a single module on Composer's Packagist because they don't support the version numbers, so it won't work. The only work around to that is to everyone who has a Drupal module to double tag every release in Git. But until we're willing to switch everyone over, you know, and that issue is gigantic of whether we should switch everyone over or not because people ran into like, what is them, you know, it was more than I could handle. But yeah, I'm all for it as soon as we can figure out that version number because I think the more that we integrate with other people and the more we use what everyone else is using, the better. One more, sorry. The Composer, when you're saying that like the tarball should come with CD Composer, Composer install, where does Composer come from from the, on the builder's directory? Is that included as a FAR file or something inside of the distribution or? I mean, it's installed globally on whatever machine is running that. Always, or should, or needs to be beforehand. It needs to be beforehand. Okay, so that's a prerequisite. Yep, you can download the FAR file every time, but I mean, it's just kind of a waste. Right. But yeah, I typically just install Composer globally, that's the best way to really run it. But yeah, it is a FAR file. Cool, thanks. Yep, you're welcome. If the vendor directory is in the get ignore, right? This is a little bit different than say, NPM node modules directory, right? We need the vendor directory on production. We need that upstream. So what are you, how do you suggest? I mean, running Composer up on production to get the vendor directory? You could either, yeah, you could either run Composer install depending on your workflow, or, and you could automate this, obviously if you're doing some sort of integration like that. Or you, another solution I heard, which if you feel more comfortable doing this, is just copying the vendor directory over, that would also work. The dependencies should be the same. If you just ran Composer install, if you wanna test this, just delete your vendor directory, run Composer install, you'll get it back again, and then just copy it to your server. If you don't want to, or can't, some servers can't run Composer, but you can do it that way too. There's no difference. Copying, okay, that's a thought. What we do for that sort of thing for deploying Drupal.org is we have two repositories. One we commit to is a Drushmake file and some other Composers. We have to run it and check that into a second repository. Some modules include a getignore that we can't, don't actually want ignored, so we getignore there, getignore, there's some tricks. Mostly a Drushmake workflow, so it'll get rid of the get. Whoa, hi. So what are the big things for Drupal.org that need to happen? Is it all just the proposals that you went through? Yeah, that's where it's, I mean, it becomes a mess, but I think the big one, and the one that started this was having Drupal.org to maintain the subtrary split of Drupal Core, I think it would be huge. Right now we have it, but it's kind of being maintained by one person, and that's hard, so it would be nice if that was part of it, then we can say, yeah, we officially support Composer, and Drupal.org is handling, downloading either Drupal itself or Drupal Core, that's all coming from there, and there's, actually there's already a namespace, it would be Drupal.org slash project slash core that isn't being used, so that's already available, and I think that's kind of how that would work, and that's probably the big one, and then the next one would be quite the Drupal components, but as I said, there's also this contra problem of how do we solve this problem, and that's probably a whole bigger issue. Someone marked it as the contra of issue as a critical issue, and that was not down, which I agree, it's not really a critical issue, it shouldn't stop release, but I think it's gonna become more and more of a problem as time goes on, and yeah, I don't think people are aware of how big of a problem it's gonna become. Well, thank you, everyone, unless you have, did you have a question? Oh yeah, go for it, I was too fast, sorry. So this does bring up that site builders versus developers thing where the implication is you expect Composer to be installed on whatever shared hosting environment people are trying to build a Drupal site on, and I guess is there a proposal for a solution on how to make that easier so that users can use the add a module interface that they have now, or how would that work? There is not, but there should be, because I know the only proposal I know of is to remove that update function and add a module function completely, because I guess there's some problems with it working with 8 right now, so that's kind of people's solution, which I don't think that's a good solution, but there does need to be some sort of user interface, but I don't know what that's gonna look like, if that's even possible, there's a lot of unknowns, but yeah, I mean, like I said, the data supports that there are way more site builders than there are developers that use these tools, so, but the developers want to use libraries, so, well the problem with the Contrib modules is that you don't want more than a bunch of vendor directories, because then you have dependency hell, because if my module requires the OAuth subscriber and your module does too, if someone site builds it, they're gonna get portal. Thank you so much for coming.