- From: Erik Hollensbe <
>
- To:
- Subject: [chef] Re: Re: Re: Chef, test-kitchen, vagrant and net-ssh fun
- Date: Thu, 14 Feb 2013 08:33:18 -0500
Bundler (and rubygems, but only secondary) is the problem here. There's a workaround for some situations at the end of this email, but requires changes to the code.
vagrant depends on net-ssh 2.2.2 (and an older version of net-scp) which conflicts with chef's dependency on newer versions of net-ssh. I already had a PR rejected by Mitchell to resolve this the day of the 10.20/11.2 release, and I'll leave it there.
Bundler "works" with vagrant and chef in the same gemfile because it actually won't let you bundle versions of chef greater than 10.18 -- and unless told to use something newer will have no qualms lowering the version of chef to satisfy its dependencies. If you use 10.20 or later, bundling won't even work. If you're on 11, you're probably going to have a bad day.
This is bundler (and rubygems) doing the right thing from their perspective, it's just that vagrant and chef are at odds of which version of net-ssh they need.
Berks and Chef-Workflow have the same problem with each other, and with vagrant. Berks (and Librarian) depend on constrained versions of chef and c-w tries very hard NOT to force chef versions on the user, allowing them to tailor the Gemfile to select that themselves. c-w works around this for the berks case by making you install it as a separate dependency and executing it with Bundler.with_clean_env (which allows rubygems to deal with the dependencies independently of Bundler). Since it runs berks as a command line tool, this works.
It still depends on vagrant as a library though (knife-server also has this issue but that's a little easier to deal with on a number of levels). If you use vagrant as a command line tool, you can get users to do the same thing for it as we do with berks/librarian in c-w, but they will have to install it independently.
Archive powered by MHonArc 2.6.16.