berkshelf / berkshelf Goto Github PK

View Code? Open in Web Editor NEW

1.1K 57.0 315.0 6.87 MB

A Chef Cookbook manager

License: Other

Ruby 78.95% Gherkin 21.05%

berkshelf's Introduction

Berkshelf

Manage Chef Infra cookbooks and cookbook dependencies

Warning

Berkshelf is effectively deprecated. There is no ongoing maintenance and triage of issues. No active work is being done on bugfixes. The only work being done is to maintain it so that it continues to ship and run in its existing state.

Existing users should strongly consider migrating to Policyfiles and new users should avoid using Berkshelf.

Installation

Berkshelf is now included as part of the Chef Workstation. This is fastest, easiest, and the recommended installation method for getting up and running with Berkshelf.

note: You may need to uninstall the Berkshelf gem especially if you are using a Ruby version manager you may need to uninstall all Berkshelf gems from each Ruby installation.

From Rubygems

If you are a developer or you prefer to install from Rubygems, we've got you covered.

Add Berkshelf to your repository's Gemfile:

gem 'berkshelf'

Or run it as a standalone:

$ gem install berkshelf

Usage

See docs.chef.io for up-to-date usage instructions.

CLI Usage

Berkshelf is intended to be used as a CLI tool. It is not intended to be used as a library. Other ruby code should shell out to the command line tool to use it.

Supported Platforms

Berkshelf is tested and supported on Ruby 2.4 and later.

Configuration

Berkshelf will search in specific locations for a configuration file. In order:

$PWD/.berkshelf/config.json
~/.berkshelf/config.json

You are encouraged to keep project-specific configuration in the $PWD/.berkshelf directory. A default configuration file is generated for you, but you can update the values to suit your needs.

Shell Completion

Bash
ZSH

Plugins

Please see Plugins page for more information.

Getting Help

If you have an issue: report it on the issue tracker
If you have a question: visit the #chef or #berkshelf channel on irc.freenode.net

Authors

Thank you to all of our Contributors, testers, and users.

If you'd like to contribute, please see our contribution guidelines first.

berkshelf's People

Contributors

Stargazers

Watchers

Forkers

lastobelus benattar whitepages tknerr miketheman liku slantview jackl0phty gnomeslab dwradcliffe englishm fungibleclouds andruby arangamani chrisroberts rberger hh schisamo vollnhals rectalogic togaurav botimer bdemers dasch bryanwb justincampbell blasdelf simonmd robbkidd jonathana outstand bakins stevenhaddox rb2k venturaville josephholsten colinrymer anbiniyar m00gs skorfmann leknarf appliedcode tylerflint jasondunsmore gad0lin sstrato jflowers ugf dgtm hnakamur danshultz whiteley nelsonjchen curzonj jastix jordandm doap 3dinfluence timops fgrehm jkeiser montague earzur jeremyolliver thommay danryan kppullin krmichelos ryansouza maoe dldinternet pikajude b-dean mylons riotcku hitonoou robotblake hamled alteryx pghalliday bobziuchkovski craigtracey kainosnoema kashook eklein douglaswth rtsai123 danleyden caryp-contrib cjerdonek iroller bytheway mauriciosilva grobie rylarson jclyons swrobel aspring markgibbons rarenerd

berkshelf's Issues

berks install --shims /tmp/cookbooks should detect new files

This how berkshelf currently works

$ cd my_cookbook
$ berks install --shims /tmp/cookbooks 
$ ls /tmp/cookbooks/my_cookbook
 /tmp/cookbooks/my_cookbook
$ touch foo.rb
$ ls /tmp/cookbooks/my_cookbook/foo.rb
no such file
$ berks install --shims /tmp/cookbooks
$ ls /tmp/cookbooks/my_cookbook/foo.rb
no such file

berks install --shims should either detect new files or a new option like berks update --shims is needed

Thanks again for the awesome library! I am loving it!

Can you release 0.6.0-beta4, which has Windows bug fixes I need?

I will definitely still be testing master to help out, but I would like to get my team using Berkshelf and they suffer through Windows desktops like I do.

The specific fix I need is the fix for issues #182 and #183. Also, I did just test a vagrant up with the latest master (4bfe146) and it works fine on my Windows setup.

Should allow shims directory to be in subdir of a cookbook using metadata

Currently, Berkshelf complains and refuses to allow a shims directory that is inside the cookbook directory, if the Berksfile is using metadata, saying that a directory cannot be linked into itself. However, we link files, not directories, so this should not actually be a problem.

Using a shims dir inside the cookbook is very helpful for Vagrant testing of cookbooks,

Vagrant Plugin Fails When Upping >1 VM

First off, thanks for the Vagrant integration! It's super awesome!

I was testing it out today and noticed that, unless I'm completely botching something here, it seems to fail when my Vagrantfile defines more than one server. For example, a single node definition works fine:

require "berkshelf/vagrant"
Vagrant::Config.run do |config|
    config.vm.box = "centos6"
    config.vm.box_url = "http://c338540.r40.cf1.rackcdn.com/centos6.box"
    config.vm.host_name = "yum1"
    config.vm.provision :chef_solo do |chef|
        chef.add_recipe "yum"
    end 
end

However, if I put the VM in a config stanza (in order to add additional VMs)...

require "berkshelf/vagrant"
Vagrant::Config.run do |config|
    config.vm.define "yum1" do |yum1_config|
        yum1_config.vm.box = "centos6"
        yum1_config.vm.box_url = "http://c338540.r40.cf1.rackcdn.com/centos6.box"
        yum1_config.vm.host_name = "yum1"
        yum1_config.vm.provision :chef_solo do |chef|
            chef.add_recipe "yum"
        end
    end
end

...then Berkshelf never runs and I get an error about the yum cookbook not existing. This also occurs if I add a second node, etc.

Finally, when using a combination of global and single instance configs...

require "berkshelf/vagrant"
Vagrant::Config.run do |config|
    config.vm.define "yum1" do |yum1_config|
        yum1_config.vm.host_name = "yum1"
    end
    config.vm.define "yum2" do |yum2_config|
        yum2_config.vm.host_name = "yum2"
    end

    config.vm.box = "centos6"
    config.vm.box_url = "http://c338540.r40.cf1.rackcdn.com/centos6.box"
    config.vm.provision :chef_solo do |chef|
        chef.add_recipe "yum"
    end
end

...Berkshelf runs, but causes Vagrant to error out, seemingly due to a nil being passed around as a global host_name...

[yum1] Matching MAC address for NAT networking...
[yum1] Clearing any previously set forwarded ports...
[yum1] Forwarding ports...
[yum1] -- 22 => 2222 (adapter 1)
[Berkshelf] installing cookbooks...
[Berkshelf] Using yum (0.8.2)
[yum1] Destroying VM and associated drives...
/usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/provisioners/chef_solo.rb:118:in `expand_path': can't convert nil into String (TypeError)
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/provisioners/chef_solo.rb:118:in `block in expanded_folders'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/provisioners/chef_solo.rb:108:in `each'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/provisioners/chef_solo.rb:108:in `expanded_folders'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/provisioners/chef_solo.rb:68:in `prepare'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/provision.rb:25:in `block in call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/provision.rb:25:in `map'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/provision.rb:25:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:84:in `block in finalize_action'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:84:in `block in finalize_action'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/forward_ports.rb:24:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_port_collisions.rb:42:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/env/set.rb:16:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/clear_forwarded_ports.rb:13:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/clean_machine_folder.rb:17:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/validate.rb:13:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/vagrant/action/validate.rb:25:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/check_virtualbox.rb:23:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/match_mac_address.rb:16:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/default_name.rb:17:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_guest_additions.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/import.rb:31:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_box.rb:28:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/validate.rb:13:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/check_virtualbox.rb:23:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/builder.rb:92:in `call'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/runner.rb:49:in `block in run'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/util/busy.rb:19:in `busy'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/runner.rb:49:in `run'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/vm.rb:192:in `run_action'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/vm.rb:145:in `up'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/up.rb:31:in `block in execute'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:116:in `block in with_target_vms'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:111:in `each'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:111:in `with_target_vms'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/up.rb:24:in `execute'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/cli.rb:42:in `execute'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/environment.rb:167:in `cli'
from /usr/local/Cellar/ruby/1.9.3-p194/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/bin/vagrant:43:in `<top (required)>'
from /usr/local/Cellar/ruby/1.9.3-p194/bin/vagrant:23:in `load'
from /usr/local/Cellar/ruby/1.9.3-p194/bin/vagrant:23:in `<main>'

In each instance above, my Berksfile is simply "cookbook 'yum'" and I'm running Vagrant 1.0.5. If anyone has any thoughts, I'd love to hear them. Or, if I'm an idiot for trying to do this, that's a valid answer too.

Thanks bunches and rock on!

`berks version` runs extremely slowly

Trivial issue, I suppose, but a curious one:

https://gist.github.com/3902918

berks version takes a full 5s to run on my machine.

vagrant plugin doesn't work when vagrant installed via vagrant omnibus installer

the vagrant plugin doesn't seem to work when vagrant installed via vagrant omnibus installer

I am using berkshelf 0.6.0beta2

i have tried running vagrant gem install --pre berkshelf but that doesn't suffice

Unable to run berks install

Trying our Berkshelf and having some issues getting started. I run

berks install

and I get the following:

19:14:30 (development) [email protected] tropo-gateway master ? berks install
Using tropo-gateway (0.2.3) at path: '/Users/jdyer/Dropbox/Projects/chef/site-cookbooks/tropo-gateway'
Installing jmxsh (1.0.0) from git: '[email protected]:voxeolabs/jmxsh-chef.git' with branch: 'master'
Installing prism (2.9.1) from git: '[email protected]:voxeolabs/prism-chef.git' with branch: 'master'
/Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/dep_selector-0.0.8/lib/dep_selector/selector.rb:123:in `rescue in block in find_solution': Unable to satisfy constraints on package tropo-gateway due to solution constraint (tropo-gateway >= 0.0.0). Solution constraints that may result in a constraint on tropo-gateway: [(tropo-gateway >= 0.0.0)] (DepSelector::Exceptions::NoSolutionExists)
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/dep_selector-0.0.8/lib/dep_selector/selector.rb:84:in `block in find_solution'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/dep_selector-0.0.8/lib/dep_selector/selector.rb:82:in `each_index'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/dep_selector-0.0.8/lib/dep_selector/selector.rb:82:in `rescue in find_solution'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/dep_selector-0.0.8/lib/dep_selector/selector.rb:67:in `find_solution'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/solve-0.2.1/lib/solve.rb:36:in `block in it!'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/activesupport-3.2.8/lib/active_support/core_ext/kernel/reporting.rb:89:in `block (2 levels) in quietly'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/activesupport-3.2.8/lib/active_support/core_ext/kernel/reporting.rb:43:in `silence_stream'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/activesupport-3.2.8/lib/active_support/core_ext/kernel/reporting.rb:88:in `block in quietly'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/activesupport-3.2.8/lib/active_support/core_ext/kernel/reporting.rb:43:in `silence_stream'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/activesupport-3.2.8/lib/active_support/core_ext/kernel/reporting.rb:87:in `quietly'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/solve-0.2.1/lib/solve.rb:36:in `it!'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.5.1/lib/berkshelf/resolver.rb:90:in `resolve'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.5.1/lib/berkshelf/berksfile.rb:342:in `install'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.5.1/lib/berkshelf/cli.rb:65:in `install'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.5.1/lib/berkshelf/cli.rb:10:in `dispatch'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.5.1/bin/berks:6:in `<top (required)>'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/bin/berks:23:in `load'
  from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/bin/berks:23:in `<main>'

My Berksfile is pretty straight forward:

 chef_api :knife
#site :opscode

metadata
cookbook 'jmxsh', git: "[email protected]:voxeolabs/jmxsh-chef.git", branch: "master"

cookbook 'prism', git: "[email protected]:voxeolabs/prism-chef.git", branch: "master"

And my metadata.rb has no version constraint:

maintainer       "Voxeo Labs ©2011"
maintainer_email "[email protected]"
license          "All rights reserved"
description      "Installs/Configures tropo-gateway"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          "0.2.3"

depends "prism"

Any ideas whats going on ?

Additional config options for `berks cookbook create`

Additional flags should be provided to the berks cookbook create command that will configure the generated Vagrantfile. The fields in the Vagrantfile which should be configurable are:

config.vm.host_name
config.vm.box
config.vm.network
chef.chef_server_url
chef.validation_client_name
chef.validation_key_path

How do I wrap Berkshelf CLI ?

Hey Guys,

First off again I would like to say how much I love this project, it's really changing the way our team is developing cookbooks. We owe you many many beers ! So I have a question on Thor and Berkshelf. I am not to familiar w/ Thor, and I am playing around w/ it and having what I believe are fundamental misunderstanding about its use. In short what I am looking to do is create my own tasks which will run the install command w/ the -p flag

thor berkshelf:install -p some/path

The plan is to then tar up this dir, version it, and then upload it to S3. however I am having troubling instantiating the Berkshelf::Cli class.

This is what I have right now:

# encoding: utf-8

require 'bundler'
require 'bundler/setup'
require 'berkshelf/thor'

class Solo < Thor
  desc "package", "package cookbook"

  def package
    cli = Berkshelf::Cli.new
    cli.invoke(:install)
  end

end

And here is my glorious exception:

/Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.6.0.beta3/lib/berkshelf/berksfile.rb:12:in `read': can't convert nil into String (TypeError)
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.6.0.beta3/lib/berkshelf/berksfile.rb:12:in `from_file'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.6.0.beta3/lib/berkshelf/cli.rb:69:in `install'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/berkshelf-0.6.0.beta3/lib/berkshelf/cli.rb:10:in `dispatch'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/invocation.rb:109:in `invoke'
    from /Users/jdyer/Dropbox/Projects/chef/site-cookbooks/tropo-gateway/Thorfile:13:in `package'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/task.rb:27:in `run'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/runner.rb:36:in `method_missing'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/task.rb:29:in `run'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/task.rb:126:in `run'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/invocation.rb:120:in `invoke_task'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor.rb:275:in `dispatch'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/lib/thor/base.rb:425:in `start'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/gems/thor-0.16.0/bin/thor:6:in `<top (required)>'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/bin/thor:23:in `load'
    from /Users/jdyer/.rvm/gems/ruby-1.9.3-p286/bin/thor:23:in `<main>'
16:18:45 (development) [email protected] tropo-gateway master ?                                                                       1 ↵

Appreciate any help you guys can provide. Thanks!

-John

Access knife config in Berkshelf Thor task

So this might once again not be your concern, but I figured what the hell, and I would ask here :). So I am trying to use Chef::Config inside a Thor task in my Berks managed cookbook.

My test is pretty simple:

class Solo < Thor
  desc "package", "package cookbook"

  def testing
    say Chef::Config.inspect
  end

end

The problem is that I appear to be getting the wrong knife.

{:enforce_path_sanity=>true, :formatter=>"null", :authorized_openid_identifiers=>nil, :authorized_openid_providers=>nil, :openid_cstore_couchdb=>false, :openid_cstore_path=>"/var/chef/openid/cstore", :client_registration_retries=>5, :cookbook_path=>["/var/chef/cookbooks", "/var/chef/site-cookbooks"], :script_path=>[], :sandbox_path=>"/var/chef/sandboxes", :checksum_path=>"/var/chef/checksums", :couchdb_database=>"chef", :couchdb_url=>"http://localhost:5984", :file_cache_path=>"/var/chef/cache", :file_backup_path=>"/var/chef/backup", :user=>nil, :group=>nil, :umask=>18, :http_retry_count=>5, :http_retry_delay=>5, :interval=>nil, :json_attribs=>nil, :log_level=>:info, :log_location=>#<IO:<STDOUT>>, :verbose_logging=>true, :node_name=>nil, :node_path=>"/var/chef/node", :diff_disable=>false, :diff_filesize_threshold=>10000000, :diff_output_threshold=>1000000, :pid_file=>nil, :registration_url=>"http://localhost:4000", :template_url=>"http://localhost:4000", :remotefile_url=>"http://localhost:4000", :search_url=>"http://localhost:4000", :chef_server_url=>"http://localhost:4000", :role_url=>"http://localhost:4000", :client_url=>"http://localhost:4042", :rest_timeout=>300, :run_command_stderr_timeout=>120, :run_command_stdout_timeout=>120, :solo=>false, :splay=>nil, :why_run=>false, :color=>false, :client_fork=>false, :enable_reporting=>true, :enable_reporting_url_fatals=>false, :ssl_client_cert=>nil, :ssl_client_key=>nil, :ssl_verify_mode=>:verify_none, :ssl_ca_path=>nil, :ssl_ca_file=>nil, :role_path=>"/var/chef/roles", :data_bag_path=>"/var/chef/data_bags", :recipe_url=>nil, :solr_url=>"http://localhost:8983/solr", :solr_jetty_path=>"/var/chef/solr-jetty", :solr_data_path=>"/var/chef/solr/data", :solr_home_path=>"/var/chef/solr", :solr_heap_size=>"256M", :solr_java_opts=>nil, :amqp_host=>"0.0.0.0", :amqp_port=>"5672", :amqp_user=>"chef", :amqp_pass=>"testing", :amqp_vhost=>"/chef", :amqp_consumer_id=>"default", :authentication_protocol_version=>"1.0", :client_key=>"/etc/chef/client.pem", :validation_key=>"/etc/chef/validation.pem", :validation_client_name=>"chef-validator", :web_ui_client_name=>"chef-webui", :web_ui_key=>"/etc/chef/webui.pem", :web_ui_admin_user_name=>"admin", :web_ui_admin_default_password=>"p@ssw0rd1", :signing_ca_cert=>"/var/chef/ca/cert.pem", :signing_ca_key=>"/var/chef/ca/key.pem", :signing_ca_user=>nil, :signing_ca_group=>nil, :signing_ca_country=>"US", :signing_ca_state=>"Washington", :signing_ca_location=>"Seattle", :signing_ca_org=>"Chef User", :signing_ca_domain=>"opensource.opscode.com", :signing_ca_email=>"[email protected]", :report_handlers=>[], :exception_handlers=>[], :start_handlers=>[], :cache_type=>"BasicFile", :cache_options=>{:path=>"/var/folders/d_/y4w1ph_d2nd8lg7c1fl3b0800000gn/T/d20121031-34836-1xlix41", :skip_expires=>true}, :chef11_deprecation_warnings=>true, :knife=>{}, :user_valid_regex=>[/^([-a-zA-Z0-9_.]+)$/, /^\d+$/], :group_valid_regex=>[/^([-a-zA-Z0-9_.\\ ]+)$/, /^\d+$/], :user_home=>"/Users/jdyer"}

I know knife is finding the right Knife.rb file because running knife in the same dir works just fine:

9:39:28 (development) [email protected] tropo-gateway master ? knife node list | wc -l
     192
9:42:01 (development) [email protected] tropo-gateway master ?

Warn if a :git entry points to a local path instead of a URL

When moving a cookbook from local dev to a git remote, if you change the :path to :git and forget to change the actual path, you can get strange behavior. Maybe we can warn if the :git path isn't a URL.

Berkshelf ignores version constraints in metadata when there is already a version of the cookbook installed.

In my metadata I had:

depends "cookbook_a", "~> 0.9.4"

When I ran berks install --shims I got

Using cookbook_a (0.9.3)

Even when I used an explicit matcher, depends "cookbook_a", "0.9.4", it still continued to use the version I had installed (0.9.3) instead of fetching the new, correct version, even though it shouldn't have matched the version constraints.

I fixed the issue by nuking my entire ~/.berkshelf directory and rerunning berks install --shims

berks install error indicates wrong remote

When running berks install if a remote fails (e.g. on a bad public key), the remote that failed is not indicated in the error message, so it appears that the error occurred on the last successful remote.

For example, if I have the following repos:

[email protected]/blah1
[email protected]/blah2
[email protected]/publicrepo

If my pub key works for the internal repos but fails on github.com the error message indicates:

Installing [email protected]/blah1
Installing [email protected]/blah2
Error: pub key failed

The messaging makes it seem like the public key failed on blah2, when in fact it failed onpublicrepo. I recommend outputting "Installing" before the error message shows up.

Vagrant plugin always tries to load Knife config

Whenever I try to run the Vagrant plugin of Berkshelf 0.5.0, I get the following error:

$ bundle exec vagrant up
[default] Importing base box 'lucid64'...
[default] The guest additions on this VM do not match the install version of
VirtualBox! This may cause things such as forwarded ports, shared
folders, and more to not work properly. If any of those things fail on
this machine, please update the guest additions and repackage the
box.

Guest Additions Version: 4.2.0
VirtualBox Version: 4.1.12
[default] Matching MAC address for NAT networking...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- 22 => 2222 (adapter 1)
[default] Destroying VM and associated drives...
/Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/berkshelf-0.5.0/lib/berkshelf.rb:107:in `rescue in load_config': Attempted to load configuration from: '/Users/mlafeldt/.chef/knife.rb' but not found. (Berkshelf::KnifeConfigNotFound)
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/berkshelf-0.5.0/lib/berkshelf.rb:105:in `load_config'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/berkshelf-0.5.0/lib/berkshelf/vagrant/action/install.rb:16:in `initialize'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:78:in `new'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:78:in `finalize_action'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:20:in `block in initialize'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:20:in `map'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:20:in `initialize'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/builder.rb:124:in `new'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/builder.rb:124:in `to_app'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/builder.rb:92:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:83:in `block in finalize_action'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/forward_ports.rb:24:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_port_collisions.rb:42:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/env/set.rb:16:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/clear_forwarded_ports.rb:13:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/clean_machine_folder.rb:17:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/validate.rb:13:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/berkshelf-0.5.0/lib/berkshelf/vagrant/action/validate.rb:25:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/check_virtualbox.rb:23:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/match_mac_address.rb:16:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/default_name.rb:17:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_guest_additions.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/import.rb:31:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_box.rb:28:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/vm/check_accessible.rb:18:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/validate.rb:13:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/general/check_virtualbox.rb:23:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/warden.rb:33:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/builder.rb:92:in `call'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/runner.rb:49:in `block in run'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/util/busy.rb:19:in `busy'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/action/runner.rb:49:in `run'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/vm.rb:192:in `run_action'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/vm.rb:145:in `up'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/up.rb:31:in `block in execute'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:116:in `block in with_target_vms'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:111:in `each'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/base.rb:111:in `with_target_vms'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/command/up.rb:24:in `execute'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/cli.rb:42:in `execute'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/lib/vagrant/environment.rb:167:in `cli'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/lib/ruby/gems/1.9.1/gems/vagrant-1.0.5/bin/vagrant:43:in `<top (required)>'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/bin/vagrant:23:in `load'
    from /Users/mlafeldt/.rbenv/versions/1.9.3-p0/bin/vagrant:23:in `<main>'

Neither do I understand why it's "Destroying VM and associated drives", nor why it attempts to load knife.rb considering that I'm provisioning with Chef Solo.

Here's a test setup to reproduce the issue: https://gist.github.com/3783760

Relax Chef version constraint to support Chef 10.14.x

Currently (0.6.0.beta1) berkshelf depends on Chef ~> 10.12.0, i.e. it won't work with Chef 10.14.x.

Should that constraint be relaxed to ~> 10.12 so that it stays compatible with 10.x versions of Chef?

404 Not found when installing a cookbook by path and a lockfile exists

If a cookbook lock file was generated from a path source it will not look in the source to get the cookbook, it will attempt an HTTP request to the community site.

Cookbookfile

cookbook 'pvpnet_core', :path => "~/code/riot-cookbooks"

Stacktrace

Reading Cookbookfile
DEBUG: Sending HTTP Request via GET to cookbooks.opscode.com:80/api/v1/cookbooks/pvpnet_core
/Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/1.9.1/net/http.rb:2632:in `error!': 404 "Not Found" (Net::HTTPServerException)
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/rest.rb:245:in `block in api_request'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/rest.rb:296:in `retriable_rest_request'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/rest.rb:226:in `api_request'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/rest.rb:114:in `get_rest'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/knife/cookbook_site_download.rb:39:in `run'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/knife_utils.rb:8:in `capture_knife_output'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/cookbook.rb:49:in `download'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/cookbook.rb:86:in `dependencies'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/shelf.rb:57:in `populate_graph'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/shelf.rb:58:in `block in populate_graph'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/shelf.rb:57:in `each'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/shelf.rb:57:in `populate_graph'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/shelf.rb:23:in `resolve_dependencies'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/knife_cookbook_dependencies/cookbookfile.rb:27:in `process_install'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/knife_cookbook_dependencies-0.0.1/lib/chef/knife/cookbook_dependencies_install.rb:11:in `run'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/knife.rb:391:in `run_with_pretty_exceptions'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/knife.rb:166:in `run'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/lib/chef/application/knife.rb:128:in `run'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/gems/chef-0.10.8/bin/knife:25:in `<top (required)>'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/bin/knife:19:in `load'
    from /Users/reset/.rbenv/versions/1.9.3-p125/lib/ruby/gems/1.9.1/bin/knife:19:in `<main>'

Softlink in cookbook breaks berks install --shims

I tried installing the elasticsearch cookbook cookbook.

This cookbook has a symlink called "tests" in it's root, pointing towards the minitest spec directory at files/default/tests/minitest/.

Adding it to my Berksfile and running berks install --shims produces the following error:
/usr/local/rvm/gems/ruby-1.9.3-p194/gems/chef-10.12.0/lib/chef/checksum_cache.rb:171:ininitialize': No such file or directory - /home/nl/.berkshelf/cookbooks/elasticsearch-52143ab1d1a5997a2cdd140ab2726a6dc7edbfe9/tests (Errno::ENOENT)`

Cloning the repository to a local path and deleting the "tests" symlink makes berks install --shims work.

Add support for retrieving cookbooks from the local chef server configured in the knife config

Right now all cookbooks not given an explicit source (git/path) are pulled from the Opscode community site. There should be support for pulling from the configured chef server as a higher priority source to accomodate unpublished cookbooks, cookbooks awaiting pull requests being handled, etc.

ambiguous error when cookbook not found

When a cookbook depends on a cookbook that is not on the opscode community site then when it tries to download it, I receive the follow error:
ERROR: The object you are looking for could not be found
Response:

It would be better if we said that the cookbook was not found on the opscode community site and that the user should define where it can be found in their Cookbookfile.

add git_collection source, or overload site: to work with cookbooks collections

I am switching an ironfan homebase to Berkshelf to simplify development.

Ironfan uses the idea of "pantries" which are groups of cookbooks, and the cookbooks folder in the ironfan homebase consists of symlinks to one or another of the pantries (there are 3 by default: ironfan-pantry, org-pantry, and opscode)

To play nicely with this setup (and to easily use other cookbooks that are distributed as a collection rather than as individually source controlled cookbooks) it would be helpful to add a :git_collection option

cookbook "hadoop", git_collection: "https://github.com/infochimps-labs/ironfan-pantry.git"

Alternatively, the :site option could be overloaded, so that when set to a git repo it looks for a cookbooks folder in that repo and for the cookbook in that folder.

Berkshelf only recursively pulling in dependencies defined in metadata.rb?

I'm not sure if I'm confused about how Berkshelf is supposed to work or if I'm seeing a bug...

I have a chef-repo that references a cookbook called ruby that I'm developing. The ruby cookbook in turn relies on a 3rd-party recipe that I'd like to use the git version of, rather than the one released to the opscode community site. The Berksfiles and metadata.rb files look like so:

chef-repo/Berksfile

cookbook "ruby",
  path: "~/src/cookbooks/ruby"

~/src/cookbooks/ruby/Berksfile

metadata

cookbook "xquartz",
  git: "git://github.com/jtimberman/xquartz-cookbook.git"

~/src/cookbooks/ruby/metadata.rb

maintainer       "JD Harrington"
maintainer_email "[email protected]"
license          "All rights reserved"
description      "Installs/Configures ruby using either RVM or rbenv"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          "0.0.1"

depends "ruby_build"

When I run berks install in the ruby cookbook, it picks up the dependency on xquartz and installs it to the berkshelf as expected. When I run berks install in the chef-repo, however, it pulls in the ruby cookbook, as well as the ruby_build dependency defined in the cookbook's metadata.rb, but does not pull in the xquartz dependency as I was expecting.

Berkshelf.com notes that "All sources and their dependencies will be retrieved, recursively. ", which is what made me think this would work. I'm happy to dig in and try to fix this, but wanted to check to see if I'm off-base as to how Berkshelf is meant to work or not ;)

I've tested this on both 0.5.1 and 0.6.0.beta2 built from git.

Vagrant Plugin Always Loads, Contradicts Documentation

The docs on berkshelf.com state that:

Berkshelf ships with a Vagrant plugin that integrates the Berkshelf development process into creating and provisioning virtual machines. All you need to do is require the Berkshelf Vagrant plugin at the top of your Vagrantfile.

Based on that, I was expecting the plugin to only load when explicitly required, however the presence of the vagrant_init.rb file results in Berkshelf being automatically included by Vagrant any time it's run.

I was just curious if this was intentional or not, since I had to delete my vagrant_init.rb to get Test Kitchen to run properly (the Vagrant file it generates doesn't take kindly to the shared folders the Berkshelf plugin then tries to load).

Thanks!

Add support for updating an individual cookbook via knife cookbook deps update COOKBOOK_NAME

Should warn if using --foodcritic w/o thor-foodcritic installed

Easy enough fix but probably easy for people to stumble on after installing berkshelf for the first time. See https://gist.github.com/3952597 for stacktrace.

add "addressable" as a development dependency

valid uri not passing validation

In a private repository (perhaps set up in gitolite) you might not have your repo nested beneath some organizing directory. So your uri would look like:

"[email protected]:mycookbook.git"

instead of

"[email protected]:directory/mycookbook.git"

But this fails the SSH REGEX: /(.+)@(.+):(.+)/(.+).git/

I'm not sure of the best way to make that organizing directory bit optional. if you use

SSH REGEX: /(.+)@(.+):(.*)/(.+).git/

then

"[email protected]:/mycookbook.git"

would work and would likely clone just fine. It does with gitolite. There is probably a better solution though.

LoadError/json conflict

When running berks with json 1.7.5 installed:

Gem::LoadError: Unable to activate chef-10.14.4, because json-1.7.5 conflicts with json (<= 1.6.1, >= 1.4.4)

Happens (at least) on v0.5.1 and both 0.6.0 RCs

`berks init` should generate the same files as `berks cookbook create`

The berks init command should accept the same flags as berks cookbook create and generate the helpful files to iterate on cookbooks

Don't copy cookbooks for every vagrant run

If I haven't changed a cookbook (as is the case with all but 1 cookbook), don't recopy the cookbook to the temp directory. Reuse what's already there. Copying takes a while.

Perhaps we only need to copy cookbooks with a path source after the first run?

Fails w/ call to mixlib-shellout/windows.rb on windows

I get the following error when I try to use berkshelf on windows Vista xi86 (i know, fucking horrible).

This looks like it may be an issue with mixlib-shellout tho I don't see a corresponding ticket in tickets.opscode.com

it could be that the mixlib-shellout library doesn't like the "/" that I have in the git command path on windows => "c:\Git\cmd/git.exe"

I am using the version of ruby that comes embedded w/ the vagrant installer
ruby 1.9.3p125 (2012-02-16) [i386-mingw32]

C:\vagrant\openarchive>berks install
Using openarchive (0.0.1) at path: 'C:/vagrant/openarchive'
C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.1.0-x86-m
ingw32/lib/mixlib/shellout/windows.rb:244:in should_run_under_cmd?': undefined methodeach_char' for #Array:0x35fb4d0 (NoMethodError)
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellou
t-1.1.0-x86-mingw32/lib/mixlib/shellout/windows.rb:168:in command_to_run' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellou t-1.1.0-x86-mingw32/lib/mixlib/shellout/windows.rb:56:inrun_command'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellou
t-1.1.0-x86-mingw32/lib/mixlib/shellout.rb:222:in run_command' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/git.rb:20:ingit'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/git.rb:39:in clone' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/locations/git_location.rb:41:indownload'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/downloader.rb:70:in download' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/resolver.rb:127:ininstall_source'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/resolver.rb:47:in add_source' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/resolver.rb:22:inblock in initialize'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/resolver.rb:21:in each' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/resolver.rb:21:ininitialize'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/berksfile.rb:337:in new' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6. 0.beta2/lib/berkshelf/berksfile.rb:337:ininstall'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/cli.rb:65:in install' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/thor-0.16.0/li b/thor/task.rb:27:inrun'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/thor-0.16.0/li
b/thor/invocation.rb:120:in invoke_task' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/thor-0.16.0/li b/thor.rb:275:indispatch'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/lib/berkshelf/cli.rb:10:in dispatch' from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/thor-0.16.0/li b/thor/base.rb:425:instart'
from C:/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.
0.beta2/bin/berks:6:in <top (required)>' from C:/vagrant/vagrant/embedded/bin/berks:19:inload'
from C:/vagrant/vagrant/embedded/bin/berks:19:in `

I really appreciate your work on the Windows stuff. AFAICT, the majority of corporate programmers out there run linux on top of their company-provided Windows desktop/laptop. vagrant + chef + berkshelf makes it that much less painful ;)

Add local chef server source

Berkshelf should ascend directories looking for Berksfile

Vagrant ascends to look for Vagrantfile, so you can run Vagrant commands but then the berkshelf plugin will die a horrible death cause, even though the Vagrantfile was found, the Berksfile was not.

Cookbook 'application_ruby' not found in any of the default locations

Installed the beta version berkshelf (0.6.0.beta1)

Created a cookbook and in its Berksfile.

site :opscode

metadata
cookbook "application_ruby", '~> 1.0.3'

When I do berks install, it say:

berks install
Using funsole (0.0.1) at path: '/Users/millisami/chef-apps/funsole'
Cookbook 'application_ruby' not found in any of the default locations

Why does it says application_ruby cookbook now found?

Segfault when running berks install in a vagrant

I ran berks install on a vagrant built on the lucid32 box, and experienced a segmentation fault.

I have tried running the command with my vagrant running inside an Ubuntu PC laptop, also running 10.04 and a mac running the lasted OSX. In both cases I got the output I've pasted below.

vagrant@lucid32:~/kiwi/kiwi_infrastructure/kiwi-ironfan-homebase$ berks install
Using helloworld (0.0.1) at path: 'vendor/kiwi-pantry/cookbooks/helloworld'
Using kiwi-app (0.0.1) at path: 'vendor/kiwi-pantry/cookbooks/kiwi-app'
Using solr (0.0.1) at path: 'vendor/kiwi-pantry/cookbooks/solr'
Installing minitest-handler (0.0.10) from git: 'https://github.com/richzhou/minitest-handler-cookbook.git' with branch: '1cba2f8488cbc94b11d070625e3ef6fe49011d64'
Installing python (1.0.6) from git: 'https://github.com/richzhou/python.git' with branch: '44868073eb4eaae9d5e6fd99a47b33c085e038fa'
Installing application (1.0.0) from git: 'https://github.com/richzhou/chef-application.git' with branch: 'kiwi'
Installing application_php (1.0.0) from git: 'https://github.com/richzhou/chef-application_php.git' with branch: 'kiwi'
Segmentation fault

This segfault occurred first when running berks install with our Berksfile in the working directory. We later tested it with a very simple Berksfile, containing only one recipe, and then finally with an empty Berksfile. In each case, the segfault occurred.

I'm about to try again on a precise32 box.

Thank you,

Provide a way to request 'recommends' dependencies

It looks like berks install doesn't honor 'recommends' dependencies either in my own cookbook's metadata or in the cookbooks on which we depend, e.g. https://github.com/opscode-cookbooks/pxe_dust/blob/master/metadata.rb

It would be great to provide an option to treat these as 'depends' in Berkshelf.

Berkshelf should not always require knife.rb

When using berkshelf together with chef-solo, knife.rb is unnecessary in that context

the --git option should populate w/ regexes to ignore temporary editor files

Add option to freeze cookbooks on upload

Detect when Cookbookfile has been changed and automatically update

Right now, if you have a Cookbookfile.lock, knife cookbook deps install will not look at the Cookbookfile at all and will build off the Cookbookfile.lock, even if new cookbooks are added to the Cookbookfile.

Perhaps we can we can put in some detection to see if the Cookbookfile has been changed and update the lockfile accordingly.

Need override mechanism individual cookbooks in Berksfile

The scenario I have is where a team of developerss share a common Berksfile and they do not have equal access to all of the cookbooks in the Berksfile. For example, some devs have read/write access to a given cookbook and others only have read access.

The Berksfile could include the url with the least access permissions and devs with greater access can override individual cookbooks

example:

/chef-repo/Berksfile
cookbook "ark", :git => 'git://github.com/bryanwb/chef-ark.git' # read-only url
include_overrides '/.berkshelf/overrides'

~/.berkshelf/overrides
cookbook "ark", :git => '[email protected]:bryanwb/chef-ark.git' # read-write url

So when my colleague Eugenio uses this Berksfile, berkshelf will not find a read-write url in '~/.berkshelf/overrides', thus he will continue to have read-only access. However I will have that override and will continue to have read-write access

Should git initialization include a git commit?

After creating a new cookbook, the user is left with a git-init'd repo with no commits. It's possible to commit the initial structure, so that any changes beyond the generated files are more obvious.

The user could be left to do this themselves, and other app generators (such as Rails) also omit a commit.

Obvious cons:

The user might not want a commit yet
The user might want to format the commit message differently than we decide
The user might not want to attach their author to the automatic commit

Just a request for comments. The proposed change would be to commit with the following message (or similar):

berks cookbook #{cookbook_name}

(Automatic commit by Berkshelf)

Git and Vagrant should be the default during cookbook creation

Default to creating Vagrant and running Git init
Add flags for --skip-git, --skip-vagrant
Noop legacy flags and add deprecation warnings

Refactor Cookbook to multiple classes handling each installation path

Currently piles of conditionals handle varying functionality between git/path/etc functionality.

Having a GitCookbook, PathCookbook, SiteCookbook inherit from Cookbook would be more maintainable as we add methods to fetch cookbooks.

validate the name of the retrieved cached_cookbook is not different than the source

the cookbook retrieved from a source location should not contain a different name than the source

Dependency Resolution Broken on Windows 7

Hey guys,

following the awesome cookbook authoring guide from Jamie Winsor I git stuck after adding the depends "artifact", "~> 0.10.7" tp metadata.rb.

What I got on the next bundle exec vagrant provision is this:

W:\tmp\myface>bundle exec vagrant provision
[Berkshelf] installing cookbooks...
[Berkshelf] Using myface (0.0.1) at path: 'W:/tmp/myface'
W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/downloader.rb:91:in `download': Cookbook 'artifact'
f the default locations (Berkshelf::CookbookNotFound)
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:127:in `install_source'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:47:in `add_source'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:71:in `block in add_source_
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:68:in `each'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:68:in `add_source_dependenc
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:26:in `block in initialize'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:25:in `each'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/resolver.rb:25:in `initialize'
        from W:/tools/vagrant/vagrant/vagrant/embedded/lib/ruby/gems/1.9.1/gems/berkshelf-0.6.0.beta1/lib/berkshelf/berksfile.rb:335:in `new'
...

Next I tried berks install but got the same problem:

W:\tmp\myface>berks install
Using myface (0.0.1) at path: 'W:/tmp/myface'
Cookbook 'artifact' not found in any of the default locations

My Berksfile looks like this:

site :opscode

metadata

and this is my metadata.rb:

name             "myface"
maintainer       "YOUR_NAME"
maintainer_email "YOUR_EMAIL"
license          "All rights reserved"
description      "Installs/Configures myface"
long_description IO.read(File.join(File.dirname(__FILE__), 'README.md'))
version          "0.0.1"

depends "artifact", "~> 0.10.7"

I have tried several things like using site 'http://cookbooks.opscode.com/api/v1/cookbooks' instead of site :opscode, using a different cookbook ("mysql") with and without version constraints, but it didn't make a difference.

Am I doing something wrong?

Windows7 64-Bit, Ruby 1.9.3p125, berkshelf 0.6.0.beta1

PROPOSAL: allow symlink option for :path cookbooks

hardlinks are not useful for active development of cookbooks if your editor uses atomic saves (like TextMate, for example).

whether you edit a file in the shim directory or the original file it is linked to, the hardlink is broken. There is no way to tell except by comparing the inode of each file (or editing with an editor that does not do atomic saves and noticing that the link is broken).

usually one is using a :path cookbook either because one is linking to a cookbook collected elsewhere in the repo, or because one is actively developing a cookbook. In either case a symlink seems more appropriate. When active development is finished, typically the cookbook would get scm'd somewhere and no longer be a :path cookbook in the berksfile.

Same cookbook can't be included in different groups

FATAL: Berksfile contains two sources named 'artifact'. Remove one and try again.

Currently it doesn't allow different version of the same cookbook to be specified in different groups.

knife plugin

I'd really like to use berkshelf with knife -- it's more natural to me and I have numerous chef servers to maintain, so having one stop where my config can be loaded for all chef-based administration tasks would be ideal.

I understand you guys are attached to thor, so what I'd like to accomplish with this ticket is some signoff on an abstraction layer that lets us not duplicate our efforts and populates both thor commandline arguments and mixlib (knife plugins) argument stuff.

This is not particularly hard but it will require quite a bit of refactoring to the Berkshelf::Cli class which makes me think I should ask before jumping in.

Again, the end goal would be the standalone interface intact and knife plugins for those of us who prefer that route.

What say you guys?

path source should link, not copy, to the source

Currently specifying cookbook 'pvpnet_core', :path => "/Users/reset/code/riot-cookbooks will copy the contents of a cookbook to {current_working_dir}/cookbooks.

If we make this link instead we can make modifications to the cookbook without re-running knife cookbook dependencies install

Add github source

Many cookbooks are in github. It'd be nice to add a thin wrapper around the git source to make pulling from github nice and clean:

cookbook 'something', github: 'bluepojo/something-cookbook'