I have ruby v 1.8 installed at C:\Ruby and its gems underneath.
I am planning to upgrade to v 1.9 , and it's installer try to default the app to c:\Ruby 1.9
How shall i proceed in order not to break my old gems .. including Rails , etc?
Thanks
Using the RubyInstaller, can I install Ruby 1.8 and 1.9 at the same time?
A: Yes. By using the RubyInstaller, Ruby 1.8 will be installed by default
to C:\Ruby, while 1.9 will be installed to C:\Ruby19. This is by design as
Ruby 1.8 and 1.9 offer a different API that may interfere with some RubyGems.
Source: http://wiki.github.com/oneclick/rubyinstaller/faq#dual_install
So go ahead and use the default of installing to C:\Ruby19.
Related
I just upgraded by ruby to 2.7.0.
And I tried to install the ibm_db gem in windows platform. Installation works fine. When I try to use the gem(like require 'ibm_db') I get the following error
LoadError (126: The specified module could not be found. - C:/Ruby27/lib/ruby/gems/2.7.0/gems/ibm_db-5.1.0-x86-mingw32/lib/mswin32/rb2x/i386/ibm_db.so)
I have faced this type of error in ruby 2.6 also but when I have set RUBY_DLL_PATH to the ddl which the gem uses it is solved.
But in ruby 2.7 even after setting this variable I get the following error.
Can anyone please help in solving this? ( I have one more doubt:- c gems are supported in ruby 2.7)
It appears that the ibm_db gem currently does not support Ruby 2.7 yet. The newest Ruby version they support is Ruby 2.6.x.
There is a pull request at https://github.com/ibmdb/ruby-ibmdb/pull/105 which might add support for Ruby 2.7 though.
The issue is because the binary was pointed to ruby 2.6 binary. So replace it with the latest ruby 2.7 binary and then everything works fine.
Thanks,
Akhil
I have both Ruby 1.9 and 2.1 installed in my computer. Now I am wanting to use several of the gems installed for Ruby 2.1 in Ruby 1.9. However, Ruby 1.9 can't find them.
I tried to solve this problem by setting the environmental variable RUBYLIB but since there were so many gems that needed to be used I can't do it one by one. Is there an easier way?
For example, one of the packages I would like to use in Ruby 1.9 is pango.
Its path is ~/ruby/lib/ruby/gems/2.1.0/gems/pango-2.2.0/
All of the packages installed for Ruby 2.1 can be found at ~/ruby/lib/ruby/gems/2.1.0/gems
Thanks you.
I'd suggest you use a manager like rvm (https://rvm.io/) or rbenv (https://github.com/sstephenson/rbenv) to avoid manually configuring your environment. I use rvm even when I have only one Ruby version installed.
I have multiple Rails apps from 3.2.14 to 3.2.18 in my development environment. I'm using Ruby 1.9.3 (yes, I know) for these apps and it's installed and managed via rbenv. I'm about to build a couple of new apps with Rails 4.1 and Ruby 2.1. My question is, what is the best way to handle installing multiple versions of Ruby using rbenv. Currently 1.9.3 is set to global, but I want different Rails apps (4.1) to use Ruby 2.1.
I guess I'm a bit behind the curve with Ruby management so I could use a hand here. Again, looking to have multiple Rails apps (different versions 3.2.14-4.1.x) and multiple Ruby instances to support each app.
I appreciate the help in advance.
Create a .ruby-version file in your application root directory and specify the ruby version you want. For instance, if you want one application to use 1.9.3 and the other 2.1.0, you'll have a .ruby-version file each in those two applications, specifying the version:
/application1/.ruby-version
1.9.3
/application2/.ruby-version
2.1.0
Update
For every installed version of ruby, you'll have a shims directory which will house all your gems for that particular version. When you switch between ruby versions, rbenv will simply set the environment variables to the one you select.
In the example above, I set the local ruby version for the directory ruby_cookbook to 2.1.2 and a gem list will only show gems installed for 2.1.2.
I also created a .ruby-version with ruby version 1.9.3-p547 in my try_stuff directory. As you can see, gem list only shows gems installed for 1.9.3.
The gems you install are specific to the current version of ruby.
If your project root has a .ruby-version file, your environment will automatically set the current ruby version to the one specified. So, yes, your production environment will need the version you mention in your .ruby-version. If you use git for source control, you can add that file to your .git-ignore and you won't see it in your prod version.
Can Chef support newer versions of Ruby i.e. 2.0.0?
If not , is there a reason why?
In the documentation it specified up to 1.9.2
https://wiki.opscode.com/display/chef/System+Requirements+with+install (dead link)
Chef 11.6+ supports Ruby 2.0. Versions less than that will only work on Ruby 1.8 and 1.9.
Sources:
I work for Opscode
I use Chef on Ruby 2.0, 1.9, and 1.8
Documentation might need some updating. Chef supports ruby 2.0 according to this blogpost
http://www.opscode.com/blog/2013/09/03/chef-10-28-0-released/
Find the latest requirements at https://docs.chef.io/chef_system_requirements.html
Currently, Ruby 2.2.2 (or higher)
I'm using Ruby 1.9.2 (Yarv).
When I install gems I just use "gem install ".
How can I know which Ruby version they are written in: 1.8.7, 1.9.1 or 1.9.2?
If I'm using the latest version and I install a gem that is written in 1.8.7, then that gem doesn't work?
Eg. Yardstick gem seems to not work with 1.9.2 but perfectly with 1.8.7.
How do you check what version each gem is using?
Could someone enlighten this topic for me.
Unfortunatelly there is no definitive way to check that as there are so many versions and variants or Ruby interpreters (Ruby, JRuby, Iron Ruby) and system platforms. Also one gem which is pure Ruby may not work on all platforms with same interpereter verson, because some OS specific properties could be used.
So you must trust the autor or docs he/she provided. Another way to make sure that your platform is right for gem just run tests enclosed to gem - every well written gem should have such.
There is also small tip: if file contains
# -*- encoding: utf-8 -*-
then autor probably developed the gem with 1.9.x in mind.
There's a website for answering the question: "Is it Ruby 1.9?"
http://isitruby19.com/
It doesn't look like anyone has reported on Yardstick yet:
http://isitruby19.com/yardstick
You could be the first, and report that it's broken in 1.9.