 Everyone go ahead and find a seat if you're wondering if you're in the right place in a minute or two We're going to be talking about composer Drupal and Drush for the win Good afternoon everyone. You are in the composer Drupal and Drush for the win session Like to tell you a little bit of a story so you can find out if you're in the right place or not Today we're living in a world where software is becoming more and more complicated and dependency management is getting more and more complicated and people are trying to do this manually But the dependencies are just getting unmanageable. You're losing track of things dropping your boxes It's not modern I'll tell you a little story about something that happened to me for real. I was having an argument with someone over dependency management What was an argument? civilized discussion in the issue queue and I He said well, you don't have to use composer like that You can do your own thing to see what he was talking about. I installed his extension and I forgot it was there In a month later Drupal 8 just started blowing up on me. It's like boom How could it even do that as in the debug debugger and I'm like how could it even do that the base class? It doesn't even have its requirements and I can see the code and it's right there That guy he had a copy of symphony in his project and the base class was different it was Descending from an older version. So the derived cast was descending from an older version of the base class And that was a runtime error. It wasn't you included something twice. It was a runtime error. It's hard to find so the right way so using Composer that's going to help you manage your dependencies. It's going to make it a lot easier So you don't have to go through and think okay Well, I have this and that requires this and then that requires these two things And now do I have all these they're just no more. Hey, this isn't working because you're missing something you need Composer manages that all for you. Make sure it's there for you Another thing it can do is help you avoid the class nightmare where it's inheriting from the wrong base class The auto loader Lacey includes all these class files for you and make sure you avoid this nightmare that Greg went through And it also helps keep your repository clean No longer are you committing all of the module files all of the libraries? You have basically one line if you're doing peer review and someone's like yeah I'm building this new functionality and it requires these libraries and these modules and maybe there's some custom code You just go through all that you're like waiting through module files after module files. No more you can easily Here's exactly what they did custom Okay, so I'm Greg Anderson. I work for Pantheon an awesome company. I'm an open source contribution engineer And some of you know me for my work on drush I'm Doug dobertsonski. I am the build manager and a Drupal developer at Promet source based in Chicago Today we're going to talk about what is composer? And there so installing Drupal 7 with composer You're going to have the composer vendor plus a custom installer or you can take the Drupal tangler route So you have two options and based on those two options We're going to tell you how to manage your project and then we'll also go over how to do the same thing with Drupal 8 Let's get started So composer includes an installer You'll notice there that it's listed. We'll go into that in some more depth It's also a dependency manager different components are going to ask for different versions of their libraries of two different Components asked for the same thing in different versions composer is going to figure out which version is the best one to use And it's an auto loader. It loads all your classes for you So why use it? It's standard It makes it easier for developers. It takes care of all of your dependencies Make sure you have the best version it does code updates for you and it auto loads your classes Basically, it's being used everywhere. Here's some examples So you'll notice there are a ton of projects using composer if we try to include them all we'd probably fill up the whole hour So here's some gamble symphony Drupal 8 now Lots of lots of projects are using composer But Drupal 7 isn't using composer. Oh Can we use composer to build Drupal 7? Yes, we can So we have different parts in composer. You have composer the PHP dependency management You're going to use packages. This manages your software You're going to use a composer Jason file to tell packages exactly what you need You're going to have auto load that PHP the generated file that must be included by your app And finally you're going to have to pick a custom installer This is going to be one of the key things we'll explain is how we use these things to make everything work with Drupal 7 So what is packages? It's a third-party Repository containing data on projects dot Drupal from Drupal.org. It's at packages dot Drupal dash composer dot org The people who maintain this one of them being web flow Florian Weber are amazing people and have made this available for us to use And the other thing I want to mention about that is that there is a standard Packagist that you can register components in But then this is the special Drupal one that automatically takes dependencies from Drupal.org An interesting thing about Drupal packages is a composer Requires that all of your component version numbers use what's called semantic versioning There's something called a major version a minor version and a patched version and these all have very specific meanings to composer In the Drupal universe, however, it's a little bit more confusing than that You've got the Drupal major version the Drupal.org just calls the major version Unless it's talking about modules then the major version is the modules major version Which is that middle number there and then there's also what they call the minor version so a Drupal package is The Drupal module version is remapped to semantic versioning with the Drupal major version becoming the major version and The module version becoming the minor version and the Drupal minor version becoming the packages patch but The mapping doesn't have to be as confusing as it sounds you see the three numbers in order They're still the same three numbers in order. You'll just write it a little bit differently in your composer Jason vile So looking at this versus Drush make you'll notice they're Fairly similar down at the bottom. You have your modules and Drush make composer Jason You include those modules and require and you also specify the repository to use The autoloader is a really cool feature of composer the concept of autoloading itself is part of PHP That's something that PHP does But to help you manage your autoloader Composer has a number of components where it plugs into this runtime system and this slide only shows about Half of the parts. I just want to give you a taste of what autoloading is like so you can understand the concept in The upper left on your PHP runtime You're just going to include your autoloader file and then after that your only obligation. Well, you have no obligation you just Instantiate a new class and the autoloader finds it for you. How does that work? Well at install time There's a little bit of information inside of your composer Jason file that describes where a given package Has its source code located so composer reads that file and then in the bottom Right there. You can see it makes a little PHP file that has a map that just records that information and at runtime PHP is going to go ahead and Load this other piece of generated code here that just iterates over the Class load information and calls the PHP function. Well, that's a composer function set psr4 Which eventually goes and calls the PHP function that tells you where that class can be found So all of this stuff that's done for you it only saves you one line of code You don't have to include your class file anymore one line of code per class, but it's a very very important line because Leaving this line out of your source code means that you don't need to worry about where the classes are coming from and that Is what opens up the possibility of allowing composer to manage that complexity for you So looking at some custom installers for Drupal 7n composer As we mentioned earlier you have several options We have this first two in the upper left with The custom installer as well as composer preserve pass Another option is Drupal tangler Which is a custom installer that will take your components and drop them down exactly where they go Along with that you have some optional parts to use with composer tangler There are strupo libraries installer plug-in to help you get needed libraries into the right folder as Well as composer patches allowing you to patch modules We'll show you how all of these things are used next So the short answer is with all of these things. Yes, we can and we're going to show you how part two So looking at some options. We have composer autoload This searches for an autoload file in every module directory and then load some individually The thing to note is if you're looking through all these files and loan them individually, it's very fragile This is exactly the scenario. I went over at the beginning of the talk Even if you're using composer if you just merge these autoloaders together you're going to get runtime errors so we want a solution that Handles everything together in composer and composer manager is an example of one of these solutions It will iterate over all of the files in your Drupal site and find all of the composer Jason and it chops them up into little pieces and it reassembles them just right and Make sure that everything is all put together just so to allow your dependencies to be evaluated by composer and it works and If you're already using composer manager and you're happy with it There's no reason to stop using it because it works as advertised But the problem with composer manager is it's complicated So if you're using this in your project, then you're going to be dependent upon someone to maintain this complexity So we're going to show you another way That doesn't require composer manager actually just two choices So as we mentioned one of the choices is Drupal Tangler So this writes a settings PHP file that loads the correct autoload PHP file And I also call out a very simple module called composer vendor All it does is include one file the autoload PHP and site cell vendor You could actually dispense with this module as well and just include the auto loader by hand from settings PHP Which is what Tangler does So looking at Drupal Tangler We have the overall structure there if you're familiar with composer one thing you'll start to see it's very important Is the composer.json file? This is a new top-level directory for our project You put it there because composer cannot manage dependencies in the same file as composer.json We then put our web root our Drupal root in htdocs Drupal Tangler actually defaults to www but you have the option to specify what to call this directory Then you'll notice we have our vendor directory that's in root Because that's a default place that composer puts it But we need that in the Drupal root So we put it in sites default vendor with a sim link So then looking at module and profile placement with Drupal Tangler You'll notice the standard vendor Structure where it has your project or your vendor name and then the project So we have Drupal and we have our module views in there This is done by composer it go heads and downloads these and places some there and then you'll notice It gets into some sim linking so to get the Drupal structure It sim links from profiles Panopoly back to that Panopoly directory in vendor and it does the same thing with views Then looking at custom modules these are placed in the top level the root in the modules folder You can divide these however you would like to see them as is common practice You generally put them in custom and then you have my feature module and again You'll notice there's some sim linking going on to get that Drupal e-structure It links it sim links your custom directory in sites all modules back to the top-root modules directory Finally, you have your settings with Drupal Tangler So we can put default configuration in your config.yaml.dist and then you can put custom configuration for settings in just config.yaml and then the settings file is Auto-generated for you based on which config.yaml So if you have a config.yaml file, it will use that one to create your settings file Otherwise, it will use the default config.yaml.dist So composer vendor is another option. I don't think it's really any better or any worse It's just a question of tastes the main difference here is that composer vendor is Going to require a little extra complexity in the composer Jason file in order to place things down Exactly the way Drupal expects to find it. So you have a slightly less complicated tree layout We're going to place the vendor directory in sites all modules vendor I just did that arbitrarily because that's where my little Then the composer vendor module wanted to look for it You could put it somewhere else if you were including your own from settings PHP The way you place the vendors directory is you just add a config element To your composer Jason and inside there one of the configuration elements that you can specify as the vendor directory And it can go anywhere. It's based off of the root of the project of course like everything else When you're placing custom modules and themes you're going to use one of these custom installers I've chosen the one that David Barat put together, but there are other choices that are very similar The thing that custom installers have in common is they look inside of the extras section of your composer Jason To read data that is in a arbitrary format that's defined by the custom installer So in the case of this custom installer Drupal modules Drupal themes and profiles and so on they just name the path that they go into and you can see that There's a little replacement on the end there dollar sign name is replaced with the name of the project So it'll just drop any Drupal module down into sites all modules can trip similarly profiles can be placed in htdoc profiles and Everything will just go into place now I'll take to drush you take a pose when you're using All of this stuff whether it's composer vendor or tangler You're going to get into a new workflow, and we're just going to compare how your new fancy composer based workflow is Different from what you're used to so when you're existing workflow use drush DL develop You name the module and drush downloads it and places it in the right folder Looking then at composer you're going to do a composer require and it will update the dependencies Using installer installing require dev Yeah, so the difference there is that drush you have to require you have to specify Sorry drush you don't have to specify the version and composer you do But composer will update the composer Jason file automatically for you So that makes it easy at update time drush you run PM update Composer you run composer update and land drush up DB our update DB and Regardless of what technique you're using to update your site you all know by now that You should not update the live site test it first very important safety tip Fancy techniques will never change that So looking at installing a module from a private repository These are the same for both composer vendor and Drupal Tangler You'll notice you have require and then your org slash your module You can specify then the version and That's going to match up with the your org and your module in the repository section You can also add patches to a module just like drush make You use this custom installer There's a few of them the one I have illustrated here is called the composer patches plug-ins in the extra section It just has a list of patch patches that goes with each module and you give it the URL of the patch And then the custom installer will apply the patch to your module after a composer has done all of the other steps to install it for you So looking at using a composer library from a module You again as you'll start to notice use composer.json and you require the library and That's it. No step to But it's very important to note as we've mentioned earlier is that you never want to include an autoload file from a plug-in You leave the autoloader management in the application so that you don't have your class inheritance hell So what about drush with drush, you could write extensions as well But drush extensions are a little bit different than a Drupal module because not every drush extension Goes with the module and if it doesn't go with the module then it doesn't necessarily have a site that it's attached to so the first step is the same if you want to use a Composer provided library in your drush extension. You just put a composer.json in your extension and you require it But the important part is you do not want to include the autoloader yourself from your code Instead the recommended thing to do is to call a function called drush autoload and you pass it the Magical PHP file Macro and you do that inside of your command file and drush is then going to figure out the environment and drush will say Oh, if this is an extension that's part of a module and it's autoloader is inside the vendor directory Then I'm smart and I'm not going to load it twice But if it says oh this extension is running standalone and I haven't bootstrapped a site at all Then I'll go ahead and include the autoloader for you So if you do this important step, then you can rely on on drush to Adjust the strategy if anything changes in our thinking we won't have to go out and make all of the drush extensions Change the way they're autoloading Going strong We're about halfway done So looking at managing your project code, hopefully every one of you is using get or some version control So looking at your site, you see some common files. You have your dot get There will also be a dot get ignore that is not shown here so you're going to want to commit your composer.json and Composer lock to your get repository, but You are not going to want to commit modules or htdocs because composer handles that If you have any custom modules You can just commit those to the same repository that you put your composer json in or if you prefer you can make your own Component and add it to the composer json and we'll show you How to do that? Deploying your code The nice thing about composer is It figures out what code you need so an obvious thought in deployment is why don't you just run composer to Install on your remote site the same way you do it on your dev site When you run composer install it writes something called a composer lock file and the composer lock file Ensures that if you run composer install again without running in composer update You're going to get exactly the same software that you did before so if you have a remote dev machine using composer Install to repopulate the software is a perfectly reasonable thing to do You can also deploy code using our sync you'll notice it's a bit simpler So you're going to clone you're going to do that composer install that'll give you all the files the Drupal root and then you are going to our sync the Drupal root to your live server This is available if you don't have composer on the live server It also saves a bit of processing power since you're not doing install and possibly downloading all the files as well That'll help with uptime So what if you're using Some hosting provider that requires that your Drupal root go at the project route and we've been showing you That in the ideal Composer world you add a new top-level Directory to your site to put things like composer.json and all of your git files and other very convenient Files that are not part of what you want the web server to serve If that's not an option in your deployed environment though one thing you could do is use two repositories For example, if you have a repository that your hosting provider Requires that all of your code comes from you could start off by pulling from that repository to get the existing state of the site and then take your lean mean fighting repository and Build it with composer install and then copy just the document root Over what was there before and then you have a nice set of differences that you can commit and push up to your hosting provider Even cooler if your hosting provider upgrades to support composer natively and I'm sure that you can You'll find that that will happen more and more as time goes along You'll just commit your composer jason and the hosting platform will say hey, I know what to do with that. Wouldn't that be cool? So looking at converting an existing site You can use a project called composer generate You're just going to download that project using drush You're going to use site aliases to create your composer json And then you'll notice it gets very similar to what we've been talking about with the ideal composer world You're going to just compose or install Set up your settings php copy your files all that good jazz and then you're going to dress site install to get your magical Drupal site Today this only works with Drupal 7, but it's just a matter of writing a template to get it to work with Drupal 8 so You know you can always fiddle with it and Change it and make it install the kind of site that you want So looking at creating a new site with the Drupal 7 framework This is something that pro met has pulled together using a lot of different projects. It includes Drupal tangler It includes drop a custom project called drop ship To help you with deployments So you're going to use the magical composer command create project They're going to specify the vendor name and then that project name and You can optionally specify the project name This is the folder to which it will create and then we use vagrant and virtual box To just go ahead and vagrant up with provision to create that virtual box That's all included in the Drupal 7 framework. If you're curious, we can talk about this more But the idea is it gives you a starting point to have a Drupal site Drupal 7 site with some of the most common modules as well as a way to deploy We call this the development of rocket ship if you're just doing a Bear bones site there is a project called Drupal composer slash Drupal project and this gives you a template that you can use with create project in order to make a Canonical system 7 site without all of the bells and whistles so this is a good project to look at the source code for if you want to Customize and make your own Create project deployments for folks Part for We're in the home stretch So Drupal 8 already uses Composer this means it should be a massive magical land You just use Composer and Drupal 8 and it'll give you exactly what you need, right? Yeah, you just get on your rainbow unicorn flying butterfly and zip off to Candyland and in This magical world of the future composer create project Drupal Drupal Path your project till the 8 will give you a working Drupal 8 site Except today all it gives you is flames and Exceptions and things and why why doesn't it work? It should be so simple That's complicated Very complicated. I could go into it, but that would take two hours. So instead of going to in two hours Please come back tomorrow for David Barat session at 345 in room 511 BC he's going to talk all about the magic of What's called the split core? I'm just going to sort of gloss over it a little bit actually Doug will gloss over this slide So you'll notice some common themes in there the Drupal core contains only the contents of Drupal 8 core directory Again, and your require you have Drupal core you specify your version and then you also specify your drush version You'll notice this is using installer pass as well to set where things should go And as we mentioned previously at the critical point here is that we have drush and Drupal in the same composer Jason so because they're in the same composer Jason That means that they're going to be in the same auto loader And that means that you're not going to have someone giving you an old version of symphony behind your back If someone tries to do that you'll find out at composer install time. I guess I'll take this slide so the project layout looks very very similar to What we showed you before for Drupal 7 but the difference is that since we're doing this thing called the split core Where is the core directory? You know when you try to squeeze things into the slide Sometimes folders get left off So there should be a core directory in here So the idea with split core is Drupal 8 if you download it per normal from Drupal.org You get a big package full of stuff and one of the directories in the route is the core directory and most of the stuff That is Drupal 8 is inside of that folder called core So if we roll back here to the composer Jason You're seeing that we're requiring instead of doing a create project of Drupal slash Drupal We're requiring Drupal slash core so Drupal slash core is a separate project from Drupal Drupal And it's actually a subset of Drupal Drupal That contains only the files that are inside of the core directory If you look on Drupal.org and issue queue You'll see that there's a lot of patches that are still open that are doing things like Taking the contents of index dot PHP and moving it into the core directory So index dot PHP will only be an include of some file inside of the core directory Why are we doing that? because When you are using this Create project the whole idea with a composer project is that your project owns all of the files at the top level so at composer update time The core directory is going to get updated, but if there's changes to any files inside the core directory that you have Copied out of Drupal Drupal then you're responsible for changing those yourself but in the future that's not going to be such a bad thing because as I mentioned The important parts from that file those files are all moving into the core directory Also because Drush is in the same auto loader as Drupal. You'll notice now that you have One drush site for every Drupal site on your system and that's different than the way we traditionally do it where you install drush Globally and the one drush Operates on all of your local Drupal sites. So we call this a site local drush And the reason we invented site local drush is exactly what I explained before we want Drush and Drupal to be sharing the same auto loader and the only good way to do that is to put them in the same Composer vendor file But you don't want the unfortunate side effect of having to type a very long path To drush every time you use drush And you don't want to have a one separate alias for every single Drupal site and to type the right alias for the right site so We are still in the process of working out. What is the best way for this to work? There's an issue that I've quoted there 1343 and the drush issue queue Or we're talking about a couple of different alternatives one of the alternatives is that At drush install time we'll just tell you to put this folder Home drush use bin into your path and then if you call drush site set At your site alias then drush is going to rewrite the symbolic link to point to the correct bin directory Inside of the composer bin directory for your Drupal site and then drush the right drush will just magically be on your path through the power of Linux and You can just run drush status and it'll hit the right site There's an disadvantage of that if you're already using our Examples bash RC, and if you're using the use command you'll know that your prompt changes every time you use another site and with this option you could get into the Unfortunate situation where your prompt showed that you're using one site, but your path was pointing to a different Drupal So even though this one is easier to set up. It's not necessarily what we're going to go with There's another thing that's done in the patch where if you just say Use the drush use command with your site alias then using the existing feature Drush will tell you which site you've used and it also updates your path BAM to point exactly at that Bin directory so then you can just run drush And then finally the read dispatch option is already working as a 7-0 RC 1 If you run drush with the site alias and the site is local and it has a Another copy of drush then your global drush will see this and it'll relaunch the local drush So that it can bootstrap with the right dependencies So then looking at our autoload We're going to have to modify this so in our modified site. You'll notice we return the directory With up one directory vendor autoload Whereas in Drupal 8 our autoload is in core which is in root slash vendor and then you have your autoload dot PHP And this is a side effect of the fact that Drupal 8 isn't yet set up to just natively allow you to use the Composer create project once that gets all worked out. You won't have to change that So the big question is, you know, you're changing that root file. Are you hacking core? What does hacking core mean? Greg Dunlap talked about this first in 2008 we talked about God killing a kitten every time you hacked core don't do it. It's bad We just changed autoload and autoload was distributed with Drupal. Are we hacking core? This concept is still under discussion But are you see a splitting core? You're not hacking core But The definition that I liked as they say well if you have to resolve merge conflicts when you update Then you're hacking core. So let's take an example From the existing world if you're using Drupal 7 Maybe you need to make a change to a dot HT access file if you have a really old Low-cost hosting provider that requires you to specify your PHP version that way and a lot of people have to do that So if you just change the middle of HT access and you have to update it every time you're hacking core And it's a simple way probably not going to get into trouble for it But it's a hack But if you wrote a script that just appended to the end of that HT access file then there would be no merge conflicts and You know that wouldn't be considered hacking core. So as you can tell we were sort of getting into philosophy here You have to find the workflow that's right for you, but just make sure that when you update you hit all the files Where do we go from here? We'll take Q&A in a couple of minutes, but we've got some URLs here of very important and useful places Composer of course is that get composer org and there is a group on Drupal org for composer discussions, and there's some very interesting discussions you can find Inside of there and the folks who made Packages dot Drupal composer org. They've got a landing page at Drupal composer org that has Links out to some of the most interesting pieces of information if you want to track What's happening in Drupal 8 today? You can find links to key issues off of this site and if you're interested in how The packages to Drupal composer org Malls the set the contents of Drupal org to create this packages file the source code is all up on github So if you want the slides you should follow us we'll both tweet when they're available online and If you have any questions you can come up now One other project that actually was mentioned and not put on here don't Is the Drupal 7 framework, so I should put that up there. It's open source We've already had people getting involved. We encourage you to try it help us test Find errors if you find errors file an issue queue and work on fixing that We've already taken a lot of work that was out there done in the community just recently to improve it It's on github slash Promet Slash Drupal 7 dash framework and we will tweet that after as well Yeah, I think that URL does appear someone of the slides, but we will fix the slides and put it in here before we publish them Thank you all for coming everyone. If you have any questions, we'll hang out and answer all of your greatest desires Thank you We're doing Q&A from the microphone in the middle. Hey guys Just so I don't silo this yeah, I'm gonna do it on the mic. Can you hear me? Yes so One of my questions is about and this might be sort of obvious, but if if Drupal Composer and some of the other tools you mentioned are a replacement for the old rush make and the idea of Sharing distributions you talked about the the workflows for instance. You could use our sink etc to for deployment, but when sharing Let's say we're if we're not going to say a made project Let's say a composed project that's made of many smaller projects contribute and so on I Know that there's another session tomorrow to use The split session and that it might cover some of this but you did mention something about patches And it was kind of my fault for missing part of that Could you describe briefly the workflow of sharing between teams is this like a quick Yeah, no, that's not hard at all. Okay, I mean the developers on a team are between teams. Yeah, yeah Are you talking about Drupal 7 or Drupal 8 or both? It could be both, but in this case I'm talking about 8 because this was the main focus 8 yeah, yeah Well for Drupal 8 The long answer is to go to tomorrow's session, but then the shorter answer is You recall in our slides. I can even roll back to it We're talking about managing the project And I regret that we left out the core directory here Yeah, yeah, so You know you've got you've got your composer Jason and you've got your your root projects and You can just commit these all To a git repository that's you know that emits the generated files And then you give someone your URL they clone the URL they run composer install And then they're up and running with your project. So then the open question is what about the database? What about the configuration? That's that's yeah, that's that's that's not a composer issue that works the same way regardless of how you get your files there You can use seek, you know configuration manager and Drupal 8 to get the configuration And you can generate content or pull content down from live Whatever whatever you want Yeah, yeah, it's becoming a lot more common I don't I guess we don't have an example for eight, but we have an example for seven It's becoming a lot more common now if you go to github and you see some random project If there if it has a composer Jason in it, they're expecting that you're gonna see that and you're gonna run composer install That's just part of your deploy If you don't like that two-step process There's a one-step project says that composer provides and that's the create project And so this command is actually going to go out to the URL specified by this path this project specifier here and it's going to download stuff and Composer install it and if you want to update it, you'll just cd to your project route and Run composer update, but when you're using composer create project anything that it puts in the root Next to your composer Jason that now belongs to you and you need to commit it to your repository because it's not going to be touched by composer update Okay Next question First of all, I wanted to say that this is friggin awesome So Second statement I wanted to make or a question I suppose So you were talking about the drush What was it composer if I project? Oh, yeah, just composer generate. Yeah, so does that add like the repositories for all of Drupal's modules and then how does that work? that relies on packages dot Drupal dot org which is done by windmill will and Dorasi and Florian Weber and it goes out to Drupal dot org and It's web spiders all of the projects on Drupal dot org everything with a release a stable release it Downloads it it converts the version from Drupal version to semantic versioning and it writes all of the information That composer expects so then you just in your composer Jason file You say hey, I want their Repository as well and then like magic you can say Drupal slash foo for any foo That's a project on Drupal and it'll get downloaded and that is due to the awesome hard work of Volunteers who are outside of the Drupal dot org space because it's probably gonna be a long time before Drupal dot org can break all of these dependencies to be natively providing this service for us and What was that? Composer if I drush component drush composer generate composer generate that is a little drush extension that just takes an existing site and It asks the System which modules are installed and then it generates a composer Jason file and lists all of the projects that contain the modules that you've enabled and Fill it out from there Thank you. You're welcome. Oh, and you can all be Confident that the third-party Packages will not go dark due to lack of funds because Pantheon generously Sponsored their their hosting so we're we're paying for their their server uptime So that you know our customers and our not customers can do this composer stuff and Be sure that it's going to be available until it's it's ready to be rolled into Drupal dot org Another question. Yeah, thanks. Go to the thanks for the presentation. So you recommended not committing to version control your modules and so forth that You're now Recording in your composer Jason. I wondered what the advantage of that was and if you were in a scenario where you know Connection to your get server is reliable, but connection to the outside internet is not Yeah, so again at this point we are Strongly in the area of opinion, you know, if you're asking me whether you should have one auto load or two auto loads I would say firmly. There's a right and wrong answer here But I'm not going to tell you what's wrong to just commit everything But let me tell you about the downsides or Maybe I can pose this as an upside, you know, if you have a team with a bunch of developers on it and The foo module is not checked into your get repository Then you know your developer isn't going to twiddle just one line in one file of your module to fix something You know, this is what gets you into the situation where you can't manage all of your boxes You know, that's the fastest way to get a release today. Oh and five minutes I can fix the problem for the customer, but you do that a hundred times over the course of a year and Then updates become more painful and documentation of what you changed becomes more painful So if that file isn't even there, what doesn't exist can't be hacked And I think that's one of the biggest advantages now in terms of network availability issues I Strongly recommend deploying from a tested site Where everything is all put into place and not using composer install for the push to live So if your internet Goes away, but somehow your customers can get to your site then you're still okay Because you're just going to be copying the site you already Tested and and I think that that's really the the recommended workflow You want anyway because composer install can take a long time if it takes 30 seconds Then that's 30 seconds of downtime while you're waiting for composer install to do its thing and you all hope that that process is reproducible, but I Don't know about you, but I have a lot more faith in a file copy than Running an installer, so I like to say what I tested is what goes out one other big advantage is Composer has version specification. This becomes especially Advantages if you're supporting sites, how many of you have been in situations where you go and do updates and then find Oh crap this update to this contrib module broke all this custom functionality We can't update that so you roll it back things. It's all good Another developer comes along in a month does updates does the same thing and then they have to go in spend that same time Figuring out. Oh wait, we shouldn't have updated this with composer You can say use this exact version and it's self documenting So you no longer have to worry about updating you see oh this is pinned for a reason We've dealt with similar situations with Josh make where we ended up just committing everything to the repository So and one way we check to make sure nobody's hacked is we just force everyone to run drush make Every time we commit Can you do something similar with? Composer can you run drush install and will it overwrite any? Customizations made the libraries that have been pulled Yeah, yeah, absolutely. I mean overall make and composer processes You're going to find them to be very similar if you're doing something with composer You pretty much can do that with make now and if you're doing something with make you can do it with composer one area that Make doesn't really help you with is the auto loading and the class Dependency management, but beyond that all of the basic functionality is there The main reason you're going to want to move to composer manager is you know today There aren't a lot of modules using External libraries if you go out and look on Drupal.org you'll find some modules are using composer.json and the ones that are Predominantly our modules that integrate with some third-party service service if you think about it for a minute It's really obvious why they're doing that because the third-party service They've published an API and they've got their API on GitHub and their API and GitHub uses Composer to and the composer auto loader because that's the way things are going if you look at any of that You know the things that Google provides the thing that Amazon provides any big vendor that's providing PHP libraries You're going to see that they're using composer to do it. So your module that uses that is going to use the auto loader You are completely not in control of what libraries those big providers Pull in through their composer.json. So if you're trying to use a make file to load these in You're in big danger that what you're using from Google and what you're using from Amazon might cause problems Unless you do it the composer way that we described and then composer install will make sure that all of those things Go together end up in one auto loader and you don't have weird hard to debug mixed-up classes Believe me. It's not not fun to fix those things Yes You use the mic you're not quite there No, yep. Can you talk a little bit about including PHP extensions in libraries if you have dances? I'm sorry PHP extensions as libraries. What is your question? I know that composer can include PHP extensions like requiring specific extensions to be enabled You know what she's asking Okay, I'll repeat I didn't quite get the gist of what you were asking Okay, so you're talking about the fact that if you have a class then you can Jam it somewhere and your PHP in it can point to it and then that class is available to be used. Is that That what you mean? Yeah, yeah but well the PHP extensions that's like the old way of doing it and Composers the new way of doing it. So if for use soap as an example If you have a PHP extension that provides soap That might be repackaged as a composer component that provides soap They they provide the same functionality in different ways but composer does not Specifically, I mean it composer has it has packages which keeps track of all of this Software that's available and it's its whole system. It does not take any foreign systems like PHP extensions and I'm predicting that PHP extensions are going to Become less and less used and people will just be packaging things with composer instead. So composer require is the way to go Okay, looks like that's it for questions. So Thank you all for coming. Thank you You