I am getting the following error each time i try run my app through pow
Bundler::RubyVersionMismatch: Your Ruby version is 1.9.3, but your Gemfile specified 2.0.0
I am just trying to link my project with pow and apparently i have a different version of ruby? i am using rbenv to manage my ruby versions. i have set rbenv to set 2.0.0-p0 locally, if i call ruby -v i get ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin12.4.0]
$rbenv versions
system
1.9.3-p327
* 2.0.0-p0 (set by /Users/fortknokx/Personal work/cave/.rbenv-version)
i tried to 'rbenv rehash' and refresh the '.ruby-version' nothing seems to convince pow that i am using ruby 2.0.0
The full stack on the error that i get from pow is as follows
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/definition.rb:361:in `validate_ruby!'
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-1.3.5/lib/bundler.rb:116:in `setup'
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/setup.rb:17:in `<top (required)>'
~/.rbenv/versions/1.9.3-p327/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in `require'
~/.rbenv/versions/1.9.3-p327/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in `rescue in require'3.5/lib/bundler/definition.rb:361:in `validate_ruby!'
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-1.3.5/lib/bundler.rb:116:in `setup'
~/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/bundler-1.3.5/lib/bundler/setup.rb:17:in `<top (required)>'
~/.rbenv/versions/1.9.3-p327/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in `require'
~/.rbenv/versions/1.9.3-p327/lib/ruby/1.9.1/rubygems/custom_require.rb:60:in `rescue in require'
some how pow thinks i am on 1.9.3-p327?? any one had a simular issue. is it a ruby 2.0.0 thing or is it pow and rbenv having a boxing match?
There are some issues with using pow and rbenv as chronicled here: rbenv does not work well with pow
The problem seems to center on some PATH issues with the powconfig file, hence the reason pow is trying to use your default ruby install (assuming 1.9.x) vs. what you designated via rbenv. If you are using OSX mavericks, add the following to your ~/.powconfig file, restart pow once the change is made, and you should be good to go. (per the last suggestion):
export RBENV_ROOT=/usr/local/var/rbenv # Might not be necessary for pre-Mavericks OSX
eval $(rbenv init -)
export PATH=$(rbenv root)/shims:$(rbenv root)/bin:$PATH
Related
I can install charlock_holmes gem on opensuse, trying to open it up in irb quickly, I get this:
> irb
2.3.0 :001 > require 'charlock_holmes'
LoadError: /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes/charlock_holmes.so:
undefined symbol: _ZTIN6icu_538ByteSinkE - /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes/charlock_holmes.so
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /home/wpostma/.rvm/gems/ruby-2.3.0/gems/charlock_holmes-0.7.3/lib/charlock_holmes.rb:1:in `<top (required)>'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
from /home/wpostma/.rvm/rubies/ruby-2.3.0/lib64/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
from (irb):1
from /home/wpostma/.rvm/rubies/ruby-2.3.0/bin/irb:11:in `<main>'
2.3.0 :002 >
It looks to me like maybe something in charlock_holmes is incompatible with the libicu version inside tumbleweed.
I'm using ruby installed with rvm, and purging all my gemsets and reinstalling does not fix it. Any other ways to get charlock_holmes to work? Maybe I need to install a special copy of libicu (earlier, older) and point the gem at it?
Either of these works. For me the bundle config option works better.
This is a direct command to install the gem, directing it towards the correct libicu version:
gem install charlock_holmes -- --with-icu-dir=/usr/local
This is a command to tell which ever ruby project I install later on this system, will get gems installed by bundler to just work instead of breaking:
bundle config build.charlock_holmes "--with-icu-dir=/usr/local" --global
Since I'm using rvm the above bundle configuration seems to be "global" to that rvm environment only.
In my case, the bundle config is helpful as a large series of actions that would have otherwise failed (installing gems, and bootstrapping a large rails application) just worked.
I know that rb-appscript is officially no longer supported.
However, I tried and found that rewriting existing libraries to use alternative methods (e.g. osascript) was a non-trivial work and it occurred to me that monkey-patching rb-appscript to work again seemed like a better approach, if ever possible.
Here's what happens.
$ rvm 2.0.0
$ gem install rb-appscript
$ irb
> require 'appscript'
LoadError: cannot load such file -- _aem/mactypes
from ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
from ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require'
from ruby-2.0.0-p0/gems/rb-appscript-0.6.1/lib/appscript.rb:8:in `<top (required)>'
from ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in `require'
from ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:110:in `rescue in require'
from ruby-2.0.0-p0/lib/ruby/site_ruby/2.0.0/rubygems/core_ext/kernel_require.rb:35:in `require'
What change in Ruby 2.0.0 is causing this?
It seems that there was a bug in Rubygems 2.0.0, and upgrading to 2.0.2 by
gem update --system
fixed the problem.
install ruby 1.9.3, devkit, mingw
gem install rails work good, but when i create new rails app - have bundler error
D:/Programes/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': 193: %1 эх ты хЄё яЁшыюцхэшхь Win32. - D:/Programes/Ruby193/lib/ruby/1.9.1/i386-mingw32/digest/sha1.so (LoadError)
from D:/Programes/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/definition.rb:1:in `<top (required)>'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler.rb:138:in `definition'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/cli.rb:219:in `install'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/task.rb:22:in `run'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/invocation.rb:118:in `invoke_task'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor.rb:263:in `dispatch'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/lib/bundler/vendor/thor/base.rb:386:in`start'
from D:/Programes/Ruby193/lib/ruby/gems/1.9.1/gems/bundler-1.0.21/bin/bundle:13:in `<main>'
and commands like
D:\Work\ruby>gem help commands
ERROR: Loading command: server (LoadError)
193: %1 эх ты хЄё яЁшыюцхэшхь Win32. - D:/Programes/Ruby193/lib/ruby/1.9.1/i386-mingw32/digest/md5.so
ERROR: While executing gem ... (NameError)
uninitialized constant Gem::Commands::ServerCommand
file md5.so exists
what i forgot to do and may ruby don`t work on windows 7 x64?
I think you use cyrillic without # encoding: UTF-8, just add it to file where you use эх ты...
P.S.: откуда вообще там кирилица?
Also running Windows 7 x64, and I had this same problem crop up on me with 1.9.3-p0. Searched the web without success. Also tried copying in the "sha1.so" file from 1.9.2-p290 in case it was a problem with that particular library -- nope.
I'd suggest something about rubygems or bundler seems to break require, but the same bundler and rubygems code runs fine on 1.9.2. I get no problem running require "digest/sha1"
in my own bare test file with Ruby 1.9.3.
Reverting to Ruby 1.9.2-p290 fixed the problem for me for the moment.
I have installed Ruby v1.9.2, and (according to the instructions on http://rubyonrails.org/download) I am trying to install Gems. I've downloaded the 1.4.2 zip from http://rubyforge.org/frs/?group_id=126, but when I run setup.rb, I get the following error/trace:
C:\temp\rubygemsInstall\rubygems-1.4.2\rubygems-1.4.2>setup.rb
C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems/source_index.
rb:62:in `installed_spec_directories': undefined method `path' for Gem:Module (N
oMethodError)
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems/
source_index.rb:52:in `from_installed_gems'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems.
rb:914:in `source_index'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems/
gem_path_searcher.rb:83:in `init_gemspecs'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems/
gem_path_searcher.rb:13:in `initialize'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems.
rb:873:in `new'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems.
rb:873:in `searcher'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems.
rb:495:in `find_files'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems.
rb:1034:in `load_plugins'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/lib/rubygems/
gem_runner.rb:84:in `<top (required)>'
from <internal:lib/rubygems/custom_require>:29:in `require'
from <internal:lib/rubygems/custom_require>:29:in `require'
from C:/temp/rubygemsInstall/rubygems-1.4.2/rubygems-1.4.2/setup.rb:25:i
n `<main>'
I am running Windows Server 2008 R2 - please post a comment if there is any other relevant info.
How do I get around this error?
The windows RubyInstaller includes rubygems already, so you don't have to install it separately. I'm assuming you're using RubyInstaller because that's what the rubyonrails.org page links you to if you click on the Windows link, but there is more information on the RubyInstaller page in the Help section.
What happens if you go to a cmd prompt and do "gem list"?
Older versions of rubygems aren't completely compatible with Ruby 1.9.2. I realize the OP discovered that rubygems was already installed, but for those who still need to install it, all you need to do is downgrade to Ruby 1.8.7 and then it should work properly. This is where a tool like RVM really comes in handy.
I use RVM and have some legacy projects where I use Ruby 1.8.7, rails 2.3.x, rspec 1.3.0 and rspec-rails 1.3.2. But after installing Ruby 1.9.2 and some gems rvm is messing up the Gem paths for 1.9.2 and my 1.8.7 gemset:
When I run my specs with rake I get the following error:
"\"/home/vermelho/.rvm/gems/ruby-1.8.7-p302#rails2/gems/paperclip-2.3.3/data/paperclip\""
config.load_paths is deprecated and removed in Rails 3, please use autoload_paths instead
config.load_paths= is deprecated and removed in Rails 3, please use autoload_paths= instead
Exception encountered: #<OptionParser::InvalidOption: --loadby>
backtrace:
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/core/option_parser.rb:18:in `parse!'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/core/option_parser.rb:4:in `parse!'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/core/configuration_options.rb:64:in `parse_command_line_options'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/core/configuration_options.rb:46:in `parse_options'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:7:in `initialize'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/monkey/spork/test_framework/rspec.rb:4:in `new'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/rspec-core-2.1.0/lib/rspec/monkey/spork/test_framework/rspec.rb:4:in `run_tests'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/run_strategy/forking.rb:13:in `block in run'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/forker.rb:21:in `block in initialize'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/forker.rb:18:in `fork'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/forker.rb:18:in `initialize'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/run_strategy/forking.rb:9:in `new'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/run_strategy/forking.rb:9:in `run'
/home/vermelho/.rvm/gems/ruby-1.9.2-p0/gems/spork-0.8.4/lib/spork/server.rb:47:in `run'
/home/vermelho/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1558:in `perform_without_block'
/home/vermelho/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1518:in `perform'
/home/vermelho/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1592:in `block (2 levels) in main_loop'
/home/vermelho/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1588:in `loop'
/home/vermelho/.rvm/rubies/ruby-1.9.2-p0/lib/ruby/1.9.1/drb/drb.rb:1588:in `block in main_loop'
In the gemset I currently use rspec 2 is not installed, and my current ruby installation and gemset should know nothing about gems from another ruby installation, right?
I just ran into the same problem. The answer is that spork is running using another version of ruby, likely for another ruby application. Rspec tries to connect to spork if using the --drb option. Spork uses the version of rspec it already has loaded. Easy solution, stop the other spork process before trying to run rspec.
I do not believe that this problem has anything to do with RVM.
I've never seen RVM do that so I suspect something was preexisting then RVM was loaded into the system. Was Ruby 1.8.7 a system-install or were some of the gems loaded outside of RVM? If so RVM can't really do much to corral the pre-existing configurations.
The only other thing I can think of is that Rails captured the paths to the gems, then you installed RVM. I did my Rails installs under RVM, then converted to Rails 3 and upgraded my projects with everything under RVM control and didn't see what you are.
You might need to ask Wayne Seguin (wayneeseguin in #rvm on irc.freenode.net) for some help. I'm pretty sure he'll ask what version of RVM you're on so have the output of rvm -v ready. The current rev as of right now is:
rvm -v
rvm 1.0.21 by Wayne E. Seguin (wayneeseguin#gmail.com) [http://rvm.beginrescueend.com/]