Common drush cookbook

[patcon]

Hey Marius,

Just tracking drush and drupal developments as they relate to chef, and wondering whether it might be possible to host an actual drupal cookbook that depends on a separate drush cookbook. Seems you and Mark are both working on this separately?
https://github.com/msonnabaum/chef-drush

If I knew which project was the "official" one, I'd be interested in contributing a sub-recipe for drush_make, drush_clone, and maybe some drush tools. Might be nice to have drush depend on git, and pull in the most recent version from drupalcode.org by default, but the tag attribute could be overridden if someone wanted a different version.

[mdxp]

Hi Patrick,

I was not aware of Mark's work. I havn't seen a drupal cookbook on his repo, but probably it is just my bad not looking hard enough. In anycase, I don't think that any of the projects is more 'official' than the other; you should probably contribute to the one you like better and want to use yourself. Personally I don't have any problems in separating drush in its own cookbook. I created it in a simple recipe as it didn't make sense to have it separate from drupal (even though I planned to be able to install other drush tools like drush_make).

I'm not such a big fan of installing things in chef with git (because the most recent version will mean different things based on when you run and install it; it will cause inconsistency with servers deployed at different times). I usually like to have an attribute for the version and install that one (what I usually want to) and if others want they can change that attribute for other versions (the same as opscode do with their cookbooks). The recipe/cookbook should produce the same result regarless on when you run it, imo.

Regards,

• Marius -

[msonnabaum]

As Marius said, there isn't really an official one, but I do strongly prefer drush in its own cookbook. However, since I am one of the drush maintainers, I'm happy to commit to maintaining a canonical drush cookbook.

I do pull down drush from git in my cookbook and the potential issues that Marius outlined is why I have the default recipe that pulls the latest stable tag and then the dev recipe that pulls the latest from the drush5 dev branch. I'm happy to expand on these further and make the tag a variable however.

And although I think it might make sense to do a drush make recipe, anything past that suggests to me that there should be a drush provider, and then you specify which drush extensions you want in a role or a custom cookbook similar to how php modules work in the latest opscode cookbooks.

[patcon]

OK, so just to keep this from dying, if we were to take drush out into it's own cookbook, any thoughts on a roadmap?

I think it's a great idea to have a simple resource for drush extensions that need to be installed or symlinked into the commands dir.

I'm thinking it might also be helpful to think how drush aliases (or other files from the examples folder) might be implemented as resources or templates.

Thoughts? In the meantime, I'll work at getting something to show

[mdxp]

I hope to have sometime this week to work on this.

[msonnabaum]

Past the initial recipes in mine, I think it would make sense to provide a drush LWRP that could work similarly to the pear one. It could look something like this:

drush "drush_make" do
  version "6.x-2.2"
  action :install
end

[patcon]

ok, right on. Sounds right to me. But just to make sure that I understand correctly, this would only apply to modules that need to be installed in a non-standard (drupal) way, right? Like when they involve symlinking into the commands dir?

Also, might suggest something other than "drush" (ie. drush_plugin), since I can imagine other drush LWRP's appearing at some point :)

P

[msonnabaum]

Well, I don't know that they would be symlinked. In the case of an LWRP, we're treating drush as a package manage, so it's no different than apt in that respect.

If you want a suffix, I'd use either drush_extension or drush_command, but at this point we don't even have our own project type on drupal.org, so it'll be a very long time before drush has more than one extension type.

Although maybe I'm thinking of this differently. I'm thinking in terms of drush installing its own plugins like make, dog, deploy, etc. If you're talking about modules and themes, that gets into the existence of a drupal site, and then we've crossed the line from configuration into deployment. Not that that is outside the scope of chef necessarily, its just not something I do.

[patcon]

And yeah, I like drush_extension most. As for other resources, looking for a good place to figure out resources, and might give it a shot with drush_alias.

Totally agree with deployment statement. Definitely not thinking about installing site modules here :)