[chef] The future of the database and application cookbooks

[William McVey < >]

I'm a fairly new user of Chef and the application cookbook, but I do
like the proposal for the application deployment (and database
deployment for that matter.) One thing I'd like to confirm though is
that the 'repository' and 'revision' fields would be optional. The
current 'application' deployment cookbook pretty much explodes in
error if you try to use it to deploy an application that is not
fetched from an revision control repository (a problem I wrote up in
ticket COOK-724). If in the example below, the repository and revision
fields were optional, and the packages to load (ideally both OS level
packages as well as 'python::pip' installation rules) could be
specified, then that would go a long way to making the application
cookbook usable in environments where there the codebase to install
isn't sucked out of a live repository.

 -- William

On Tue, Aug 30, 2011 at 10:39 PM, Noah Kantrowitz 
<
 >
 wrote:
> application "radiant" do
>  path "/srv/radiant"
>  owner "nobody"
>  group "nogroup"
>  repository "git://github.com/radiant/radiant.git"
>  revision "master"
>  packages ["libxml2-dev", "libxslt1-dev", "libsqlite3-dev"]
>  migrate true