 Welcome everyone. The Drush maintainers are happy to talk to you guys about what's new for Drush 6. Little introductions. My name is Moshe Weitzman. I'm a longtime Drupal developer. Currently the Director of Research and Development at Acquia. Want to introduce two co-presenters. Jonathan Headstrom, further away from me, is the Director of Engineering at OpenSorcery and the maintainer of Drush Make. Closer here, Owen Barton, Director of Engineering at Civic Actions and maintainer of a bunch of different pieces. You'll hear about completion, Drush completion or Bash completion and Siteset and different other pieces that Owen has worked on. So the first major feature in Drush 6 is called output formats. All right, so just about all of the commands in Drush are now able to be formatted as you wish. The output from there can be formatted with JSON or CSV or INI, lots of different formats, YAML. Those are the four matters that we ship with. In addition, you're welcome to write your own plugins with other four matters. So the way that manifests is that you run a command. Let's say it's pm-list which lists out which of your modules are enabled and which aren't and what version they're at and all of that sort of thing. You can say dash-format equals CSV-list and then you're going to get a CSV listing. This is really handy when you're taking data out of your Drupal site and you're reusing it in a script. You can now get it in just the way that's useful for you. If you are authoring Drush commands, all you really have to do, you have to do two things. You remove the part of your command where you print out your data and instead just return that data back in your command callback. Drush will then take care of taking that data and presenting it to the user the way the user asks for it. So it's removing a line from your command callback. The other thing you have to do is in your command definition, I'll show you in a second, you have to add a little section to the array that tells Drush which formats you support and what your default format is. If you want to learn more about output formats, we have a topic in Drush. If you guys haven't explored the topic command, it's really useful. There's a ton of great documentation about Drush there. You don't have to, like, Google all over the place to find out things. Just run Drush topic. When you run Drush topic, it tells you all of the topics that the authors have written and it's a little bit like man. Really useful. So if you want to go directly to the topic about output formats, you can see it at the end of the slide there. Drush topic, docs-output-formats. So here's an excerpt of the command definition for the version command. This command is super simple. It just tells you what version your Drush is. In addition to saying what arguments and options your command supports, you have a new array key called output formats. It has two elements inside of it, the default and the pipe format. Default tells you if someone doesn't specify a format, here's how Drush should output the data. In this case, it's in a key value format. And if someone passes dash-pipe, this instructs Drush to format it as just a string. It exists on most of our commands and it's kind of like a handy way to get machine-readable output without having to think about what format you want it in. It's just give it to me in a format that makes sense. That's what dash-pipe is about. In this case of version, it would be the equivalent of passing dash-format equal string. So let's give you a little demo of output formats. Can you guys see that? It's too low, I see. Oh, it just looks good for me. All right, so the command I typed, you can see it down there at the bottom, PM-list and I gave it a format. If I do it without a dash-format, I get it in its standard table presentation. So that's an example of passing format, getting it back in the format you need. So that's a big JSON array. So that's output formats. Let's see if I can get the Google example going that I had before. Okay, so this command that I just did is going to be a little hard for you to read because there's a lot of stuff there. I use the command SQLQ, which means execute this query against my Drupal site and Drush takes care of how to connect to the database for this site and so forth. And I passed some instructions, dash, dash, extra to my SQL that said I wanted tab delimited formatting for my SQL query. The query I sent was simply give me the names and email addresses of the users from the users table. And then I went ahead and saved that to a temporary file and then uploaded that file to Google Spreadsheets. And so... I love it, Ezra. Yeah, so there was a question to see the command again. Let's do it like this. There. So you'll see the SQLQ at the beginning, then a query. And then I'd save to temp.tab file and then there's ampersand ampersand and then the command Google docs upload of that file. This command Google comes from an open source project called Google CL. And it seems to work. I started using it yesterday and it looks pretty cool. All right, thanks. Now you can mostly get it, right? Okay, so there's only one user in my users table, but there is that user. Okay? Now you can clap, Ezra. This works for other commands. I guess we can try one more after I narrow my terminal. Okay, so what I did was I ran PM-list again, which is that listing of modules and what their status is on this website. This is a Drupal 7 site. And I redirected that to a file and sent it to Google command to be uploaded. I think it didn't like that tab delimited. I should have done... I uploaded it with the .tab instead of a .csv file name. So that wasn't perfect, but there is a document here. All right, next feature that's new in Drush 6. We had a bunch of user commands in Drush 5. We added a full set of role commands. Okay? What you can do with the roles is you can create, update, list, delete for roles. And you can also add and remove permissions from those roles. And like you've had for a little while, you can add and remove users from roles. So there's really a good set of role-related stuff here. And I'll just give you a quick demo of that. Is it still spelled wrong? Administrate... Is that singular? Oh, good. Okay. The error handling could be better there. So what I typed, drrap, which is short for role-add-permission, you take the role that you want to operate on, authenticated user is the role, and the permission is access administration pages. So I just added the permission to the role. This is a local site, so doing something silly like this doesn't make any difference. And if you want to remove it, I think it's RMP, yeah, removed access administration pages, permission from the authenticated user role. All right. So Drush 6 is the first version to start supporting Drupal 8. We built in pretty nice support for the CMI subsystem, the configuration management subsystem. All right, so I'm going to show you one command out of a suite of commands that have to do with config. This terminal window. I have my drush command alias to just dr. That's why that's working. All right, so I entered the command cedit, which is short for config-edit. What this does is it takes any config file in your site and brings it up in your editor. You can go ahead and change it, and then it saves it back into Drupal. This is actually like a fairly convoluted process in CMI. You need to use the staging directory to stage your file, change a manifest, and import it into Drupal. Drush handles all of that for you. So this is actually quite a time savings to go ahead and do this one second. I'm just going to keep going. Okay, so if you pass cedit without any arguments, it offers you a listing of files that you might want to edit. My Drupal site has 134 files, config files. So we can just pick one. Let's say I'll pick the last one, which is the tracker view. Views is in Drupal 8 for people who didn't hear. All views are stored in the configuration system. They're CMI files. So instead of going to that nice UI, you can go to your editor. So let's check it out. I typed in number 134. I want to just edit this view. I don't recommend creating a view this way, but editing a view can be really handy. If I want to change the number of items per page, I save it, close it, and in great Unix fashion, it succeeded. I got no feedback, but I do know it succeeded because if I try it again, I'm running cedit. I'm going to pick the same file, 134, and now there's 50 items per page. So all your configuration in your site is easily managed just with cedit. You can pop open the files, change them, and it gets imported back into your site. All right, Benji. Oh, the editor. Yeah, I think it does. I think it does. I think there's some equivalent to the editor function that Windows has. Yeah. Okay, keep going. Here's a Drush 5 innovation that I just don't think a lot of people know about or use, so I want to mention it again. We added something called shell aliases to Drush. So in your Drush RC file, which is your configuration file for Drush, you can set up a simple array of short names and what command they might map to. Okay. This is completely analogous to Git aliases in Git's configuration file. So here's two examples. I have a command Drush non-core, which I invented. It resides on my system and it maps to pm-list-no-core. All right. Again, another one, pulldb. Executes two different commands. The first one is a Git pull, and the second one is a Drush updb, which updates my database. So get my new code and run all my pending updates. All right, this exclamation point at the beginning of the word Git tells Drush that this is not a Drush command coming up. It's actually just execute this as raw bash. Okay. Here you can see the shell aliases array in my Drush RC file, and you can see just how easy it is to add and remove things there. Okay. Because it's defined in Drush RC file, it's not only for personal use. You can put Drush RC files up on a server in a shared location, so all your Unix users are going to share the same aliases. You can also put aliases into your Drupal site, into your Git if you want to, and share them there. So there's definitely lots of different ways that teams can share site aliases as well. All right, with that, I'm going to hand it over to Jonathan for Drushmake. How many people here are familiar with Drushmake? Awesome. All right. So I'm going to cover, well, first I'll go over what Drushmake is. It essentially allows you to create a manifest of the themes, modules, and libraries that your site needs in order to run. So here we have an example, just a very quick one showing you can specify a version of a module. You can patch modules. So we have views and C tools. It's sort of an alternative, or the way we use it anyways, an alternative to storing big blobs of contributed code redundantly in our own create repositories. Instead we just store the make file which gives Drush everything it needs to pull down the code to build out the Drupal site. There were some really, in Drush5 we introduced Drushmake into Drush. It was previously a separate project. In Drush5 there were several really cool innovations. One of them is concurrent downloads. So if you have, say, 100 modules and you specify a concurrency of 20, you'll download 20 modules at a time. The other really big win in Drush5, or yeah, in Drush5 was caching. So instead of actually downloading Drupal 7.22, you know, 20 times a day, it'll download it once and then the next time you need to download it, you'll have it cached locally. That also works with git. If you're not using a working copy, the cache will use git reference to cache to store the repository and then the next time you run the Drushmake file, it will look if there's any upstream commits and pull those down. So that saves a lot of time, particularly with Drupal Core, which is now quite a big git clone. Okay. Were you guys able to hear any of the stuff I just said? Okay. So I'm going to talk about things that are new in 6now and a lot of these have actually been backported to 5. There's now the ability to use local patches and the patch itself is actually copied straight into the project directory. For most use cases, I would encourage people not to use local patches because at a certain point you get into basically having a forked or hacked module, but there are some legitimate use cases. You know, for instance, if you need a custom htaccess file, that's a really good use case for a local patch. And with the copying into place, if someone in the future decides they're not going to use Drushmake anymore, you still have that patch accessible. This is a subtle change. The ability to use a distribution as a core version. Previously, what happened is you would specify the version of core you wanted to use and Drushmake would grab that as a separate process and then it would build your distribution. The reason this change was necessary is even though this is shortened to kickstart here, this was introduced by Damian for commerce kickstart. And in the previous way it worked, if you had core patches that were necessary for your distribution, Drushmake wouldn't grab those. You would have to re-specify them by doing it this way when you specify a distribution of core, you no longer have to redundantly specify those core patches. So you could, this code you're seeing right here would download all of the modules necessary to run commerce kickstart and then if you wanted a few more modules you'd just add those below or if you wanted a different theme or some new jQuery libraries. QuickDrupal, which I think Owen is going to demonstrate, basically allows you to download Drupal, spin it up without Apache, it just runs its own little HTTP server. In Drush six now you can use a makefile with QuickDrupal so you could build out a bunch of modules and then just type drushqd and then point it at the right makefile, it would download everything it needs, run it site install and you'd be up and running in a browser. Drushmake has long had the ability to specify a working copy, meaning if you have a bunch of git repos say you're actively working on some modules it would pull down the git repository itself so you could go in there and then make patches against modules. In Drush six, you can now specify in the makefile that you want specific projects to be working copies and others not to be. So in this case if you were working on a module called cap which we shortened to make the slide fit this would download an active git repo and you could make patches or commits if you had access to do that. This is one of my favorites for people who have been working with makefiles for a long time and wanting to store contrib modules in a separate sub-directory called contrib you used to have to do it the way it's done there at the bottom where each project had a sub-directory of contrib you can now do in one line at the top of your file set project defaults which basically cut the size of makefiles in half so I like that one a lot and I believe you guys see that raise this up a little bit okay so I was going to start off by demoing quickdruple and run server which if you were in Denver you may have seen before but I think a lot of people still don't know about this and it's pretty handy so just explain what these two things are so quickdruple is essentially if you've used like simply test me if you guys know about that it's like a web service you can demo a module very quickly it's a little bit like that except it's purely driven by drush so it takes a lot of shortcuts so for example by default it uses SQL Lite so everything ends up in one directory you don't have to like clean up my SQL databases it it has a it can use the the built-in run web server so that's what core run server or RS is and you can run this on any site you don't have to use it with quickdruple I'm just showing them at the same time because they use each other so run server is uses either the PHP CGI binary which is available on a lot of systems not all of them or it also works with the built-in web server in PHP 5.4 so if you have either of those you should be able to use this it's super easy to use if you're used to like setting up a v-host every time you add a site you no longer need to do that you just CD into the site directory or use an alias and just do RS and it pops up a web server right there so let me just show you what these look like so I'm just going to go into temp you know quickdruple I would say is it's not a substitute for make make is designed primarily for building things you care about to keep it's potentially production you're going to do work on it quickdruple is much more around something throw away or something I originally conceived as something that might be useful for training so somebody who's new to drupal has to learn not only drupal but they're learning Apache, v-host they're learning MySQL they're learning file permissions they're learning all this stuff whereas it would be nice if people just had to install a working PHP and could just run one command and start learning drupal rather than installing all this other stuff so to run it you just run quickdrushqd I'm going to show a slightly more advanced command so you can give it a site name I'm just going to call it demo if you don't give it a site name it just uses a timestamped directory and if you want you can give it any number of counter modules so I'm just going to use admin menu so let's say I want to show somebody hey you've never seen admin menu let me show you this this will include admin menu but it also works for distributions the themes and it will enable them if it can work out the name so if I just run that it's downloaded drupal actually it's using the cache drupal it's installing it I'm just going to move my browser window here so you can see it's enabling the module it's starting the web server and there's my site so pretty handy like no configuration no dependencies it doesn't need to know your root password that's the whole thing it takes away a lot of the hassle of just building a quick drupal site you can see it shows the log of all the accesses it will show errors on here this will also show if I just create a node you'll see if you look very quickly I will scroll up so you'll see there we go so it also captures watchdog so it's really handy for watchdog you don't have to go and dig up your Apache logs you have the window right there it's always updating it's like tailing the Apache PHP logs as you go so it's pretty fun quick drupal has a whole ton of options it uses a whole bunch of commands under the surface all of those commands you can alter the options if you want dev versions if you want a particular install profile you can choose that it works with commerce kickstart even pretty complex things that we'll work with run server has a couple of interesting options I think one of the main ones you may need to know about is the port so by default it'll come up on what's that let's see my browser window is too small by default it comes up on 8888 848 and but you may want to choose a different port if you have Java running on there or something you can put into your own port you can run multiple servers at a time on different ports if you have multiple sites you're working with okay I'm going to show something else this is something I don't think we've demoed before but it's really super useful and something I'd use pretty much every day now it's called to the site set command what this does is if you use generally people use drush in either one or two ways they change directory into the sites directory and sometimes into the site slash something or other directory so that drush picks the right site or they use aliases and every single command they have to retype the alias and neither of those is really great especially retyping the alias I mean it's kind of a disincentive this is really simple if you're doing a lot of work so essentially it persists to site so if I I'm just going to go straight into the demo here so if I can you guys see my let me close my browser so if I'm just in temp and I just do drush status I don't get anything back I'm not using an active site I'm just using drush on its own if I run site set so I'm going to run site set local so at local at local is a local alias so this is something I have set up in my drush RC and now if I run oops drush drush drush status you'll see I'm in my site I've got my database I've got theme I can see everything so now if I'm running commands I'm running them on this site and those of you who are observing carefully will observe the site alias is in my prompt now this is super super important especially if you do site set on a production site because if you do site set on a production site it's very easy to forget that you are working in a production site and accidentally do drush site install or something like that and you'll have a phone call very quickly and it won't be a good one so so it integrates with your prompt really I'd say pretty much a prerequisite for using this at all you can see I use I have it here basically the command to use this is you put something like this in your in your bash RC and it calls essentially this is the standard prompt you know host name and username and whatever it's pretty cryptic looking but then you call this under under drush ps1 function and what that does is that it looks up the active site and these I should say these sites are active per terminal session so if you have a bunch of tabs open it's not site wide right so you can have one tab that's set to your local site and one site that's set to your QA site so you do a commit you know push it you know pull on the QA site and run features revert and so it's per per terminal window like it looks at the source and works out what that is so if I but this this is what this prompt looks like so I've got my my prompt and square brackets here to get this function you also need to have the drush.complete.sh in your bash RC if you want to use auto completion you should already have this it's super helpful so you just saw so you can put a dot and then you put the dot and then you can run the and just a demo I'll see if my network works but this does work with remote aliases as well so here I'm this is a remote alias if I do drush status on here this is not running locally you can see it's taking a little bit longer yeah you can see this is this is the life this is a production site so that's drush set yep yeah it should work with pretty much any command that works remotely should work fine when you're done you do drush site reset and it goes away so pretty straightforward easy to use make sure you set up the prompt there's another one the drush user login command or ULI most people call you run ULI and you run ULI a lot I pretty much always use ULI every time I get to a site and we've added some things to this that make it a lot faster just a lot cooler so I'm going to site set to local and if you've never used the ULI command what you'll use to so I'm just going to log out here otherwise it's not really showing very much actually I'm in a different site anyway so what it previously showed if you use ULI and drush 5 is it just prints the link to log into the site you know this is a password reset link and so now if I do drush ULI it doesn't only print it prints the link but it also opens the site in the browser and logs me in so but it does a couple of other things so I can do drush ULI you can pass in the user ID so you can do a number you can do a name you can do an email address any kind of user identifier and then you could put a path so admin content node for example so if I do this it's going to log me in and put me in this path so let me just log out it works even if you're not logged out but log in you can see it redirects and I'm on admin admin content node so super handy you want to go you don't want to like log into the site and then have to browse around full links down you can just type the path you want to get to okay that's how we do it I think we do yeah we got time so completion again this is something I demoed we demoed in Denver the this has one piece of setup which I already mentioned which is making sure the drush.complete.sh file is sourced in your bash RC and that makes available a completion function that calls drush when you type a command starting with drush so let me just show what that looks like um I'm sure most of you familiar with completion basically you just type tab let's see yeah let's just do s so it's going to show me all the commands that start with s si tab sit so it knows if it starts with sit it's going to be a site-something command but then it asks me which ones so I can continue um so this works pretty much everything for aliases it works for commands it works for options and it works for most command arguments as well um and it's pretty easy there's a hook you can include in your command files to provide completion for that command and essentially you just provide a list of all possible arguments to that command um the reason for that is drush caches all the completions so that if you're working in a site and it takes a couple of seconds annoying if it has to do that every time you want to complete so we cash all the completion output so the next time you hit tab which is normally a second later it's almost instant so uh the other thing with completion is the options um rather than list every option everywhere um which is you know a little unwieldy what we decide is we put global options first global options so we've got you know the root and debug and so on and then if we go um let me use uli if we go after the command we only show the command specific options this is the same set up as get users so if you used to get uh this will come pretty naturally so you can complete the net the command that way um oh did I close the window oh it's uh popped up back here so I think that's it completion uh should we yeah let's have questions if you could come and line up for the mic thanks very much alright just before the first question just one second um I want to let everyone know that there's a group doing um doing support for the Oklahoma tornado disaster okay room voters are kind of getting ride board set up and other things like that so if you're inspired please go join that team is this stable enough to just be used as just our main drush or do we still want to use drush 5 usually okay good question um you know I can say that all the drush maintainers definitely use um the uh master branch or general um I would say drush is stable um to stay that way definitely for drush 6 I would encourage it now to go ahead and start using drush 6 um we did a if you want a stable release there is a beta one out you could use that or you could just stay with us um on the branch up to you but I would say it's ready hi um lots of cool stuff here question I guess um is it possible to disable the browser firing up automatically because I use multiple browsers and it's it opens in the browser I don't want it to open in because I dab in a different browser so yep yeah it's possible so uh so there is a a dash dash browser flag and probably what you want to do is set that in your drush rc okay if you always want to use a particular browser I would say also if your system browser set correctly it will it will use that okay and of course you could do dash dash browser equals firefox or dash dash browser equals chrome or chromium or whatever you want and it will use that for a particular command awesome thanks I had a question about um the drush site set is it actually changing to that active local dev directory or is it running an alias behind the scenes the whole time it so uh so the way it works is we basically we store a file in the temporary directory by the parent process of drush so in other words the process of your bash right that you are interactive in uh so it and then whenever you run a drush command it goes is there an environment file for this process cool and if there is it will use that so it's like typing the alias in the command name um but it's transparent you don't need to be in the directory you don't need to be on the same host even cool and then the second question was could you show us a little more yeah okay so there's an alias that actually comes with drush um called unsuck and it disables the dashboard and the overlay modules um yeah it's in the array by default it is in the shell aliases array that's commented out in example.drushrc.php yeah um and the dashboard module is no longer in triple eight so we got rid of one of them yeah go ahead next um I went looking and there is some bhat drush support and I'm just wondering if you tested that with the um the new core server that's going ahead and running locally I mean can we essentially at this point do complete testing entirely from drush where it brings up its own web server tests all the things against it and basically comes back and says yes your commit did not go ahead yeah you'll need you know obviously it runs as a persistent process the web server so you'll need a little bit of trickery you know you'll want to do it as a bash external bash script to bring up the server and then kill it afterwards um but it should work yeah I mean it's pretty solid um you know if you want to test in your you know environment very similar to your production environment it's probably not ideal for testing like you know smoke testing it's pretty good and uh it doesn't with simple test in particular it doesn't complete all the all the core simple tests there's a few little deep internals of Drupal that don't pass in the browser because it's mostly like CGI environment settings I also say those also don't work in an Apache configured with CGI either so it's a core issue really it's nice to know that it's stable and we can go ahead and use it that you guys are using it on a daily basis just wondering about backwards compatibility a little while ago it seemed you couldn't use Drush 6 to maintain like a Drupal 6 site I wish we weren't but we're still hosting some Drupal 6 sites I was just curious about that yeah so Drush 6 is intended to work on both Drush 6 and Drush 7 so if you hey this may just be me being daft but especially with site aliases I've had trouble using shell aliases to combine multiple Drush commands are you able to do that or you are able to do that yes so I can't think of a reason why they would fail but you know I'd have to see what your errors were and try to figure out what's happening but you know with ampersands and it should work just use our thank you maybe yeah are you thinking of changing Drush Make to use YAML syntax you know jump on the YAML bandwagon yeah we were talking about that yesterday and we'd like to do it but we'd also like there to be a reason to do it so people don't just have to rewrite all their things so it's on the list of ideas if I wanted to use Drush 6 on a Makefile that was generated with Drush 5 would that be backwards compatible yeah we have not changed the API it's still API 2 sorry I came a little late but I was wondering is there a way to generate a Makefile where I'm basically gonna say always use Git to as the download method and basically check against because I'm using Git as the download method and providing a revision that when I do a validation for this that I'm actually using stable commits that are maybe coming after a more say release so that basically what's happening to me right now is I'm seeing security updates that I don't need for my site because of the way that I am downloading the modules generate I believe there's an issue in the issue right now for generate Make to do that to set up your Makefile with a you know pointing at a Git revision instead of checking out a version but that hasn't been committed yet and I don't think there's a patch I think there's some discussion about ways to make that work but yeah I'd encourage you to go look at that issue and if you have more use cases or you know details on what you're trying to do generate Make command or about Make in general it was two questions really it was generate Make to potentially generate a Makefile in that fashion so that say distribution like Panopoly that uses specific branches of you know modules and things like that are when installed don't show up as hey this site has a bunch of security errors and that was another issue that one should have been fixed there was a problem it would get revision it would write the version string as blank in the info file which caused Drupal to really freak out about that module but it should now say it should be the same as if you download a DevTarball it should say you know 7.x 1.1 plus 23 commits or something like that so if the modules is downloaded for you soon if I change the module from 7.x 1.1 to 1.2 to have Drushmake download the new one you mean if you edit the make file or if you run Drushup have it edit the make file for you I mean if I go and edit the make file and say okay I want to get everything that's in here and leave the rest of it alone there is a flag for Drushmake but it should be in the help file but is there something to say find the newer projects that have updates in the make file and download all those or would I have to do it for a project you mean using something like Drush PM update no I mean just for downloading the modules themselves that have just for it to know which ones have changed yes I can say you know these five have changed the patch there people have talked about integration PM update okay thank you there is definitely an open issue on that and I can't remember all the discussion but I think there was a reason why it was hard so just maybe help out in that issue so and Drush make is there a way to now include a patch file let's say as part of the module in the give repository so that when you get a patch let's say as part of the module or from get and then you run it instead of setting it up let's say in GitHub making it a public repository and then getting the role version of the patch are you talking about a private patch I don't fully understand the question yes one of the issues we run into with Drush make is actually including so when you get it out of GitHub that it runs the patch I mean is that possible to do now you mean have it include the patch as part of in the module directory yeah so it doesn't do that yet that's been on I would like it to do that actually it does that for the local patches just because a local patch in a make file is quite if it's just referencing a file that's not very useful yeah got it thanks hi I don't know if there's a quick suggestion for this one but in terms of completions I've noticed that if I have anything to the right of my prompt like I'm editing an old command and I hit tab for instance I'm trying to complete an alias I get all kinds of craziness on the screen I have to reset the terminal do you have you seen this before I don't think so I mean but okay it's also just try so I'll upgrade to just 6 and see yeah try upgrading if you don't add a bug make sure you add what setup you're using what shall and so on does just wrap have like a wild card so I can add all administrator permissions to the administrator role yeah the question was about role add permission and about wild cards wild card support like that Drupal has wild card support ish for an administrator role but yeah I don't think that we we went quite that far with wrap okay thank you guys I'm afraid this is a stupid question but I'm going to ask it anyway I'm not using Drush Make at all because it seems like something that you're going to use to provision a lot of websites based on a template or something I'm not sure it really serves when you're maintaining one or you know a few production sites and you're just maintaining them am I wrong is there some use case yeah we actually use it on every project and some of the benefits you get are you won't see a massive commit that updated say 10 contrib modules and then they did some custom code in the same commit because contrib is just not part of the repository only one site it's worth using because you're not you're your repository at that point becomes much cleaner you're only seeing your custom code your custom theme and then the make file which is a few hundred lines long so when you're doing an update you'll do Drush Make to like it'll pull code from the get repo instead of your own repo yeah the way we use it Drush Make the file when we update modules we rebuild out all the directories and everything was is that your does that address your question or I mean you're wondering if it's worth using just for one off well I'm not sure what we have right now is everything's in our repo and we upgrade a module so we commit it and then we put on the production server you're saying I would use and still keep everything in the repository it allows another really good I mean a make file provides a quick overview of the modules you're using so even if you do check all of them into the repository I'd argue that it's still worth using that to build out your modules and keep track of the versions and patches that you're using okay thanks I think part of the question was around if I've got this right was about like if you have an existing site how do you how do you deploy that do you rebuild the site and switch simlinks or that's how we do it I mean it takes a bit of doing to do that there's not a lot of documentation about that in Drushmake itself but there are blog posts about you know sort of switching to that mindset of you know using a make file as basically your deployment mechanism rather than just a get Drushmake as provisioning system yeah people can just come right up to the desk care and we'll answer questions last thing I want to remind people is please go ahead and give us feedback go to the Drupalcon site slash schedule find the what's new in Drush6 and please give us feedback thanks