I’m somewhat new to Chef and Ruby in general, so please bear with me ( and feel free to correct any misguided statements! )
From what I understand, pre-ChefDK, people would use bundler to pin the gem versions they used to develop/test their application/cookbook. I slap it all into a Gemfile, bundle install, commit the Gemfile.lock. You download my repo, you bundle install and you immediately have all the same gem versions that I used.
My confusion stems with how this is supposed to work with ChefDK. Suppose that I use ChefDK to create my cookbook, do all my development and testing and release it to a public repo.? My colleague, however, doesn’t have ChefDK and grabs my repo. How is he supposed to know what gems I used? My first answer would be - I either document it in the README or I just say ‘Install ChefDK v0.3.5’. Another option would be to manually create a Gemfile for everything that I used out of ChefDK and include that along with my repo? But in both cases, I’m having to keep some extra piece of information up to date with everything I’m using out of ChefDK ( or just telling him he better install it ). Am I missing something there?
The second scenario I’m hazy about is when you get into the situation when we start drifting between ChefDK versions. Perhaps I haven’t upgraded my ChefDK for awhile and you’re on the latest and greatest. What’s keeping us in sync, so that we’re using the same versions of Test Kitchen, ChefSpec, etc? Or does it not matter, because in general, the differences between the gems provided in different ChefDK versions isn’t a big enough concern?
I understand ( I think ), that if I start using 3rd party gems that aren’t included in ChefDK, I should be bundle installing them and including the Gemfile. I think it’s the two scenarios above that I’m unsure about and I’m curious how others are doing this.
For what its worth, I share your confusion here. We've historically used
the Gemfile approach as well and as we transition to ChefDK, I still feels
like we need this... As very simplistic example we use rubocop to enforce
rules (build fails if there are offenses). Since new version introduce new
rules folks with varying levels of the gem and/chefDK get different
results. It's unclear to me how ChefDK (which as I understand, suggests you
can do away with Gemfiles) solves this issue?
I'm somewhat new to Chef and Ruby in general, so please bear with me (
and feel free to correct any misguided statements! )
From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the same
gem versions that I used.
My confusion stems with how this is supposed to work with ChefDK.
Suppose that I use ChefDK to create my cookbook, do all my development and
testing and release it to a public repo. My colleague, however, doesn't
have ChefDK and grabs my repo. How is he supposed to know what gems I
used? My first answer would be - I either document it in the README or I
just say 'Install ChefDK v0.3.5'. Another option would be to manually
create a Gemfile for everything that I used out of ChefDK and include that
along with my repo? But in both cases, I'm having to keep some extra piece
of information up to date with everything I'm using out of ChefDK ( or just
telling him he better install it ). Am I missing something there?
The second scenario I'm hazy about is when you get into the situation
when we start drifting between ChefDK versions. Perhaps I haven't upgraded
my ChefDK for awhile and you're on the latest and greatest. What's keeping
us in sync, so that we're using the same versions of Test Kitchen,
ChefSpec, etc? Or does it not matter, because in general, the differences
between the gems provided in different ChefDK versions isn't a big enough
concern?
I understand ( I think ), that if I start using 3rd party gems that
aren't included in ChefDK, I should be bundle installing them and including
the Gemfile. I think it's the two scenarios above that I'm unsure about
and I'm curious how others are doing this.
I've read a few blog posts and the previous mail on the list chef - [chef] Re: Chef-DK Question, but I
think I'm still confused enough what the vision/workflow is that I had to
ask.
For what its worth, I share your confusion here. We've historically used the
Gemfile approach as well and as we transition to ChefDK, I still feels like
we need this... As very simplistic example we use rubocop to enforce rules
(build fails if there are offenses). Since new version introduce new rules
folks with varying levels of the gem and/chefDK get different results. It's
unclear to me how ChefDK (which as I understand, suggests you can do away
with Gemfiles) solves this issue?
I'm somewhat new to Chef and Ruby in general, so please bear with me ( and
feel free to correct any misguided statements! )
From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the same
gem versions that I used.
My confusion stems with how this is supposed to work with ChefDK. Suppose
that I use ChefDK to create my cookbook, do all my development and testing
and release it to a public repo. My colleague, however, doesn't have ChefDK
and grabs my repo. How is he supposed to know what gems I used? My first
answer would be - I either document it in the README or I just say 'Install
ChefDK v0.3.5'. Another option would be to manually create a Gemfile for
everything that I used out of ChefDK and include that along with my repo?
But in both cases, I'm having to keep some extra piece of information up to
date with everything I'm using out of ChefDK ( or just telling him he better
install it ). Am I missing something there?
The second scenario I'm hazy about is when you get into the situation when
we start drifting between ChefDK versions. Perhaps I haven't upgraded my
ChefDK for awhile and you're on the latest and greatest. What's keeping us
in sync, so that we're using the same versions of Test Kitchen, ChefSpec,
etc? Or does it not matter, because in general, the differences between the
gems provided in different ChefDK versions isn't a big enough concern?
I understand ( I think ), that if I start using 3rd party gems that aren't
included in ChefDK, I should be bundle installing them and including the
Gemfile. I think it's the two scenarios above that I'm unsure about and I'm
curious how others are doing this.
I've read a few blog posts and the previous mail on the list chef - [chef] Re: Chef-DK Question, but I think
I'm still confused enough what the vision/workflow is that I had to ask.
yo,
ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks' Gemfiles, or even mega repository
Gemfiles. I don't think I've heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.
One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.
I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn't take an hour to
compile on smaller rigs
I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.
Thanks AJ, this is exactly what we've done as well. Just let ChefDK get all
the rights bits, but we are still using gemfiles and Bundler, I can't
recall where I saw/heard it, but there was some suggestions that ChefDK
could do away with these complexities.
On Thu, Dec 18, 2014 at 4:23 PM, AJ Christensen <aj@junglistheavy.industries
For what its worth, I share your confusion here. We've historically used
the
Gemfile approach as well and as we transition to ChefDK, I still feels
like
we need this... As very simplistic example we use rubocop to enforce
rules
(build fails if there are offenses). Since new version introduce new
rules
folks with varying levels of the gem and/chefDK get different results.
It's
unclear to me how ChefDK (which as I understand, suggests you can do away
with Gemfiles) solves this issue?
I'm somewhat new to Chef and Ruby in general, so please bear with me (
and
feel free to correct any misguided statements! )
From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I
slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the
same
gem versions that I used.
My confusion stems with how this is supposed to work with ChefDK.
Suppose
that I use ChefDK to create my cookbook, do all my development and
testing
and release it to a public repo. My colleague, however, doesn't have
ChefDK
and grabs my repo. How is he supposed to know what gems I used? My
first
answer would be - I either document it in the README or I just say
'Install
ChefDK v0.3.5'. Another option would be to manually create a Gemfile
for
everything that I used out of ChefDK and include that along with my
repo?
But in both cases, I'm having to keep some extra piece of information
up to
date with everything I'm using out of ChefDK ( or just telling him he
better
install it ). Am I missing something there?
The second scenario I'm hazy about is when you get into the situation
when
we start drifting between ChefDK versions. Perhaps I haven't upgraded
my
ChefDK for awhile and you're on the latest and greatest. What's
keeping us
in sync, so that we're using the same versions of Test Kitchen,
ChefSpec,
etc? Or does it not matter, because in general, the differences
between the
gems provided in different ChefDK versions isn't a big enough concern?
I understand ( I think ), that if I start using 3rd party gems that
aren't
included in ChefDK, I should be bundle installing them and including the
Gemfile. I think it's the two scenarios above that I'm unsure about
and I'm
curious how others are doing this.
I've read a few blog posts and the previous mail on the list chef - [chef] Re: Chef-DK Question, but I
think
I'm still confused enough what the vision/workflow is that I had to ask.
yo,
ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks' Gemfiles, or even mega repository
Gemfiles. I don't think I've heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.
One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.
I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn't take an hour to
compile on smaller rigs
I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.
Thanks AJ, this is exactly what we've done as well. Just let ChefDK
get all the rights bits, but we are still using gemfiles and Bundler,
I can't recall where I saw/heard it, but there was some suggestions
that ChefDK could do away with these complexities.
I've just been adding chef-dk to Gemfiles. This was a little
problematic with the chef-12 it required getting into fights with other
things that required chef-11 deps (test-kitchen in particular), but
that should all be getting ironed out as those other gems are getting
bumps to deal with chef-12.
I avoid Gemfiles in projects where ChefDK already includes the things that
would be installed in the bundler. Think test-kitchen, chefspec, etc.
However, as I do use ChefDK's Ruby as my primary Ruby VM on my workstation,
I vendor bundles with binstubs in non-Chef project repositories (like my
blog, which is octopress).
E.g.,
bundle install --path=vendor --binstubs
This avoids some weird gem conflicts when they're installed in my GEM_HOME
(~/.chefdk/gem).
Thanks AJ, this is exactly what we've done as well. Just let ChefDK get
all the rights bits, but we are still using gemfiles and Bundler, I can't
recall where I saw/heard it, but there was some suggestions that ChefDK
could do away with these complexities.
On Thu, Dec 18, 2014 at 4:23 PM, AJ Christensen <
aj@junglistheavy.industries> wrote:
For what its worth, I share your confusion here. We've historically
used the
Gemfile approach as well and as we transition to ChefDK, I still feels
like
we need this... As very simplistic example we use rubocop to enforce
rules
(build fails if there are offenses). Since new version introduce new
rules
folks with varying levels of the gem and/chefDK get different results.
It's
unclear to me how ChefDK (which as I understand, suggests you can do
away
with Gemfiles) solves this issue?
I'm somewhat new to Chef and Ruby in general, so please bear with me (
and
feel free to correct any misguided statements! )
From what I understand, pre-ChefDK, people would use bundler to pin the
gem versions they used to develop/test their application/cookbook. I
slap
it all into a Gemfile, bundle install, commit the Gemfile.lock. You
download my repo, you bundle install and you immediately have all the
same
gem versions that I used.
My confusion stems with how this is supposed to work with ChefDK.
Suppose
that I use ChefDK to create my cookbook, do all my development and
testing
and release it to a public repo. My colleague, however, doesn't have
ChefDK
and grabs my repo. How is he supposed to know what gems I used? My
first
answer would be - I either document it in the README or I just say
'Install
ChefDK v0.3.5'. Another option would be to manually create a Gemfile
for
everything that I used out of ChefDK and include that along with my
repo?
But in both cases, I'm having to keep some extra piece of information
up to
date with everything I'm using out of ChefDK ( or just telling him he
better
install it ). Am I missing something there?
The second scenario I'm hazy about is when you get into the situation
when
we start drifting between ChefDK versions. Perhaps I haven't upgraded
my
ChefDK for awhile and you're on the latest and greatest. What's
keeping us
in sync, so that we're using the same versions of Test Kitchen,
ChefSpec,
etc? Or does it not matter, because in general, the differences
between the
gems provided in different ChefDK versions isn't a big enough concern?
I understand ( I think ), that if I start using 3rd party gems that
aren't
included in ChefDK, I should be bundle installing them and including
the
Gemfile. I think it's the two scenarios above that I'm unsure about
and I'm
curious how others are doing this.
I've read a few blog posts and the previous mail on the list chef - [chef] Re: Chef-DK Question, but I
think
I'm still confused enough what the vision/workflow is that I had to
ask.
yo,
ChefDK includes bundler and all of the dependencies one would
typically have in their cookbooks' Gemfiles, or even mega repository
Gemfiles. I don't think I've heard any suggestion that it does away
with Gemfiles, but in many common cases, probably can.
One might even define their own modified generators to include
pre-populated Gemfiles, in some cases.
I use the same flow as before except now my colleagues have ChefDK
manage their workstation installs. Bundle still works for berks, tk,
kitchen-docker, blah blah except gecode doesn't take an hour to
compile on smaller rigs
I hit something weird the other day where using
/opt/chefdk/embedded/bin in $PATH caused pkg-config in the Omnibus
ChefDK to be used instead of my systems, which broke a ton of other
builds, and was resolved with PKG_CONFIG_PATH or a PATH= adjustment.
Choosing to pollute my shells global environment was on me, though.
