Skip to content

should "chef exec bundle install" be considered harmful? #21

Open
@dwmarshall

Description

@dwmarshall

Not sure where best to start this discussion, i.e. whether this is just for these cookbooks, should be more fully discussed in the Chef community, or what.

Both this repository's TESTING.md and the Gemfile in the individual repositories I've checked all recommend using chef exec bundle install to install dependencies. However, when using ChefDK, this is probably the absolute wrong thing to do. Based on the available gems at bundle installation time, a user's ~/.chefdk will be populated with gems that are later versions than the gems in /opt/chefdk, and that has caused me trouble from time to time.

To cut to the chase, I believe it is better to prefer chef gem install --file --conservative --minimal-deps for installing dependencies.

All this is with ChefDK 3.2.30, FWIW.

If I start with an empty ~/.chefdk, the version of octokit I have is 4.11.0, which is what came with ChefDK:

$ ls -ld /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/octokit*
drwxr-xr-x  9 root  wheel  288 Aug 30 14:06 /opt/chefdk/embedded/lib/ruby/gems/2.5.0/gems/octokit-4.11.0

which I can confirm with

$ chef exec ruby -roctokit -e 'puts Octokit::VERSION'
4.11.0

If I do what is currently recommended, chef exec bundle install with this Gemfile:

source 'https://rubygems.org'

gem 'community_cookbook_releaser'

I'm going to get whatever happens to be on rubygems.org for all the dependencies! Notably I now have octokit-4.12.0 in my ~/.chefdk. This is probably not desirable:

$ ls ~/.chefdk/gem/ruby/2.5.0/gems/
community_cookbook_releaser-1.0.0	octokit-4.12.0
faraday-0.15.3

Indeed,

$ chef exec ruby -roctokit -e 'puts Octokit::VERSION'
4.12.0

If I repeat installation (starting with a blank ~/.chefdk) with chef gem install --file --conservative --minimal-deps, I don't start replacing ChefDK's gems with new ones.

$ chef gem install --file --conservative --minimal-deps
Using multipart-post (2.0.0)
Using faraday (0.15.2)
Using public_suffix (3.0.3)
Using addressable (2.5.2)
Using sawyer (0.8.1)
Using octokit (4.11.0)
Fetching: community_cookbook_releaser-1.0.0.gem (100%)
Installing community_cookbook_releaser (1.0.0)

Although it hasn't happened to me in a long time, I recall winding up with all sorts of gems in ~/.chefdk because I was using bundle install, and I'd wind up with all kinds of errors for which the only solution was to blow away my ~/.chefdk.

Am I making too much of getting newer gems in ~/.chefdk because I used bundle install? I would think that we would normally want to have only those gems there that don't come with ChefDK and that are compatible with the gems that come with ChefDK (or Chef, for that matter).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions