berks install --shims /tmp/cookbooks should detect new files about berkshelf HOT 11 CLOSED

Thanks for the feedback @bryanwb - this is a known issue and a limitation of the filesystem. We're looking for a better way to do shims, or just better chef-solo support overall.

I'll modify the shims creation function to relink things so it can easily be updated. This will at the very least allow you to update them quickly and easily.

from berkshelf.

@bryanwb if you update to 0.3.4 you'll be able to reinstall your shims by calling berks install --shims

from berkshelf.

thanks @reset! I have tested this and it can lead to some unintended consequences

This works as expected when working on an individual cookbook but not so well when working w/ the traditional

chef-repo/cookbooks setup

for example:

hitman@foobar:/chef-repo$ touch cookbooks/logstash/foo.rb
hitman@foobar:/chef-repo$ berks install --shims cookbooks
..... berks install runs
hitman@foobar:~/chef-repo$ ls cookbooks/logstash/foo.rb
ls: cannot access cookbooks/logstash/foo.rb: No such file or directory

This could cause a lot of confusion

I can't see a better way to do this than the solution you gave, but perhaps we should not overload the install action w/ this behavior.

I am not sure how berks update works. Perhaps it already accomplishes what I am looking for?
EDIT:
on reflection, I think berks update --shims would be a more intuitive way to accomplish this action

from berkshelf.

@bryanwb it looks like you are trying to install the shims into a location already containing cookbooks. That's not what I had intended shims to be for since a shims directory contains a collection of shims and not a mixture of shims and cookbooks.

You should try to develop cookbooks by themselves to ensure they are self sustaining and not intertwined with another cookbook. If you do have dependencies of something else that you are currently working on that is what the path location source is for.

You would want to create a source with a path: location for each cookbook that is located on disk that you'd like to develop against. This will allow you to develop two cookbooks simultaneously who may be circular dependent on each other. I saw a few things that might make clearing this up easier in your blog post. I'll just respond to the email thread there with my comments.

Of course, I don't want to tell you how to use my software - I'd rather find a solution that works for everyone!

from berkshelf.

"You should try to develop cookbooks by themselves to ensure they are self
sustaining and not intertwined with another cookbook. If you do have
dependencies of something else that you are currently working on that is
what the path location source is for."

agreed! However, most people do start with all of their cookbooks in a
single directory like chef-repo/cookbooks even though that can lead to too
many interdependencies. I think we are expecting too much of n00bs and even
experienced chef users if we expect them to not work in this manner.

if my shims path is chef-repo/cookbooks/ and I am actively working on
cookbook "foo", then I should use path => '~/path/to/foo"

what would u recommend that path be? 'chef-repo/site-cookbooks' ? and do I
have to run

berks install && berks install --shims every time I make a change to
site-cookbooks/foo ?

On Tue, Jul 3, 2012 at 8:56 PM, Jamie Winsor <
[email protected]

wrote:

@bryanwb it looks like you are trying to install the shims into a location
already containing cookbooks. That's not what I had intended shims to be
for since a shims directory contains a collection of shims and not a
mixture of shims and cookbooks.

You should try to develop cookbooks by themselves to ensure they are self
sustaining and not intertwined with another cookbook. If you do have
dependencies of something else that you are currently working on that is
what the path location source is for.

You would want to create a source with a path: location for each cookbook
that is located on disk that you'd like to develop against. This will allow
you to develop two cookbooks simultaneously who may be circular dependent
on each other. I saw a few things that might make clearing this up easier
in your blog post. I'll just respond to the email thread there with my
comments.

Of course, I don't want to tell you how to use my software - I'd rather
find a solution that works for everyone!

---

Reply to this email directly or view it on GitHub:
#66 (comment)

from berkshelf.

@bryanwb I would definitely suggest that people avoid jamming all of their cookbooks in a single directory while working on them. It will cause people more problems later on as they try to separate them from each other and also ensure people aren't programming by coincidence.

I'd say the only reason people were developing cookbooks in this manner is because Berkshelf didn't exist. Much the same of how Ruby development worked on Gems prior to Bundler.

But if you do want to follow the traditional development process of using the cookbooks directory as a container for everything. I'd make my shims directory something like site-cookbooks or cookbook-shims and then add that to the cookbook_paths array in Vagrant or Knife. I think this will still enable that style of workflow.

from berkshelf.

@reset

sadly, this is how I develop cookbooks now and it is likely flawed as you
suggest.

I will have to investigate a better workflow based on your suggestions

can we chat on irc? I think that would be very helpful

It is very important for me to consider the needs of n00bs, esp.
considering that I have 2 colleauges that are not nearly as advanced w/
Chef as I am. Also, I want to address the needs of a lot of foodfightshow
listeners, many of whom are n00bs.

On Fri, Jul 6, 2012 at 1:13 AM, Jamie Winsor <
[email protected]

wrote:

@bryanwb I would definitely suggest that people avoid jamming all of their
cookbooks in a single directory while working on them. It will cause people
more problems later on as they try to separate them from each other and
also ensure people aren't programming by coincidence.

I'd say the only reason people were developing cookbooks in this manner is
because Berkshelf didn't exist. Much the same of how Ruby development
worked on Gems prior to Bundler.

But if you do want to follow the traditional development process of using
the cookbooks directory as a container for everything. I'd make my shims
directory something like site-cookbooks or cookbook-shims and then add
that to the cookbook_paths array in Vagrant or Knife. I think this will
still enable that style of workflow.

---

Reply to this email directly or view it on GitHub:
#66 (comment)

from berkshelf.

Hey @bryanwb I'll be in #chef all day if you want to grab me and don't see Jamie. I'm ivey there too.

from berkshelf.

@bryanwb message me in #Chef. I'll be there all day.

I want to promote best practices but I also do not want to force people to change the way they work. Let's see what we can come up with!

from berkshelf.

+1 for an berks update --shims, although for me the main reason is that berks install --shims takes too long. When the Berksfile has not changed, but you just want the changes to a :path cookbook, this would make things much faster.

Personally, I would like to have the options for :path cookbooks to be symlinks instead of hardlinks. Hardlinks are frustrating when using TextMate, because if you happen to edit the hard linked file in any way a new file is created, because Textmate uses atomic saves. There is no way to tell that this has happened other than to edit the original file and notice that the file you thought was hard linked doesn't change.

from berkshelf.

The master branch now contains a Vagrant Berkshelf plugin that obsoletes shims. Closing this ticket as it no longer applies.

BYE BYE SHIMS

from berkshelf.