Hello, Use of alternative ruby profile breaks work of vagrant with LoadError due to ruby/gem version mismatch. Reproducible: Always Version: app-emulation/vagrant-1.8.1::gentoo USE="virtualbox {-test}" RUBY_TARGETS="ruby21 -ruby20" Steps to Reproduce: 1. emerge =app-emulation/vagrant-1.8.1 2. change ruby profile to ruby23 3. run 'vagrant version' Expected Results: display vagrant version info # eselect ruby set ruby21 # vagrant version Installed Version: 1.8.1 Latest Version: 1.8.1 Actual Results: ruby/gem version mismatch # eselect ruby set ruby23 # vagrant version ruby: No such file or directory -- /usr/lib64/ruby/gems/2.3.0/gems/vagrant-1.8.1/lib/vagrant/pre-rubygems.rb (LoadError) Looks like lack of proper wrapper script for me.
# vagrant version -> this is returned from calling vagrant itself via ruby. Since you have RUBY_TARGETS="ruby21", only ruby21 libs will be installed and not even vagrant version can return anything. The vagrant shell script is just a minimalistic wrapper that could eventually return a warning if the ruby libs are not present. So instead of: # vagrant version ruby: No such file or directory -- /usr/lib64/ruby/gems/2.3.0/gems/vagrant-1.8.1/lib/vagrant/pre-rubygems.rb (LoadError) You would get: # vagrant version Sorry, no vagrant for ruby target 2.3 installed Do you see that as a beneficial change?
Proposed workaround will not lead to a correct work of utility (vagrant in this particular case), just die with a more user-friendly error message. In gentoo we have good example of wrapper solution for python: $ head -n1 /usr/bin/ansible #!/usr/bin/python-exec2c Haven`t met something close to it for ruby. Nevertheless, some other ruby scripts use shebang to define ruby interpreter, for example: $ head -n1 /usr/bin/puppet #!/usr/bin/ruby20 or even: #!/usr/bin/env ruby21 I have one RUBY_TARGETS enabled for this packages therefore for me it`s perfectly fine to have specific ruby version set in shebang, but if both targets are enabled we definitely require some advanced wrapper.
Topic was changed back by me not intentionally.
(In reply to Lik from comment #2) > Proposed workaround will not lead to a correct work of utility (vagrant in > this particular case), just die with a more user-friendly error message. Yes, the utility will not work, because it works only with Ruby 2.0 or 2.1, but you switch to Ruby 2.3. When we bumped Vagrant to 1.8.1, it simply couldn't work with anything above 2.1. So, what would you propose - what should the wrapper script do in case you switch to Ruby 2.3? Find the working ruby interpreters plus the RUBY_TARGETS and start with a working Ruby version? > > In gentoo we have good example of wrapper solution for python: > > $ head -n1 /usr/bin/ansible > #!/usr/bin/python-exec2c Ansible is special, because it's Python2 only (2.7 in our case), does not work with Python3 yet. > > Haven`t met something close to it for ruby. Nevertheless, some other ruby > scripts use shebang to define ruby interpreter, for example: > > $ head -n1 /usr/bin/puppet > #!/usr/bin/ruby20 > > or even: > > #!/usr/bin/env ruby21 > > I have one RUBY_TARGETS enabled for this packages therefore for me it`s > perfectly fine to have specific ruby version set in shebang, but if both > targets are enabled we definitely require some advanced wrapper. Well that's the question. We can for example prefer Ruby 2.1 and if it won't work, fallback to Ruby 2.0.
>> So, what would you propose - what should the wrapper script do in case you switch to Ruby 2.3? >> Find the working ruby interpreters plus the RUBY_TARGETS and start with a working Ruby version? I expect correct work of utility regardless of main\active ruby interpreter defined in system because package dependencies are met. Just run it under one of supported ruby version defined at package RUBY_TARGETS (presumably latest supported, ruby21 in this case). Maybe ansible package is not the best one to demonstrate the power of wrapper, we can take sys-apps/portage as example. Agree with you it looks more like feature request.
I've done some 'ugly' hacking[1] and it works on single ruby, regardless of what you current profile is (even with rvm). I was trying to add ruby single eclass, but it would require preparing patches for each supported ruby version anyway :/ 1. https://bitbucket.org/szymonsz/gen2-overlay/src/a021945fab954c591a92042d3930df1eca5fb7cf/app-emulation/vagrant/vagrant-1.8.4.ebuild?at=master&fileviewer=file-view-default
(In reply to Szymon Szypulski from comment #6) > I've done some 'ugly' hacking[1] and it works on single ruby, regardless of > what you current profile is (even with rvm). I was trying to add ruby single > eclass, but it would require preparing patches for each supported ruby > version anyway :/ > > 1. > https://bitbucket.org/szymonsz/gen2-overlay/src/ > a021945fab954c591a92042d3930df1eca5fb7cf/app-emulation/vagrant/vagrant-1.8.4. > ebuild?at=master&fileviewer=file-view-default Thanks Szymon for the patch, I think it's considerable. However it means no one with only Ruby 2.0 can run it.
Bit by this just today. jesse@fuji-02 Sat Jun 25 19:00:22 ~/.rbenv/versions/2.1.10/lib/ruby/gems/2.1.0/gems/ (master) vagrant ruby: No such file or directory -- /home/jesse/.rbenv/versions/2.1.10/lib/ruby/gems/2.1.0/gems/vagrant-1.8.4/lib/vagrant/pre-rubygems.rb (LoadError) jesse@fuji-02 Sat Jun 25 19:03:59 ~/.rbenv/versions/2.1.10/lib/ruby/gems/2.1.0/gems/ (master) jesse@fuji-02 Sat Jun 25 19:03:59 ~/.rbenv/versions/2.1.10/lib/ruby/gems/2.1.0/gems/ (master) rbenv versions system * 2.1.10 (set by /home/jesse/.rbenv/version) jesse@fuji-02 Sat Jun 25 19:04:29 ~/.rbenv/versions/2.1.10/lib/ruby/gems/2.1.0/gems/ (master) (I really want to run it under the latest officially stable Ruby, version 2.3.1, but tried 2.1.10 to see if that improved my chances. Nope.) Let me know if you-all need more info. Thanks.
Terribly sorry, my issues appears to have been a shell environment problem.
(In reply to Tomáš Mózes from comment #7) > Thanks Szymon for the patch, I think it's considerable. However it means no > one with only Ruby 2.0 can run it. Ruby 2.0 is no longer supported upstream and on its way out in Gentoo via bug 576034
Version 1.8.7 supports all current ruby impls (2.0-2.3) so the problem should not occur at the moment.
Ruby 2.4 has been stable for a while. Is i t possible to have it as one of the RUBY_TARGETS for vagrant?
(In reply to Ivan Iraci from comment #12) > Ruby 2.4 has been stable for a while. Is i t possible to have it as one of > the RUBY_TARGETS for vagrant? Haven't checked yet, but from their gemspec (https://github.com/mitchellh/vagrant/blob/master/vagrant.gemspec): s.required_ruby_version = "~> 2.2", "< 2.4"
(In reply to Ivan Iraci from comment #12) > Ruby 2.4 has been stable for a while. Is i t possible to have it as one of > the RUBY_TARGETS for vagrant? First all dependencies need to catch up as well. Ruby 2.3 currently seems like a more realistic candidate.
(In reply to Hans de Graaff from comment #14) > First all dependencies need to catch up as well. Ruby 2.3 currently seems > like a more realistic candidate. All dependencies ready and tests pass, so I've added the ruby23 target.
https://github.com/gentoo/gentoo/pull/6126
Please try 2.0.1,it tries with the highest ruby version to the lowest.
Created attachment 502898 [details] emerge --info
It does not work for me, I am getting: $ vagrant Ignoring bindex-0.5.0 because its extensions are not built. Try: gem pristine bindex --version 0.5.0 Ignoring byebug-9.1.0 because its extensions are not built. Try: gem pristine byebug --version 9.1.0 /usr/bin/vagrant: line 8: ruby22: command not found /usr/bin/vagrant: line 50: exec: : not found I do not have ruby 2.2 in targets (I have attached emerge --info). I am using RVM.
(In reply to Szymon Szypulski from comment #19) > It does not work for me, I am getting: Please provide the exact steps how to reproduce. Hopefully we can come up with something after that.
1. Set RUBY_TARGETS to "ruby23 ruby24" in /etc/portage/make.conf. 1. Install system ruby $ emerge =ruby-2.3.5 =ruby-2.4.2 1. Set 2.3 as default ruby $ eselect ruby set ruby23 1. Install vagrant $ emerge =vagrant-2.0.1 1. Install rvm (https://rvm.io/) $ curl -sSL https://get.rvm.io | bash -s stable 1. Install ruby 2.4.2 through rvm and set it as default $ rvm install 2.4.2 $ rvm use 2.4.2 --default 1. Try to run vagrant $ vagrant /usr/bin/vagrant: line 8: ruby22: command not found /usr/bin/vagrant: line 50: exec: : not found
Thanks,I'll try. Why do you need rvm on gentoo?
I work with projects using various ruby versions, if ruby version is defined in Gemfile (https://bundler.io/v1.5/gemfile_ruby.html) RVM can read it and switch on the fly. Just to be clear, I do not expect from Gentoo to be RVM compatible, but you wrote you have fixed RVM compatibility and I wanted to check it. Since it is an edge case, I completely happy with hacking my own ebuild version.
(In reply to Szymon Szypulski from comment #23) > I work with projects using various ruby versions, if ruby version is defined > in Gemfile (https://bundler.io/v1.5/gemfile_ruby.html) RVM can read it and > switch on the fly. Ok, thanks for clarification. > Just to be clear, I do not expect from Gentoo to be RVM compatible, but you > wrote you have fixed RVM compatibility and I wanted to check it. Since it is > an edge case, I completely happy with hacking my own ebuild version. This bug was about that your primary ruby interpreter may not be the one that is listed in RUBY_TARGETS for vagrant - I believe this should be fixed. So you installed vagrant with targets ruby22 and ruby23, but your ruby is now using ruby24, that failed before. Now we just iterate the version until we found one. While I haven't used rvm before, I would be happier if you don't have to hack your vagrant ebuilds - let's merge it in the gentoo tree. How do you need to change your ebuild to make it work with rvm? Will it also work with regular ruby? I hope we can come up with something that will work for all users. Thanks for the details so far, right now I can at least see how one uses rvm and what needs to be fixed.
I am basically hardcoding path to one of rubies from my RUBY_TARGETS in vagrant binary. So, I assume it behaves like RUBY_SINGLE_TARGET for the ebuild?
(In reply to Szymon Szypulski from comment #25) > I am basically hardcoding path to one of rubies from my RUBY_TARGETS in > vagrant binary. So, I assume it behaves like RUBY_SINGLE_TARGET for the > ebuild? So it means you have the system ruby and vagrant with some ruby targets and you run vagrant with the system ruby (but you also have rvm installed). Because the script tries the ruby binaries like ruby24, ruby23 and ruby22, does it mean that rvm replaces these with the rvm ruby binaries? Does it mean that ruby23 now executes the ruby inside your homedir instead the one from /usr/bin?
1. RVM does not override `ruby<xy>` binaries. They always point to system ruby. 2. This loop (https://github.com/gentoo/gentoo/blob/master/app-emulation/vagrant/files/vagrant.in-r1#L7) does not detect ruby binary properly, because when I run: ruby23 /usr/lib64/ruby/gems/2.3.0/gems/vagrant-2.0.1/bin/vagrant version I am getting: /usr/lib64/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file -- log4r (LoadError) from /usr/lib64/ruby/site_ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib64/ruby/gems/2.3.0/gems/vagrant-2.0.1/bin/vagrant:61:in `<main>' Probably due to RVM overwriting GEM_PATH. If I add export GEM_PATH="/usr/lib64/ruby/gems/2.3.0" before vagrant execution, it works fine. unset GEM_PATH Works too, at least for "vagrant version"
Ok, so if we move https://github.com/gentoo/gentoo/blob/master/app-emulation/vagrant/files/vagrant.in-r1#L47 to the top, will it work properly on your system with rvm?
Almost! Unfortunately if you have any plugins that should be reinstalled, script fails silently with same message as previous: /usr/bin/vagrant: line 8: ruby22: command not found If you will remove "/dev/null" redirection from this line https://github.com/gentoo/gentoo/blob/master/app-emulation/vagrant/files/vagrant.in-r1#L11 and try again, you will see: > Vagrant failed to initialize at a very early stage: > > The plugins failed to initialize correctly. This may be due to manual > modifications made within the Vagrant home directory. Vagrant can > attempt to automatically correct this issue by running: > > vagrant plugin repair > > If Vagrant was recently updated, this error may be due to incompatible > versions of dependencies. To fix this problem please remove and re-install > all plugins. Vagrant can attempt to do this automatically by running: > > vagrant plugin expunge --reinstall > > Or you may want to try updating the installed plugins to their latest > versions: > > vagrant plugin update > > Error message given during initialization: Unable to resolve dependency: user > requested 'vagrant-cachier (> 0)' This returns non-0 exit code, so wrapper fails silently. I had to run - "unset GEM_PATH GEM_HOME; ruby23 /usr/lib64/ruby/gems/2.3.0/gems/vagrant-2.0.1/bin/vagrant plugin repair" and now everything works fine.
To be honest, why do you need to check if you can execute vagrant binary from default gem path for given ruby? What problem does it solve? Is not enough to assume it is fine - set ruby variable in the wrapper - if VAGRANT_EXECUTABLE exists (for this ruby version)?
(In reply to Szymon Szypulski from comment #30) > To be honest, why do you need to check if you can execute vagrant binary > from default gem path for given ruby? What problem does it solve? Is not > enough to assume it is fine - set ruby variable in the wrapper - if > VAGRANT_EXECUTABLE exists (for this ruby version)? Should be fixed by https://github.com/gentoo/gentoo/pull/6352.
I can confirm, works great for me! Thanks for you work.
Hopefully it's sorted out now.
