search

berkshelf / vagrant-berkshelf

A Vagrant plugin to add Berkshelf integration to the Chef provisioners
Other
379 stars 100 forks source link

Break dependency on Chef DK #282

Closed paulmccallick closed 9 years ago

paulmccallick commented 9 years ago

It would be great if this plugin was not dependent on the ChefDK. Some of us do not want to use it, as adding yet another install of Ruby and gems adds an unnecessary layer of complexity on top of ruby development.

reset commented 9 years ago

@paulmccallick packaging and distributing Ruby applications is a painful experience. Unfortunately we can't compile and link to our dependencies and the best way to ensure the user's environment is as expected is to distribute your own Ruby environment. The ChefDK is a common environment that Chef developers have agreed to work within to make this easier on the end-user.

Disk space is basically free and there is no disadvantage to using the ChefDK alongside your own Ruby environment. There are a slew of compatibility guarantees, though :smile:.

paulmccallick commented 9 years ago

When asked, the ChefDK team does not see advanced ruby devs as their audience. They readily admit that those who know what they are doing shouldn't use it. They see ChefDK is intended as an helpful tool, not a requirement for doing chef development.

Also, it DOES introduce problems. It can get into fights with your regular ruby gems.

for thos who agree with me:

I have aliased 'vagrant' to 'chef exec vagrant' and not included chefdk in my path.

reset commented 9 years ago

@paulmccallick I work closely with the ChefDK team and that is not a sentiment that I'm aware of. The purpose of the ChefDK from the outstart was to provide a mechanism to distribute tooling to all developers. If the ChefDK didn't happen the Berkshelf team, like Vagrant's, was going to package up Berkshelf into an installer and distribute it.

I use the ChefDK and I'm an "advanced Ruby dev". If you'd like to detail the problems you're having with gem conflicts I'll happily walk you through how to mitigate it. My team and I haven't had an issue like that in a very long time.

paulmccallick commented 9 years ago

Thank you for offering to help. Here are some scenarios:

We are still on berks 2 in places. Berks 3 broke compatibility with the the berks file and broke the ability to use your chef server as a source for cookbooks. So we have chefspec tests that depend on berks2, and then vagrant comes along and starts demanding berks 3.

we also have windows devs who would like to be able to run our chefspec tests in windows...and that isn't happening with berks3. It used to work in berks2...

Another example is firing up vim which suddenly starts using the rubocop in my ChefDK folder.

Berks as a package...that would have been nice, but only if people stopped doing "require 'berkshelf'", like chefspec does. Perhaps the berkshelf gem would become just a wrapper around the package kind of like the 'git' gem (or kitchen-vagrant). In other words, be a package or a gem but don't be both.

sethvargo commented 9 years ago

Berkshelf 3 is almost 2 years old now (it will be two years old on July 12, 2015). Pulling from a Chef Server is the main source of your problems because it is not an API server. Vagrant isn't "demanding" support for Berkshelf 3, it's using the latest version (which is two years old already).

If there are bugs in Berkshelf 3, I would recommend opening them on the project so we can get them fixed instead of pinning to a version that was terrible (fundamentally) and is no longer maintained :smile:.

ChefSpec does not require "berkshelf" unless you require "chefspec/berkshelf" - if you don't want the Berkshelf integration, then don't require that file. Nothing is automatically loaded except the core of ChefSpec.

As with Jamie, I would consider myself an "advanced Ruby dev", and I have also never experienced these issues. Granted, I'm not on Windows, but that seems like a separate issue than what you've detailed here.

reset commented 9 years ago

@paulmccallick as @sethvargo pointed out, you're mostly having these issues becuase you're using a version of Berkshelf that is almost two years old. Berkshelf 3 didn't break compatibility with the ability to use your Chef Server as a source of cookbooks, it greatly improved upon that. You need to configure an API server to front the Chef Server. It's extremely easy to setup - there are instructions in the README.

The other issues you're having are easily fixed by setting up your shell environment and bundler environment. For example, VIM doesn't vindictively choose the version of rubocop that you don't want to use :smile:. It's reading some environment variables and deciding to use that version.