 So, I hope everyone is sitting very nicely because we're going to start up in a few seconds. So, hello. This is Larry Garfield. We have water now. My name is Rob Loach. I am a support engineer with Aquia. My name is Larry Garfield. I'm a senior architect at Paniter.net, or at Drupal DevShop, based in Chicago. And I'm also the Drupal representative to the Framework Interoperability Ambassador to the Sanctuary Project. So, Cross-Project Cooperation is a large part of what I'm doing these days. Which brings us to today's topic, which is Composer. So, Composer is a package management system. It will be good at which it sucks. It sucks more than both at sharing. Once you actually have a copy of it, then code into your runtime. How do you actually use it? And so, how do you get that one? Are you going to get it from the same place you got the first one? Only sometimes. Once you've already got that, where are you going to put the files in your project? Do they belong in your project? Really, I shouldn't be checking someone else's code into your repository. It will historically have said, no, you shouldn't. Sharing code, sharing techniques, sharing water. This is what Open Source is about. Thank you. And the first one that shares. Sucking at sharing is how Open Source projects die. Whatever we say, we're Drupal. We've got Drupal.org. And that's great if you're dealing with nothing but Drupal modules. We solve this problem for us. We didn't solve this problem for PHP. We solved this problem. We're really advanced in this developer. And you use Drush, and it'll download it for you. But then you're still checking all these into your... Or maybe you're using a Drush Mate workflow and you're redoing everything. But it works for absolutely nothing. But every project that has extension capabilities has some solution to this problem. It's specific to the... There's actually a whole conference event that's going on alongside TripCon, as well. What's that conference called again? Something that's symphony-live. Yeah. People can be there, right? I have web interested. I want to use third-party code to be library directory. I use the library's API to manually load it. I use the library's API for that extra hook. And custom code to intubate everything together. So, prayer ever make your code miraculously work. Our tools should be better than that. Our tools should not need to resort to prayer. This slide isn't my fault, by the way. It is, but I find my code to help myself here at my... So, with that, we'll get into a little bit of history behind Composer and why it happened. And some of the processes into how it happened. So, someone earlier mentioned PAM, the repository. It was founded in 2000 to support this brand-new thing called PHP4, which at the time, you know, just nice and easy to think it had classes, real class that it didn't actually work, but then it had classes. So, you could sort of share code. The problem was it was based on Pearl's approach to CPAM, which meant that you had to use root on your server in order to use it properly. And how many people have root on the shared hopes to publish something? It was a really crazy encounter. You had to get approval from some group of people, and there was some kind of review, and it had to meet certain home criteria, and I don't understand all of them. Sharing is what my hope and source is all about. That's what we're trying to solve with Composer. And it just break. So, really, very few distributed programs actually used it, because to simply live in Paris in February of 2010, to be able to say that Symphony Project Lead releases the first alpha of what will become Symphony 2, and people go, Oh, gee, this is awesome. It's written all the traction out so that it funds stuff that you'll reverse to jump on and say, This is so awesome, we're going to use it. So, they did it before we did. They haven't actually launched it yet, but they said it first. Symphony 2 was just leveraging a lot of third party life. So, for data storage, there was this tool out there called Doctrine that was trying to be so fine, used it. And this is a really good idea. Save yourself time, go do the usual stuff. This puts you into dependency help. Symphony depends on doctrine. Doctrine depends on this thing. Doctrine depends on that thing. Doctrine depends on another thing. And you get into the same problem you get into of this module. I have to go down to this module and that one. And that one's even on a different site. And this one, it is a depth relation. This one's a stable. This is actually working. So, we need some kind of water to kill this dependency help. And so, the Symphony community said that we need to actually solve this problem. And they are not the first ones to say this. By any means, we set it to a generic solution. Collaborate some very interesting algorithms. Way more advanced than anything PHP had at the time. So, you ported that over to PHP Project called Packagist, which originally was intended to just be a less sucky front end repair. Because publishing things through Pair, and they got together, I believe in a Korean restaurant, I said, you know what? These would go really well together. They got together and turned these two projects into Composer, which they told for dependency management in PHP, where is your project to meet? And it's all about, oh, it's great to have all of these different wheels that we can bring in. You need an N, so this is where Composer comes into place. So Composer solves the copy and paste of library problem. You don't need to copy and paste code around or copy and paste files around in dependencies. Just like, you know, Drushmake or Drushdl, depends on the other one. You just grab it, so the project, it'll put out that package. It depends on the specific version. It'll take care of the version. The project can define its own requirements. So, you depend on, say, the PSR log library. Composer just takes care of both of those and merges all those dependencies together. On all projects, you need to tweak its settings files to a point where you can register and plug it into that. You need to, very importantly, take care of auto-loading the code. Is anyone not familiar with that concept? Which itself supports a concept called auto-loading, which is, if you use the name of the class that has not been loaded the code before it gets into memory, then a series of utilities get called that will try to load the file off disk on half that Composer in every project can find how its auto-load works, although now most are using PSR0, this standard. Composer will stitch all of those together and build a very simple single auto-loading of some of the additional features to that. Basically, it does everything that InfoFiles know in Drupal. Actually, these are not Info.yaml files in Drupal 8, fair warning. But it works for anything. The first project was that it was surprise, surprise, auto-loading. The second was to make the air channel monitor also written by Drupal 8. SwiftMailer, which is a mailing library, also used by Symphony, which they stand alone to maintain the injection container that we're not using, and then Symphony itself, because now it can pull in all of these other pieces that it's using to make monologues, SwiftMailer, and so forth. Until early 2012, it only sort of worked. Composer still technically is not officially, it's a beta at the moment, but it's still being kept, because this is how Bernadette Far wasn't it, Pear wasn't it. This actually works. People actually are adopting. In April, there were over 10,000 packages available. Most of these are not Symphony buttons. They're just good standalone libraries that do their own thing. But you can now pull into any project and say, I'm going to use this code. It's open source. I'm going to share. I'm going to save myself time. You can bring in with Composer. There's a fantastic library called Symphony. There's a whole conference event that's coming out right now. It's crazy. I think Symphony has actually developed a series of freestanding components, which is how we're able to use bits and pieces of Symphony rather than pulling in the entire Symphony framework at once. Such a blade is using about a third of the Symphony component set. When you install Symphony, it installs those individual components with that effect. There's also this Zend framework has really aggressively adopted composer. The maintainer of Zend framework originally didn't want to. He didn't like the idea. But the Zend community rebelled and insisted. So Zend framework is now available through packages as well. Think of Zend framework as Symphony 2 as competitors. They kind of are. But you can still mix and match their components. You can use Symphony heavily from Zend framework to RSS and add in feeds. Composer, take care of the dependencies and now use this library. Who here has used Zend framework for something? Who's used Symphony? If all goes well, there'll be a little of each. Another one is PHP unit, which is a fantastic PHP unit testing framework for PHP. PHP unit addition to simple test. The long-term goal being to use PHP unit because no one would like a simple test. Steroids do everything. I'm actually working on a project where I'm using Guzzle right now. A session, I think last session on Guzzle from the maintainer who is here at Symphony Live. Seeing how the project is called Guzzle, I'm sure he would enjoy it here. There's also Solarium. Solarium is a great solar client library to allow crazy testing in the period PHP project. This is an alternative to the Apache Google Solar library that's used by this one that's available through packages. I'm actually pushing for us to adopt this one instead because it's so much easier to work with for this reason. Who's actually used the Apache Solar module which had the experience of upgrading the module and out-crafting so much less disappeared on me. Exactly. That's exactly what tools like Composer solve. It's got a little plastic up. Again, stand-alone library. It's got projects that monologue is, again, a great monologue. It allows you to log two different systems like a syslog or a database. It also has some crazy extensions that you can add. Just watchdog, but Ascetic is a JavaScript and style sheet management tool. It also handles images as well. You can add a bunch of different assets to your project and then have it filter and do really neat stuff on it. If you want to compile some coffee script, you can add it to Ascetic and then it'll spit out some JavaScript. Yes, it will. All of your SaaS using friends, they would want this. It's not available on packages, but we're using it internally. Not yet, but it will. Enough of a sales pitch to sound like a tool you might need to them using. Yeah, so we'll get into a bit of the technicalities how to use Composer. One will allow you to download all of these amazing libraries and two will show you how to publish your project onto packages so that other projects can use it. First thing you'll have to do is introduce a Composer.json file. Can people read this on the screen here? Your project, you can start your project with just a Composer on JSON file. Composer uses JSON and has its configuration format built into PHP, so it's guaranteed to be there. And two, it goes with the format as based on NPM from Node.js, so it just uses the same format and goes to the same syntax. So a project, those can be the same if you want, so symphony is symphony slash symphony, monologue slash monologue, sucrelle slash API problem. No one doesn't create API. I do that. If you have a project on GitHub, think of it as exactly the same as the nice mapping. Description, which description is required, I think, or is that optional? It's just some handy little edit data you can add to the projects to give people access. Okay, what other libraries on packages do I want? And you specify them by name, in this case we're saying the MyPackage project is compatible with Guzzle 3.4. I've had a chance to test it and make sure it doesn't break anything. You can also use operations in this version statement, so you can say greater or equal to 3.4.6, for example, accepts those version parameters. You can also specify the PHP version here as well. PSR0 is the standard used by most projects these days. It's a very simple mapping of a namespace class name to a directory. So in this case, we're saying any class that is in the MyAmeMyPackage namespace, look for it under the slashable src directory. This is myowncode. It also supports autoloading with straight up files too, so if you have a file with a bunch of different functions in there, you can just say autoload files, someone using functions is you're describing your project and what your project depends on. And this is true for your own project application or for a library releasing a project. The process is exactly the same. Then you have to let know about composers and you have to install it. This just ends up being a .farp. So a phar file is just a pack, like a executable in PHP code. Essentially with the java files from java, a bunch of classes combined using a file, exactly the same idea. So it's all PHP. You can run this through your system. Just to install a composer, there's this really ugly curl command that's actually doing here. I usually just copy this from the website myself is what some systems are actually up to you is far correctly. So it will check your system, try to enable far correctly. So if you want to enable far correctly, you can use a single file setting the composer.fire install and this will install any of the dependencies and auto load any of the classes for you. So what you end up with after it's done, like this, you have your composer.json file which you wrote a composer not blocked on exactly what versions were downloaded. Down to the specific git commit that you just installed in your system. In this case, SRC, you can put it forever. In this case, we now specify the dependency on guzzle. So that pulls that way. It guzzle depends on symphony's event dispenser library. So it pulls that down too. It also included what was generated by composers, generated PHP code. This generated PHP code registers any classes that are required in any of our vendors. It registers them to PHP as you see on the screen here and it will know where those files are. We don't even have to worry about including the classes or anything. This is the only included or required statement in your entire application. Which of these do you actually check into your repository? Which of these are your code? Would you check in someone else's code to your repository when you can just freshly download it and get their latest version or the exact same version you wrote before? Save your disk space, save your network so that your project is just your code should not include a copy of the event dispenser. It also uses the event dispenser. I only want one copy of it. So composer will figure out you need the event dispenser, you need the event dispenser. I'll download the event dispenser, okay. And you've got one copy on disk and both systems can use it. Composer update function is a function that you can execute with composer to update all of your dependencies and this will check... go out to the member code and be like, hey, I need at least this version to be those. So this will update any of the vendors you have to the latest. You can add additional dependencies so you can run this and pull those down too. Developing along, developing on. Not only do I need guzzles, I also need Solarium. I've uploaded a lot of files into your concentrations online. You can specify a license for your package. I recommend always doing this just for clarity. In this case, we're saying this project is MIT licensed. There is actually a specification for how you describe different licenses so there's a correct syntax for specifying GPL v2, for example. There's a link to the documentation there. You can also specify any development requirements you may have. In this example, we are depending on PHP you can run PHP unit tests to specify some back PHP unit. You can also suggest different packages. In this case, we say you may install monologue, but if it's not there, that's okay. We'll just suggest it. Which means our code is looking at work. We discussed building it before. The answer is we should switch over to... You can also host private repositories. So lots of people are scared about publishing their project on a public repository like packages. You still need to buy. Share often. There's a project called SATIS which allows you to host your own composer repository. This is great if you just have a certain amount of projects that you want to host on your own little ecosystem. You can add a bunch of different repositories to your own composer. You can have a number of different repositories. Now, the SATIS-like packages itself, SVN, Git, CVS, what else? It's sort of a publisher project. It's very simple. You create an account from packages.org. You point it at the repository on GitHub wherever it is you've got it if you are setting already. You push a new tab to your repository and that's available from packages and people can download that version. It's pulling straight from your version control repository. If you frustrate the Drupal process, there isn't one here who did so or who had fun doing separate questions. Turned question. They see it simple and fun and easy. So, now that we've talked about composer, you probably want to know how to use it with Drupal since this is in DrupalCon. We're talking about Drupal in this session. Believe it or not, if you're hesitant about installing composer because there's this really ugly curl code that you have to run, you can download the Drush composer wrapper. Who here uses Drush? If you didn't raise their hand, watch the video for the Drush session that was this morning. And then you'll want to use it. So Drush is a command-line interface to allow you to talk with your Drupal website. The Drush composer wrapper allows you to run composer. You just run DrushDLComposer. The composer command is available. There's a module. Once you add a composer.json file to your module, you can install the composer autoload module. And this will run through your whole Drupal website looking for autoload.php files and load them. So if you request it, we'll load that autoload.php file. And the best part is, it's not caching it into the database like the registry, so it doesn't break any of these who have run into problems with the registry in Drupal 7. I see two hands from Eric. I apologize for that. It's gone into Drupal 8. So there's also the composer manager module. And this takes it one step further. You have a bunch of different set of modules. The composer manager module, every module for a composer.json file and they all into one composer.json file. This is kind of mind-blowing because it's taking into account all of your different dependencies across all of your different modules interface. It's a bit small, but it gives you an overview of what depends. Once you have the generated composer.json file, all you have to do is run a command called TrushComposerManager and this will install all of the vendor code for you. In this example, you see we're downloading composer manager and monologue through TrushComposerManager and monologue for us along with the PSR monologue. There you go. There you go. TrushComposer figures out for you the only team track in which direction the proposition comes. As long as you run TrushComposerManager, it will run through the generation of the composer.json file and download those dependencies for you projects. There is called the composer installers project. This is a project that's independent from composer. It's a bunch of add-on tools that allow installation of projects into a number of different frameworks. You can also install WordPress plugins. I probably shouldn't mention that at a DrupalCon, but open source for friendly. It can also install symphony bundles or symphony one, which is those are installers. If you were to install a Drupal module using composer installers, you would add a composer.json file to your module and then send the type to the composer installers project. Adding this composer.json file is pretty cumbersome. If you want to add it to every project you have, there's this empty little project called the Drupal Packagist. Drupal Packagist is a very theoretical project, very prototype. It's very, very early. It just scans the Drupal.org repositories and then puts together a repository on those. So it allows you to install modules and themes using composer.json. This is all well and good. What are we doing with this in Drupal8? We're using composer.json, symphony, dozzle, send feed if we use it, a couple of others. Remember I said earlier that you should never check your render directory into your repository? We are. Challenges. The profacing as we try to integrate to composer more in Drupal to enable us to make use of the Drupal library. The best thing about this ability is composer currently really wants you to have command on access, which is great for developers. But if you're a site builder who doesn't have a code and doesn't have a command line and you just want to drop files into a directory, that's not so helpful. We're actually working on trying to solve that. You're talking to Femina this morning, Femina is trying to make really easy in Drupal8 for projects to make use of composer files. At the moment it's a little bit cumbersome. We still have to go through this whole chain. Suggestions on how to make that better, including volunteers to help make that happen within the next four weeks. Please talk to us. You can also talk to us on Friday during the code sprint. Which even if you're not working on composer, you're going to all be in, right? Okay. Yeah, so during this sprint we'll be talking about better uses of composer in Drupal. We'll be talking about what issues we have to run through. There's a tag on the Drupal.bar in HQQ for composer stuff. So if you just do a Drupal.org search for composer, you'll see all of it. For me, a lot of this PHP is changing. The language is changing. The culture is changing. This kind of sharing through composer is earth-shatteringly cool. This is changing the way people develop PHP. And Drupal should embrace them, should be part of that movement, should be part of that change so that we can benefit from it and become as pulp-shaped and finish driving up the rest of the way so that we can, in fact, be part of that move modules for Drupal 8 by taking standalone libraries available through packages that you write or someone else writes and thin-model wrappers that don't come all the cumbersome annoyances of the library's APM. So that's the goal and we're close but we need to help with it. I'll see you on Friday for that or come up and ask questions. So thanks so much for coming out. We'll definitely have some questions as well. You mentioned that you're going to check or do the source code repository and is that always true or are there reasons you might not want to do that? There are reasons you want to have the composer.lock file in there. It allows you to lock on a specific version of a project that you can depend on. So if you install it again it won't update it without you knowing. That's actually a good point we didn't touch on. When you run the composer install if you have a composer.lock file that's used instead of your composer JSON. Why is that's good? Suppose I'm working on a project and I pull in Guzzle 3.4.star and when I download it that's 3.4.2 and a month later Rob joins the project he checks out the code, runs composer install and he gets composer 3.4.7 and then we run it to a bug so clearly that I can't replicate because it's easy to get a different version. You don't want them. Of course. The composer.lock file will pin to not just the specific version but it can pin to an exact github or exact github shot1id. So you know as long as you're using the same composer.lock file you're pulling the exact same commit the every single line of code as identical in your render of repositories. Which means if we have a bug that Rob has and I don't have we know it's not good for running you can update your code and completely ignore the composer.lock file and update all the vendors you'll run a composer update function and that'll bring it in. So there was a lot of information there a lot of different modules possibilities there I guess my question is more conservative discussion about how to standardize actually using composer files interpolate and particularly around trying to make composer files in your actual order pin. Poser would come to you. Have those actually be in? Yeah so we definitely are in a transitional phase for composer integration. We'd love to have this conversation with you on Friday. In the meantime though composer manager is definitely the way to go since it facilitates both composer.json files in your modules as well as just putting it all together so it works for what it is future proof like triple seven triple eight triple six if you really want triple six support. Yeah that's definitely a conversation that we would love to have a couple questions around the verses around the composer community are they using semantic versioning the way that composer really adopts semantic versioning. So let's say sorry it doesn't really force it but things work better if you use simple. So what semantic versioning does is it forces a composer or a json file in it. So it forces a well it doesn't really force but it gives you three different versions so you have your major your minor and this allows it allows you to focus on a certain api version and so you can say I require api version 3.4 point whatever of guzzle break your api when you go so that's what semantic versioning accomplishes and it it uses that heavily and you're not forced to use it though. There's questions around the penances and if you have a package that has the same penances as another package but those are handled that just also usually it's like one library depends on guzzle greater than 3.4 another one depends on greater than 3.5 it'll dot the latest 3.5 if you have one that it specifically says it depends on 3.4 not 3.5 another that requires 3.5 it will refuse to install but tell you exactly why and then you can figure out okay I'll not use this library or I'll go file a package for that library to fix that dependency or whatever it is going to do so if it can't solve the penances for you it'll tell you and then it's up to you to decide which project to patch and I'll also try to download the best version that matches both projects as well so if you say greater or equal to 3.5 and the other library depends on less than or equal to 3.6 it'll seem capable but we have J as hint for the purpose of that file it's simply to just provide the ID with intelligence of the JavaScript libraries that are inside cores and also a built system yeah so although it's mainly focused on PHP projects it's not limited to image assets JavaScript assets, style sheets how the project averages those is up to the project for most projects it's going to install it into the vendor directory but we have a sample that you can find all of the install locations as an example so let's look behind the curtain here this slide deck is assembled using Composer and Assettock so we've got our source files in the repository that are damaged we have our RHD file from the presentation and the Composer file that holds in some code hero to deal with JavaScript libraries and then as well as Assettock to stitch all the libraries together and then I believe which libraries are we using we're using Reveal.js which is the actual presentation tool here Highlight.js Highlight.js is the loader we're using here for example and that's all we're taking care of by Composer so if you download these slides they won't work you run Composer, they will not work Composer also has the ability to reference scripts when things are installed as well so you can say run this script when this package is installed and then you can do things like copy files around or compile files for you and there's also Composer installers which exposes references to some of these projects they see there's a whole bunch of projects that this allows installation so Joomla so although some of these are mainly PHP Composer tools that have caught up so you can also reference you can define your own repository for using packages in the Composer.json file so if the project doesn't have a Composer.json file itself it doesn't provide that support in Composer.json file and that's using the repository's key documentation is on line it's actually pretty good documentation I have a question first about the other circular dependency if I'm going to view your slides so I need to download Composer but I want to look at your slides to remember how to download Composer getcomposer.org click getting started and that trip to command is right there I have a serious question too will Composer replace Drushmake particularly matches to particular projects from other locations and that sort of thing at the moment it doesn't support patch applying and you can specify alternate repositories so let's say you have a patch version of guzzle so you've taken guzzle from GitHub you forked it, made a pull request that pull request is still sitting there but you need that bug fix you specify your Composer file when I ask for guzzle use this alternate repository and it will then pull from your GitHub repository instead will Composer replace Drushmake I think so there's no reason why they can't work together as well we can introduce Drushmake hooks so that Composer installation happens and we can do it the reverse way to leveraging the scripts from Composer.json to run Drushmake installations there's a whole bunch of things we can do what we have to do is figure out the best way and much more forward we can see a lot of our triple specific tools like that just go away in time and just use standardized tools like Composer that's not going to happen in the near term I think so do you see us as a community getting first developed please dear god yes yes stick it on GitHub, stick it on GitHub stick it anywhere you want Composer can oh jeez that's of course mine can I talk about the PNX module for a sec another advantage of that whatever happens between triple 8 and triple 9 however much changes or doesn't change if your business logic is all tied up in a standalone library that you're just bridging into triple your reporting project becomes a lot easier because your code is nicely separated out and that's a good thing it recommends changeable 7 build standalone components that are not tied to any project the Drupal, symphonies and anything make those a standalone library and then bridge them into Drupal with life easier you're doing good OO code hopefully at that point which means you can be tested correctly your life will be easier now and in the future so yes please if I could follow that up it would probably be a lot of logic now it's not actually set up to make that easy the correct way of doing that to expose some kind of interface so just suppose you had some freestanding web form like configure forms that's probably not the greatest example since it's going to couple tightly to the form API but in that kind of case it would want to save its configuration to some kind of configuration object that matches an interface and then if someone was using outside Drupal they would have to bridge to that interface or you can have your own interface you define and then you write a bridge from that to the Drupal config on that bridge object in there and then someone else can write it for most just a good example of that it's the Zend feed library expects the Zend HTTP client so that you can say fetch me this RSS feed and parse it we're not using the Zend HTTP client but we want to use Zend feed the bridge class to allow Zend feed to use guzzle is then it's got 15 lines of code and that's what allows us to be trying to pull in the Zend feed library so that's just good general development practice anyway something that Drupal should be adopting more in its own code as well for organizations that have successfully used a direct specifically what I'm thinking of is we have a case where we have a lot of a language so basically my phrasing but actually those modules depend on a lot of other things so I'm just sort of wondering if anybody has actually used this since composer has a brilliant dependency tree and a construct dependencies from those projects as well since it has the scripts in there as well you can do some of these things with there's one project that would I guess we're really going to kind of say in particular so from my organization there's a lot of internal resistors we don't have any introducing new tools and so if somebody is writing a case study you can't see the name of the client yet large media organization as much as I can say so that includes on Drupal sites an elastic search server and a constant application built using Sinox and that's like anything else in the symphony world that I was using in Composer so the repository we're building for this client is a Composer.json file Composer.loc file our SMC directory we're then pulling in Scylex H2T Kernel H2T foundation Dozzle Event Dispatcher Elastica probably something else in there and they're cool with that but they are using it and so far they've had no problems with it I just think that I can watch your website for a case study or something like that probably, I mean Palencier.net keep an eye on the blog you'll probably end up on a Google plan as well you need to record it dude Eric says that MBC is using Composer.json for one of their huge projects awesome all of them for all of them so there's your endorsement as the subject and the big media corporation I mentioned is a different one I know you have a lot of tasks here that you guys want to do in the next couple of weeks and could this be a project that we would see coming if it doesn't make it to let's say code cutoff that would come into Drupal 8 at some point in the future that depends on how we run the Drupal 8 maintenance cycle and discussions about that are still open right now and installations for people that are not using the shell and modifying the build scripts on Drupal.org so that we don't have to check in our libraries to the repository and when you go to the tar ball on Drupal.org it'll download the libraries and that's the main things we need to happen please Palencier, I think we're just not out of time so thank you everyone for coming please do review this session and please take your waitress so much guys