You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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).
The text was updated successfully, but these errors were encountered:
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 ofoctokit
I have is 4.11.0, which is what came with ChefDK:which I can confirm with
If I do what is currently recommended,
chef exec bundle install
with thisGemfile
: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:Indeed,
If I repeat installation (starting with a blank
~/.chefdk
) withchef gem install --file --conservative --minimal-deps
, I don't start replacing ChefDK's gems with new ones.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 usingbundle 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 usedbundle 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).The text was updated successfully, but these errors were encountered: