[chef] Re: Re: Re: Thinking out loud


Chronological Thread 
  • From: Daniel DeLeo <dan@kallistec.com>
  • To: chef@lists.opscode.com
  • Subject: [chef] Re: Re: Re: Thinking out loud
  • Date: Tue, 28 Jul 2009 07:40:34 -0600

Also, as Adam said, if vendoring is the _only_ way to install cookbooks from gems, then the process is pretty easy. You'd just have a rake task like

rake gem_cookbook NAME="opscode-cookbooks"

or 

rake gem_cookbook:cherry_pick NAME="opcode-cookbooks" BOOK="mysql"

Personally, I'd prefer thor for this because it handles arguments better, but I don't know if the additional dependency is worth it.

Dan DeLeo


On Tue, Jul 28, 2009 at 7:17 AM, Daniel DeLeo <dan@kallistec.com> wrote:


On Tue, Jul 28, 2009 at 5:47 AM, Miguel Cabeça <cabeca@ist.utl.pt> wrote:

* Allow vendoring of these gems, because I don't like relying on system
gems, even in this sort of environment. Bootstrapping is key.

That is essentially what you have now with a normal chef repository -
I imagine the vendoring process would be very simple.

I don't understand this part, mainly because i don't know the meaning of the 'vendoring' word. Will someone be kind enough to explain this to me?
 
It comes from Rails, where a common and good practice is to get ruby gems the normal way, and then unpack a specific version of the rails (or other) gems to a my-rails-app/vendor/gems/ directory. Rails will prefer libraries in this directory over system gems. This locks the rails app to a specific version of the gems. You also get the benefit of being able to distribute the app and its dependencies in one big package that doesn't need anything other than ruby and the webserver to run.
 
Best Regards

Miguel Cabeça


HTH,
Dan DeLeo




Archive powered by MHonArc 2.6.16.

§