Gemfile.lock

[causton81]

It seems like excluding the .lock file from the git repo will yield a poor experience for new developers as they may get new incompatible versions of dependencies. There was a comment that excluding the lock file helps support multiple versions of Vagrant (and Ruby?). I'm curious if the lock file from the oldest supported version of vagrant+ruby will work with all newer versions of vagrant-softlayer. I tried to test with ruby 1.9.3-p547 but the unit tests fail to run because the newest vagrant git gem uses the double star hash feature which is not available until ruby 2.0 (def self.command(name, **opts, &block)) . If different versions of vagrant do require a different set of gems, then seems like that should be handled by multiple versions of the vagrant-softlayer provider as well. Perhaps vagrant doesn't support this type of versioning on providers; the vagrant plugin install command would have to pick different versions...

[ju2wheels]

When you did that test what version of the vagrant gem did it try to test against?

[causton81]

vagrant (1.6.5 6986a8e)

[causton@jedis vagrant-softlayer]$ rvm current ruby-1.9.3-p547@vsl [causton@jedis vagrant-softlayer]$ ruby --version ruby 1.9.3p547 (2014-05-14 revision 45962) [x86_64-linux] [causton@jedis vagrant-softlayer]$ which bundle ~/.rvm/gems/ruby-1.9.3-p547@vsl/bin/bundle [causton@jedis vagrant-softlayer]$ bundle list Gems included by the bundle:

• akami (1.2.2)
• builder (3.2.2)
• bundler (1.6.7)
• celluloid (0.16.0)
• childprocess (0.5.5)
• configparser (0.1.3)
• diff-lcs (1.2.5)
• erubis (2.7.0)
• ffi (1.9.6)
• gssapi (1.0.3)
• gyoku (1.2.2)
• hashicorp-checkpoint (0.1.4)
• hitimes (1.2.2)
• httpclient (2.5.1)
• httpi (0.9.7)
• i18n (0.6.11)
• listen (2.7.11)
• little-plugger (1.1.3)
• log4r (1.1.10)
• logging (1.8.2)
• mini_portile (0.6.0)
• multi_json (1.10.1)
• net-scp (1.1.2)
• net-ssh (2.9.1)
• nokogiri (1.6.3.1)
• nori (1.1.5)
• rack (1.5.2)
• rake (10.3.2)
• rb-fsevent (0.9.4)
• rb-inotify (0.9.5)
• rb-kqueue (0.2.3)
• rspec (2.14.1)
• rspec-core (2.14.8)
• rspec-expectations (2.14.5)
• rspec-mocks (2.14.6)
• rubyntlm (0.1.1)
• savon (0.9.5)
• softlayer_api (3.0.0)
• timers (4.0.1)
• uuidtools (2.1.5)
• vagrant (1.6.5 6986a8e)
• vagrant-softlayer (0.4.0)
• wasabi (1.0.0)
• wdm (0.1.0)
• winrm (1.1.3) [causton@jedis vagrant-softlayer]$

[ju2wheels]

Vagrant had just pinned its ruby version to >=2.0 recently at 1.6.0 here so thats an expected issue you are hitting. Have no clue how to fix it though. If you look at the upstream changelog Vagrant 1.0.1 released with embedded ruby 1.9.3p125, so it shouldnt be using anywhere near vagrant 1.6.5 at your ruby release. Unfortunately they dont keep good track of what embedded ruby version they released with in between from that point forward.

vagrant plugin install is just a wrapper around bundler/gem so it will go for the newest compatible gem from rubygems.org by default unless you give it a specific version or gem file.

FYI, if you havent read through the upstream issues before, problems with vagrant/bundler and the way it resolves deps in its plugin ecosystem is not a new thing.

[causton81]

This post has some interesting ideas on when to omit the lock file: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/

I think I get what he's saying and I think I agree :) The .gemspec file is the correct place to specify required packages and version ranges for that gem.