This is more curiosity question and not a problem. When many version are present on the system which ones are chosen when require command is used? Background of the story is: I was implementing bundler gem in project (not Rails project). I had no issues but other developers had issues, after quick investigation I realized that I did not use
require "bundler/setup"
which basically loads up bundled gems. Quick fix, but it got me wondering how does ruby via rubygems decide which gems to use. Since code broke because Ruby application used older version of one of the gems, and not the newer one. Meaning it does not use the "newest" gems, so what is logic behind it?
UPDATE
To further explain this question let say you have gems foo-1.0.1 and foo-1.0.2 when you say, require 'foo' how does ruby know which one to load?
In Ruby you require a file rather than a gem. If that file isn’t found on the current load path, Rubygems will search the installed gems for a file with that name, and if it finds one the gem is activated (meaning that it gets added to the laod path) and the file is then required. Normally a gem will have a file with the same name in its lib dir. Only one version of a gem can be activated.
The gem that gets activated is the latest version available that is compatible with any other activated gems. Normally this will just mean that the latest version installed wil be activated, but this might not be the case if you have already activated some gems which declare dependencies on earlier version of the gem you’re trying to activate.
For example, if you have foo-1.0.1 and foo-1.0.2 installed, then require 'foo' (assuming they have a file named foo.rb in their lib dirs and no other gem does) will cause version 1.0.2 to be activated. However if you also have a gem bar which has a dependency on 1.0.1 then calling require 'foo' after bar has been activated will cause 1.0.1 of foo to be activated.
Futhermore, if you try to require them in the other order, require 'foo'; require 'bar'; then you will get something like
Gem::LoadError: Unable to activate bar-1, because foo-2 conflicts with foo (= 1)
Here you can’t activate bar, which depends on version 1.0.1 of foo because you have already activated version 1.0.2 of foo.
Without Bundler, you have to specify each gem you want. e.g.,
require 'my_gem'
require 'my_other_gem'
However, Bundler can make this a bit easier for you using a Gemfile
If this is your Gemfile
gem 'my_gem'
gem 'my_other_gem'
Calling this will include all gems
require 'bundler/setup'
Related
I'm trying to run bundle install on my rails project (I've just added Nokogiri) but I ran into a permission error. I installed rbenv (which seems like the right way to go) to get around that problem but now I'm getting
Could not find gem 'open-uri (>= 0) ruby' in the gems available on this machine.
I know that open-uri is part of ruby though so why am I getting this error?
OpenURI is part of the Ruby Standard library, it is not a gem. You therefor do not need to include it in your Gemfile, just require it in your code.
require 'open-uri'
open('http://stackoverflow.com/')
Ruby is so darn mysterious when it comes to using the gems! Where do these gems reside?? In java, you can have as many jars you want just include them in your CLASSPATH and your good to go. Ruby is a simpler language, but why do I need the headache of dealing with simple crap? Can anyone seriously finally explain how the gem loading process works? It seems like no one really knows why the heck do requiring some gems work, and requiring others doesn't even if you have gem installed them and they are in the gem list. Where is the authority in ruby on this site that can finally clarify the gem loading process.
I am tried of including 'rubygems' in my ruby scripts to prevent errors like LoadError: no such file to load -- pony
And even when I do require 'rubygems' in my scripts, it still gives LoadErrors. Even if the gem is in my gem list.
When you're using Bundler to manage Gems in your project (you will have a Gemfile at the root directory of the project), be sure to run
bundle install
requiring rubygems just loads rubygems itself (and isn't required in ruby 1.9 and above)
You need to actually load each gem individually via require.
If you use bundler, then you can optionally have bundle auto require everything from your Gemfile
for a Ruby standalone script what Rails like deployment features such as Gemfile / "bundle install" etc
that is assuming you are developing a Ruby script that you want to test and then deployment, and perhaps ship to others, what Rails like deployment approach would you use for say:
a) GEM - marking GEM requirements & having them installed as required - e.g. Rails "Gemfile" where you mark what gems you need and then "bundle install" to install them
b) File Require - automatically loading *.rb files if they are in your script directory (I'm thinking of in Rails where if you put a class file in the apps/model directory Rails automatically load/require's the file for you)
depends on whether it's a tool you expect people to use on every host they find it on or not. also depends on whether the tool can be shared with pubic repos.
if it just has to work, without worrying about whether you've installed the gems via bundler already or not, you can use something like the following from within your standalone script to install gems if not already present (be mindful of system vs. user ruby):
#!/usr/bin/env ruby
require 'rubygems'
def install_gem(name, version=Gem::Requirement.default)
begin
gem name, version
rescue LoadError
print "ruby gem '#{name}' not found, " <<
"would you like to install it (y/N)? : "
answer = gets
if answer[0].downcase.include? "y"
Gem.install name, version
else
exit(1)
end
end
end
# any of the following will work...
install_gem 'activesupport'
install_gem 'activesupport', '= 4.2.5'
install_gem 'activesupport', '~> 4.2.5'
require 'active_support/all'
...
In my humble opinion, a gem is the way to go. Bundler makes it easy to get started; it starts a skeleton for you when you run the command…
bundle gem <GEM_NAME>
Take a look. As long as you specify your dependencies in your gem's .gemspec file, and somebody installs your packaged gem (they won't need bundler, just RubyGems' gem command), the dependencies will be installed as gems along with it.
I'm writing an app that will run scripts in a specified folder, and then record the numbers and graph them.
My problem is that if the script is a ruby file, the require statements fail inside the script because bundler seems to have done something funky with the load path.
Running rails runner Datasource.run_jobs fails:
class Datasource < ActiveRecord::Base
def self.run_jobs
require 'aws_sdb'
access_key_id = "REDACTED"
secret_key = "REDACTED" # In all actuality these woudln't be here.
#sdb = AwsSdb::Service.new(:access_key_id => access_key_id, :secret_access_key => secret_key)
Datasource.all.each do |ds|
puts "Updating #{ds.name}..."
unless #sdb.list_domains.include? ds.name
puts "#{ds.name} doesn't exist in SDB, creating a domain for it..."
#sdb.create_domain ds.name
end
#data = "TEST"
data = `#{RAILS_ROOT}/lib/plugins/#{ds.name}`
#sdb.put_attributes(ds.name, Time.now.to_i, data)
puts "Data Collected: #{data.inspect}"
end
end
has_many :graphs
end
(Basing this off your comments on the question)
You will need to add hpricot (and any other gem this needs) to your Gemfile so that they are made available by Bundler. Bundler is by far the easiest way to avoid gem conflicts and tomfoolery.
Imagine this situation: You somehow lose the gems that you have currently. Be this happening through a format or system change or any other reason. Whatever it is, you've lost your gems. How are you going to re-install all your gems? You could keep a list of them somewhere else yourself, but is this truly likely?
Bundler solves this problem by making you state what gems your application requires and only adding those gems to the load path, which is why you can't find hpricot. When you run bundle install the first time, this creates a Gemfile.lock which contains something like this:
GEM
remote: http://rubygems.org/
specs:
abstract (1.0.0)
actionmailer (3.0.0)
...
Because you commit this file to your source control "solution" of choice (be it Git, SVN, FTP, whatever, it's not important) you have a solid way of specifying the precise gems and precise versions of those gems that your application uses.
When/If your gems are wiped, you can simply clone your project again and run bundle install. Because the Gemfile.lock file exists, you'll have exactly the same gems you had originally, even if there were updates.
If you don't want the exact same gems, just run bundle update and this will ignore the specifications in Gemfile.lock and instead revert to depending on Gemfile to define them. This will check for new versions of gems and install them, updating the Gemfile.lock when it's done.
Honestly, I don't understand the Bundler hate. If you could explain in wider terms than "OMG IT SUCKS YEHUDA IS SATAN", I'd be much obliged.
Edit: WedTM asked for a sample Gemfile and related code:
In the Gemfile you'd have this:
group(:scripts) do
gem 'gem1'
end
To require these gems for your scripts:
require 'bundler'
Bundler.require(:scripts)
You may also wish to require the default gems too which you can do by just adding default anywhere to the arguments of require:
Bundler.require(:default, :scripts)
If this for some reason doesn't work I would imagine it would be because it can't locate the Gemfile. This can be fixed by setting the ENV['BUNDLE_GEMFILE'] to the path to the Gemfile.
I wonder if you might be able to use RVM to set up the ruby environment before running your scripts. Maybe something with a gemset like:
data = `rvm gemset use scripts; #{RAILS_ROOT}/lib/plugins/#{ds.name}`
Let's say in a Rails app you have some gems that you use in your app (we'll call them "primary gems") and you have vendored them for portability.
Let's say that those "primary gems" also require gems of their own - we'll call these "secondary gems".
When you are setting up your environment.rb, you have to say:
config.gem 'primary-gem'
for any of the gems you are using directly.
But, do you also need to say . . .
config.gem 'secondary-gem'
even if you are not using that gem explicitly in your app?
Or is it simply enough to include the gem in your vendor/gems directory for it to get picked up by your app?
At deploy time rails knows about your dependencies, so if you want to freeze your gems then you can run
rake gems:unpack:dependencies
to freeze them into the vendor directory.
At runtime however it's the gems job to load it's dependencies, and usually the gems do this, so a config.gem 'primary' should work.
No, you don't or at least you shouldn't. Each GEM specification should include it's own list of dependencies. When primary gem is installed, RubyGems automatically will install each gem dependency on cascade.
In other words, if A requires B that requires C+D, you only need to write
config.gem 'A'
When the command
gem install A
is run, RubyGems will resolve all the dependencies and install them.
You can view all A dependencies running (from a Rails project)
rake gems
Sometimes, a GEM author may forget to include some GEM dependencies in the specification. In this case you should specify them in your environment.rb to force the application to install them. Off course, it's also a good idea to contact the GEM maintainer so that it can fix the problem.