-- UPDATE --
Ok its fixed. This is what I did. remove all ruby and rubygems completely. then install ruby1.9.1-full and rubygems1.9.1 then install the twitter gem.
Hi guys,
I am having trouble working with the Twitter gem. I am using ruby 1.8.7
After installing when I try to run a simple script I get this error
ruby twitter.rb
./twitter.rb:5: uninitialized constant Twitter (NameError)
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in gem_original_require'
from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:inrequire'
from twitter.rb:2
I running this on a Ubuntu box. I checked with gem -list and I see the Twitter (1.1.0) is listed there.
this is the code I am trying to run
require "rubygems"
require 'twitter'
puts Twitter.user_timeline("test").first.text
Any ideas ?
I believe it only works with Ruby 1.9 If you want to use twitter gem try version 0.9 with Ruby 1.8.x
This works for me:
ruby-1.9.2-p0 > require 'twitter'
=> true
ruby-1.9.2-p0 > puts Twitter.user_timeline("test").first.text
TExES Pedagogy and Professional Responsibilities EC-12 Teacher Certification Test Prep Study Guid… - by Sharon A Wynne http://amzn.to/f3kF74
=> nil
which version of ruby are you using?
gouravtiwari21's comment seems to fix the problem, but it's wrong to suggest that the twitter gem requires 0.9.0 if you want to run it using Ruby 1.8.x.
You can check out the version compatibility here:
http://travis-ci.org/#!/jnunemaker/twitter
It shows the twitter gem working with Ruby installs as low as 1.8.7.
For me, it was an issue with having the correct dependent gems, as well as the correct versions.
Here's how I got it working:
I ran:
sudo gem list
And compared the versions of specific gems with what I found here:
https://github.com/jnunemaker/twitter/blob/master/HISTORY.md (I simply searched for the word 'dependency' to see which versions twitter cared about.
I also found this diff:
https://github.com/jnunemaker/twitter/commit/ac8114c1f6ba2da20c2267d3133252c2ffc6b6a3
And I compared the gems listed there with what I had installed, and I just made sure my system lined up with what I was seeing in the version notes. Oftentimes what happened is that I had multiple versions of a gem, and for some reason, the lower version was taking precedence.
I'm not sure why I still have to add
gem 'twitter', '1.7.1'
to my Gemfile, but alas, that's the last step required in order to get this stuff working.
Don't forget to restart your server, and you should be good!
Related
I am completely new to ruby, don't know the 1st thing about rvm, gemset etc. Just forced to use a CLI tool (kensa by heroku) written in ruby and facing an issue.
The kensa tool seems to use a gem named rest-client. When I run it it throws an error:
/Users/shaharsol/.rvm/gems/ruby-2.4.2/gems/rest-client-1.8.0/lib/restclient/request.rb:163:in `fetch': key not found: :ciphers (KeyError)
Some searches suggest that v1.8 of rest-client is too old so I installed v2.0.2. Now when I do a gem list I get:
rest-client (2.0.2, 1.8.0)
When I run kensa again it still used to old version. So I went and modified it kensa.gemspec file (which is referred to from Gemfile) and to my best understanding told it to use the newer version:
s.add_runtime_dependency(%q<rest-client>, "~> 2.0")
Yet, when I run kensa again, it still uses the old rest-client 1.8.0!
What am I missing? What am I doing wrong? Or what else is required for the kensa to run with the new rest-client 2.0.2 ???
PS - If my problem doesn't relate at all to changing 1.8.0 => 2.0.2 please tell me what else to do. I really don't care which rest-client version kensa uses, I just need it to run!
To remove older version of the gem, you have two options:
# remove all versions of the gem
gem cleanup rest-client
After this, you can do 'bundle install' and only install the version you want.
# choose which one you want to remove
gem uninstall rest-client --version 1.8.0
After this, you will only have 2.0.2 version.
Hope this solves your problem.
In ~/src/project/ containing all the files, I'm attempting to run bundle and bundle install, but it tells me I need a gem called "buff-extensions" and that gem installer requires Ruby version >= 2.2.0 to work properly.
When I ran ruby --version, it said Ruby 2.2.4p230 is being used when run from that directory.
I know there are several versions of Ruby on the machine in several places, and I'm struggling to follow the paths and figure out which technology is using which piece.
The Bundler docs spell this out:
You can specify the required version of Ruby in the Gemfile with ruby. If the Gemfile is loaded on a different Ruby version, Bundler will raise an exception with an explanation.
ruby '1.9.3'
What this means is that this app has a dependency to a Ruby VM that is ABI compatible with 1.9.3. If the version check does not match, Bundler will raise an exception. This will ensure the running code matches. You can be more specific with the :engine and :engine_version options.
ruby '1.9.3', :engine => 'jruby', :engine_version => '1.6.7'
I finally figured out the exact incantation in order to get the intended result, and I now realize the situation is unreasonable to expect any stranger to attempt to answer.
It involved chef, and I was supposed to run chef exec bundle.
I'm new to Ruby and I'm having a lot of trouble trying to use Nokogiri. I've been trying to find a resolution for hours now, so any help is appreciated. I tried searching for and using solutions from other related SO posts before caving and posting my own. When I run ruby -v I get: ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
(Edit: I have updated ruby with updates-alternatives --config ruby and selected /usr/bin/ruby1.9.1 but when I do ruby -v it is now showing version 1.9.3 WTF am I doing wrong here?)
I have a new project directory at ~/workspace/ruby/rubycrawler/ and I used Bundler to install nokogiri, which installed correctly:
Using mini_portile (0.5.2)
Using nokogiri (1.6.1)
Using bundler (1.5.1)
Your bundle is complete!
Running bundle show nokogiri returns /var/lib/gems/1.9.1/gems/nokogiri-1.6.1.
In the directory I'm running the script from I have a simple html file named "index.html". The script I'm trying to run is even simpler (or so I thought):
require 'nokogiri'
page = Nokogiri::HTML(open("index.html"))
puts page.class # Nokogiri::HTML::Document
The error is rubycrawler.rb:1:in 'require': no such file to load -- nokogiri (LoadError).
I also added require 'rubygems' even though I read it isn't needed for 1.9+ and still no luck.
A lot of searching shows "Did you put this gem in your Gemfile?". So I generate a Gemfile and add gem 'nokogiri'. I try running the small script again and get the same error. I read "Try deleting Gemfile.lock." so I did but still couldn't get it to work. I then read to try testing it out in irb so I tested "open-uri" and "nokogiri" and here's what I got:
irb(main):001:0> require 'open-uri'
=> true
irb(main):003:0> require 'nokogiri'
LoadError: no such file to load -- nokogiri
I'm really having a lot of trouble figuring this out, so really any help at all is really appreciated.
Ruby tools like RVM, Bundler, etc., to the novice, appear to do a lot of magic, but really, there is no magic to them. The key here lies in what Bundler actually does for you. It manages a manifest of dependencies, BUT at runtime, those dependencies STILL have to get loaded somehow, and my gut feeling is that is what is not happening here.
Regardless of what version of Ruby you are using, if you are using Bundler, there's an easy way to do this. Precede the command that starts your program with "bundle exec" and that will make Bundler edit Ruby's load path so that it includes all the things in the manifest (Gemfile.lock).
For example:
$ bundle exec ruby foo.rb
A additional note for anyone using RVM: RVM generally will modify the shebangs in the scripts that launch programs like "ruby" or "rake" so that they use the "ruby_no_exec" shell (or similar) instead of the plain old "ruby" shell. That alternate shell is Bundler-aware and makes it generally unnecessary to type "bundle exec," but since the OP is using system Ruby, that's not applicable and commands should be manually prefixed with "bundle exec".
Hope this helps!
In addition to Kent's answer, I would recommend switching to RVM instead of using the system installed ruby. System rubies tend to be horribly out of date, especially when it comes to important things like features and security updates. It might not help you in your current situation, but it would be well worth the time. If you are unfamiliar: http://rvm.io
I'm trying to run a Ruby application that requires Sinatra within Ubuntu 10.10. I'm new to the 3 of these technologies so I understand if this question looks dumb to you.
Yesterday I installed ruby doing...
sudo apt-get install ruby1.9.1-full
And sinatra by doing...
sudo gem install sinatra
This is the code I'm trying to run:
require 'rubygems'
require 'sinatra'
get '/' do
"Hi Alex!"
end
When I do ruby1.9.1 -rubygems app.rb nothing happens (Ruby is properly installed since I tried running apps that don't require sinatra and they work OK).
$ ls
app.rb
$
$ ruby1.9.1 app.rb
$
$ ruby1.9.1 -rubygems app.rb
$
I know it should open Sinatra and tell me which port it is listening to.
I've been looking for help through the web and read several of the threads created within this forum but nothing I've tried has worked out for me.
What could be happening here?
Thanks
There was a similar problem with sinatra 1.0 on ruby 1.9.2. The answer there was to add enable :run to your code.
Have a look at the docs for the :run configuration - if you're going to be deploying to a server you'll want to do something like enable :run if __FILE__ == $0 so that you only start the built-in server during development when you need it.
Strictly speaking your code is correct and should run okay, and in fact it does with ruby 1.8.7 and 1.9.2. The problem seems to be running it with ruby 1.9.1. In general 1.9.1 seems to be fairly outdated and you should probably look to upgrade to 1.9.2 if you can. If Ubuntu doesn't have any packages for 1.9.2 take a look at rvm. (In fact if you're going to be doing ruby development rvm is worth a look anyway).
Update:
I managed to get ruby 1.9.1 compiled to test this, and your code worked ok. Also a bit of googling suggests that the Ubuntu ruby1.9.1 package provides ruby 1.9.2 anyway. So there seems to be something else going on causing :run not to be set when running the file directly, though I don't know what that could be.
Another update:
Looking at the Ubuntu Sinatra package it looks like it's at version 1.0. It could be that your setup is using the Ubuntu
package and ignoring the more recent version installed via rubygems. This could explain what's happening. If so this isn't a "a similar problem" to ruby 1.9 and sinatra 1.0 like I suggested above, it's the same problem!
Yet another update:
A couple of things have occurred to me. You can check what version of Sinatra you're actually using with something like puts Sinatra::VERSION after require 'sinatra'. Also, it looks like there is a gem1.9.1 command that corresponds to ruby1.9.1. It looks like when you installed sinatra with sudo gem install sinatra the latest version got installed into the ruby 1.8 install, and left ruby 1.9 with the Ubuntu packaged Sinatra 1.0. If you haven't switched over to rvm yet, you could try sudo gem1.9.1 install sinatra.
How can you determine which rubygem is being used in response to a "require" statement? gem which doesn't seem to help.
Background: for the project hornsby-herbarium-parser, I'm using the gem roo.
I used the github gem hmcgowan-roo , as at that time it was more recent than the rubyforge version of roo. I tried testing the code on runcoderun, and it failed because it doesn't have any version of roo. By this time, new versions of roo were available on both github and rubyforge.
I decided I may as well see if the latest version from rubyforge works for my code, as I assume rubyforge is more official, authoritative, and stable than github forks. Once I'm sure the rubyforge version works with my code, I'll ask runcoderun nicely if they can install it on their system.
I sudo gem installed roo, and my gems now include "hmcgowan-roo (1.3.5)" and "roo (1.3.6)", and running the tests for hornsby-herbarium-parser still pass. I know that as the rubyforge version was installed more recently, it ought to be the one being used in the tests, but I want to be able to verify this.
gem which roo
Didn't help, because it gave me
(checking gem hmcgowan-roo-1.3.5 for roo)
/usr/lib/ruby/gems/1.8/gems/hmcgowan-roo-1.3.5/lib/roo.rb
which I assume is the wrong answer.
Update: I used both
$:.detect {|dir| dir =~ /roo/}
and
puts Roo::VERSION::STRING
both agree with gem which, saying that I'm still using hmcgowan-roo-1.3.5.
puts Roo::VERSION::STRING
First of all, rubygems will load the highest version number gem, not the most recently installed. So you should be getting roo 1.3.6 here.
Other than that, I second gerrit's suggestion to look for a version constant. For instance, I just loaded rmagick and there is a constant Magick::Version. Another example is Open4::VERSION.
However not all gems have a version constant, so as a fallback you could do something hacky like:
>> require 'open4'
=> true
>> $:.detect {|dir| dir =~ /\/open4-([^\/]*)\//}
=> "/Library/Ruby/Gems/1.8/gems/open4-0.9.6/bin"
>> $1
=> "0.9.6"
gem list xxx
it defaults to load the latest version.
you can do use Gem::VERSION
require 'rubygems'; puts Gem::VERSION
that in a ruby program, which is quite useful if you want to make sure that your application under same version of rubygems accrossing all machines (e.g. bundler Gemfile)
The simplest way will be to uninstall and then reinstall the rubygems individually.
I'm not so sure that your assumption about github not having stable sources is so accurate.