I seem to have an issue with the version of a gem that I am using.
I have no internet access, I downloaded the gem straight from the Rubyforge and then SCPed it to the target machine and I used gem install --force --local to install it. Ruby/Rubygems comes from a snapshot of the EPEL repo taken about a month ago. It is hosted on on a machine in the network and YUM is configured across the network to point to the correct location.
I am trying to use the Net::SSH family of gems (Net:SSH, Net::SSH::Shell, Net::SSH::Multi, Net::SSH::Gateway, Net::SCP). When I run my file.rb I get this:
/usr/lib/ruby/site_ruby/1.8/rubygems.rb:779:in `report_activate_error': RubyGem version error: net-ssh(2.6.6 not ~> 2.1.0) (Gem::LoadError)
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:214:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:249:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `each'
from /usr/lib/ruby/site_ruby/1.8/rubygems.rb:248:in `activate'
from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:35:in `require'
from ./cluster_config.rb:12
I have seen a lot of issues around the internet about the actual version being less that than the expected version, but I have only found on example where the actual version was newer than the expected, but it was "resolved" with a response from the OP saying "My buddy got it, thanks."
This is also the first time I have seen the ~> operator in this use. Usually I have seen the >= operator here.
Any suggestions?
~> is used inside Gemfiles to allow a gem to be used whose patch version is greater or equal to the specified version, provided that the major and minor versions are identical. For example:
~> 2.1.0 would allow version 2.1.9, but not 2.2.0 or 2.0.0.
~> 2.1.3 would also allow 2.1.9 but not 2.1.0 or 2.2.0.
Also, you could probably download the exact version you need directly from RubyGems. In your case, the link would be http://rubygems.org/downloads/net-ssh-2.1.0.gem .
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.
I'm just trying to use the simple career_builder gem and just get it imported by running the simple script:
require 'career_builder'
puts 'Hello world!'
and yet get the following error: /Library/Ruby/Site/2.0.0/rubygems/dependency.rb:315:in 'to_specs': Could not find 'activesupport' (~> 2.3.5) - did find: [activesupport-4.2.1,activesupport-3.1.12,activesupport-3.0.3] (Gem::LoadError)
I installed the gem with gem install career_builder and ran bundle install and even updated activesupport to the most recent version, but for some reason, the program can't find the newer version of activesupport. Does the gem require version 2.3.5?
http://guides.rubygems.org/patterns/
The ~>or 'twiddle-waka' is a ruby gems shortcut to specify the earliest version of the gem you can use without letting you go up to the next major release.
Your gem is being a bit unorthodox and also specifying a patch level.
So the gem_specification you're working with (activesupport' (~> 2.3.5)) really means minimum version of 2.3.5 maximum of the last patch released before 2.4.0.
The activesupport versions you have installed are all for subsequent major releases and won't work. Install something between 2.3.5 and 2.4.0 and you should be good to go.
Yes. It does require Active Support version >= 2.3.5 and < 2.4.0. All of your Active Support versions are > 2.4.0.
~> is called the spermy operator. See Meaning of tilde-greater-than (~>) in version requirement?
The gem has not been updated in 4 years, so it uses Rails 2.
FWIW, I don't think you'll have much luck getting it to work, so you may want to find a similar gem that works with Rails 4 and has been updated within the last few months.
I'm attempting to build local Ruby documentation as suggested here:
https://github.com/toy/doc
However when I use the default Rakefile I get the following:
[Documentation]$ rake build
configuring and updating: 100.0%
rake aborted!
undefined method `available?' for Gem:Module
/Users/snowcrash/.rvm/gems/ruby-2.0.0-p195/gems/sdoc-0.2.20/lib/sdoc/json_backend.rb:9:in `<top (required)>'
Any suggestions?
I don't know much about ruby (and even less about the gem ecosystem built up around it), but I believe a possible workaround for this issue is to find what gems the project requires and manually install them. In the case of this particular project, it looks like you need the gem "fspath".
At the project root, type
gem install fspath
and try re-running rake.
I honestly don't know the actual root cause of the issue, other than that presumably, your version of the 'gem' program is probably > v2, while some other program (rake?) expects it to be older and still support the "available?" method.
If installing "fspath" doesn't fix the issue, you could try downgrading your version of gem by doing
gem install -v [some version of gem older than v2]
Check gem install --help for more info on this.
This is just for future visitor who has the same issue.
As ekremkaraca said, you can just solve this by downgrading rubygems.
rvm install --force rubygems 1.4.2
I am working on a gem and it's on github.
When I include the gem in an application, do a capistrano deploy, and (on the server) run:
bundle outdated
I see:
* authengine (0.0.1 d8baa49 > 0.0.1 de43dfa)
which tells me that a more recent commit is available. Why doesn't the bundle update (part of capistrano deploy) pull the more recent version? There is no version constraint in the Gemfile of the host application, and anyway they have the same version number, just different commits.
Even if I log into the server and run
bundle update authengine
I get the same "outdated" result afterwards.
What am I missing here?
One thing I've found that can cause this is if other gems in the bundle make requirements on gems by version that are incompatible. Bundler tries to reconcile these by selecting versions of gems such that their requirements can all be satisfied. The result is that it quietly refuses to update gems.
The way to check this is to set an explicit version requirement in your Gemfile. Something like
gem "authengine", "> 0.0.2" #(you'll need to bump the version to make this work)
#or
gem "authengine", :ref => "d8baa49"
Then run
bundle update authengine
You should see something like (this is taken from my particular case):
Bundler could not find compatible versions for gem "json": In
Gemfile:
chef (> 10.8) ruby depends on
json (<= 1.6.1, >= 1.4.4) ruby
logical-construct (>= 0) ruby depends on
json (1.7.5)
So, in my case it's a problem with explicitly requiring a newer version of json.
The author, André Arko, stated in 2014 that:
The Bundler resolver is definitely a work in progress, and we adjust
the tradeoffs between specific versions and resolving quickly based on
user feedback.
Bundler has consistently not provided the newest possible version of
every gem for the entirety of its existence, and it does result in a
lot of tickets being opened. In most cases, it turns out to be the
result of Bundler having to pick between the newest version of one gem
or a different gem, and Bundler picks the gem the user doesn’t care
about having the newest version of. That’s why it’s so important to
make your Gemfile version requirements accurately reflect your actual
requirements.
I recognize that your assumption that Bundler would give you the
newest possible version seemed valid at the time, but the docs only
say that you will get a version that meets your requirements, not the
latest. Is there anywhere we could expand the docs to make it clearer
that the newest versions of everything simply isn’t feasible?
What is the output returned when you run bundle update authengine? Does it actually say it updated the gem? Or does it ignore the gem?
You can try using the --source parameter to specifically tell Bundler to use the git repository. That, or your
bundle update authengine --source https://github.com/mustardseeddatabase/authengine.git
Also, when unexpected things like this happen, I like to clean up my gemlist in general. It could be that you still have older versions of the gem laying around, not using in bundler.
So you could do:
gem list
gem check
gem cleanup
Or do a complete reinstall
gem uninstall authengine
bundle install
I am trying to install chiliproject on a server, following the -well done- documentation I am hitting this error
Could not find gem 'rubytree (~> 0.5.2) ruby' in any of the gem sources listed in your Gemfile.
I did a gem install rubytree
I get this message
========================================================================
Thank you for installing rubytree.
WARNING: SIGNIFICANT API CHANGE in 0.8.0 !
------------------------------------------
Please note that as of 0.8.0 the CamelCase method names are DEPRECATED.
The new method names follow the ruby_convention (separated by '_').
The old CamelCase methods still work (a warning will be displayed),
but may go away in the future.
Details of the API changes are documented in the API-CHANGES file.
========================================================================
Successfully installed rubytree-0.8.1
1 gem installed
Installing ri documentation for rubytree-0.8.1...
file 'COPYING,API-CHANGES' not found
Installing RDoc documentation for rubytree-0.8.1...
file 'COPYING,API-CHANGES' not found
That is saying the installation was succesful. So why do I get the error ?
If the error is from the API change how can I request version 0.5.2 of the rubytree gem ?
When I do a gem list --local | grep 'rubytree'
I have this output rubytree (0.8.1)
So why is the system saying could not find gem 'rubytree' ?
thank you for any help,
Depending on what version of rails you are using (and it sounds like you are using a relatively newer one, if it's prompting you for your Gemfile), then you need to use Bundler to manage your gems.
Try editing your Gemfile, adding a new line that reads:
gem "rubytree", "< 0.6"
Then open up a console, and type this command
bundle install
This should fix your problems, but if you still get errors when running a command, then try typing bundle exec prior to the command (i.e. rails server becomes bundle exec rails server).
Currently, we require rubytree exactly in version 0.5.2 or 0.5.3, as specified in our Gemfile, the 0.8.1. version you installed by hand will not suffice that requirement, which is exactly what the error message states.
What seems a bit odd is the literal ruby in the error message. Could you please make sure that you have the exact unchanged Gemfile from the source on your system? Also, could you please remove any user-installed plugins and try again? Also, which ruby (type and version) on which operating system are you using?