how to update vendorized cookbook #381

Closed
deepak opened this Issue Feb 22, 2013 · 13 comments

Projects

None yet

7 participants

deepak commented Feb 22, 2013

How do i update a vendorized cookbook ?

berks install --path vendor/cookbooks works
but berks update --path vendor/cookbooks does not

Also cannot update a single cookbook ?

Right now, am deleting Berksfile.lock, ~/.berkshelf and vendor/cookbooks
and then running berks install --path vendor/cookbooks
this works only because my cookbooks are under git

Contributor

@deepak what cookbook? Is a new version actually available?

deepak commented Mar 6, 2013

@sethvargo yes. new version of ohai cookbook was released

allaire commented Jun 6, 2013

👍 Same question, how are we supposed to update cookbooks, located in a vendor directory?

Contributor
ivey commented Jun 6, 2013

Does berks update ohai followed by berks install --path vendor/cookbooks do what you want?

Contributor

@ivey that will work, but not the ideal workflow.

I think we should do one of two things:

  1. Allow --path as an option (I can do that in a second if we think that's the best option)
  2. Save the configuration somehow like bundler, so future updates inside a vendored/pathed cookbook install to the same place (and thus update there as well)
Contributor

@reset @justincampbell ^ thoughts

Contributor
ivey commented Jun 6, 2013

The more I think about it the more I want to drop --path on install altogether, and move that functionality to a separate vendor command. bundle install --path installs gems somewhere other than the main store, but berks install --path does not...it still puts them in the store, and then does a local export. Maybe the confusion around it comes from not making that explicit.

We could have a --update on vendor to update first, which would then give 1 command to accomplish what people seem to want from this.

Contributor

Meh. I disagree. I think we made a bad decision to install to the store and then copy. IMO, --path should set Berkshelf.berkshelf_path and store that information in the local config, like bundler. I think that's what people are expecting, which is why there's always confusion surrounding this.

One of the advantages of --path on bundler is that it doesn't touch the system ruby gems store, usually because there are permission issues (would need sudo otherwise). I think we should follow a similar pattern.

We introduced Berkshelf.berkshelf_path = ... recently, so the change would be super simple.


I actually was severely bitten recently by this:

I had a Chef cookbook I was using a chef_api :config for. I did a berks install, which pulled the cookbooks down, as expected. However, this wasn't my Chef Server, and there were some cookbooks that were the same names and versions of community ones (but were different). This client wrote their own python cookbook, for example, but it happened to also be at the same version as the most recent community cookbook. I vendored, but it installed to ~/.berkshelf/cookbooks/python-x.y-z as well. Then, a week later when I went back to work on a personal cookbook that depended on python, a ton of shit was broken. Berkshelf still resolved the dependency (because the version was correct), but it was the "wrong python". I think we should allow fully isolated shelfs instead of copied vendor paths.

Contributor
ivey commented Jun 6, 2013

We don't touch the system Berkshelf store, either, since there isn't one. It's always your own.

Let's save for a hangout, either dedicated or next Wednesday.

Member
reset commented Jun 6, 2013

@sethvargo @ivey keep in mind that we install to the Berkshelf store before copying out because we dynamically resolve dependencies. This will be a lot easier to accomplish when the dependency API is finished since we will have a one pass resolve/retrieve.

Either not installing the cookbooks to the Berkshelf store when --path is provided or removing --path from install and enforcing a vendor command is my preference.

tknerr commented Jun 7, 2013

IMO, --path should set Berkshelf.berkshelf_path and store that information in the local config, like bundler. I think that's what people are expecting, which is why there's always confusion surrounding this.

That was exactly my expectation. Would be great and least confusing if it would work like Bundler imho.

Contributor

👍 for Seth's approach to having a local path config and doing all installation there. A vendor export from a single local berkshelf would definitely still have issues like Seth encountered. I also manage separate chef stacks for internal and for a client - both with vendoring cookbooks into a repo.

Contributor

rm -rf vendor/cookbooks && berks vendor vendor/cookbooks

@sethvargo sethvargo closed this Jul 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment