very new to coding so, having exhausted Google and Stack Overflow, would really appreciate some advice...
I am currently building a web-scraper to get familiar with CMD vs Sublime Text, feeling Ruby in action; So i am working my way through this tutorial
After having actioned in CMD
C:\gem install HTTParty
SUBLIME TEXT - starts with this code:
require_relative 'HTTParty'
require_relative 'Nokogiri'
etc
But before i can get to anything more from CMD, i hit web_scraper.rb and it returns with:
C:/Users/ATH18/Desktop/nokogiri_tutorial/web_scraper.rb:1:in `require_relative': cannot load such file -- C:/Users/ATH18/Desktop/nokogiri_tutorial/httparty (LoadError)
from C:/Users/ATH18/Desktop/nokogiri_tutorial/web_scraper.rb:1:in `<main>'
[Finished in 0.1s with exit code 1]
I think this has to be due to one of the following:
i) maybe gems have to have their actual files dragged into whatever folder you're creating a new program in?
ii) i'm missing another piece of information that would let it run properly?
iii) perhaps there's another way to tell CMD/ruby that the "require"d gem is not in the current folder (I read this somewhere but their advice didnt seem to work either).
NOTE - i have done gem install xxxxxx in both the C:\ directory and C:\users\desktop\projectFolder\
Help?
You have to use require instead of require_relative. The difference between both a is explained here: https://stackoverflow.com/a/3672600/92049
Use require 'GEMNAME' for gems installed with gem install GEMNAME; use require_relative 'PATH' to require a file relative to the file containing require_relative. (Most often you will find yourself using require.)
To come back to your question: As it says in the tutorial, you have to write require 'HTTParty' instead of require_relative 'HTTParty'.
Does this answer your original question?
Related
This SO post sort of answers the question by claiming that require will only search relative to the path that the script was run in. But this really does not appear to be true. I will elaborate.
I created a quick C extension and compiled it to mytest.so. Then, in the same directory I fired up irb.
irb(main):009:0> require 'mytest.so'
LoadError: cannot load such file -- mytest.so
This is expected because the claim in the other answer is that require is searching relative to where irb was run from. In my case that would be /usr/bin/irb. So I tried the required_relative solution from the other question:
irb(main):006:0> require_relative './mytest.so'
LoadError: cannot infer basepath
No luck. And FYI - mytest.so is tab-completing here so irb is clearly aware it is in the current working directory. Furthermore, I can easily prove this:
irb(main):004:0> system("pwd")
/home/mike/Documents/ruby_test
# => true
irb(main):005:0> File.expand_path("./")
# => "/home/mike/Documents/ruby_test"
Okay final test, I will assume that irb is being executed in /usr/bin despite the evidence pointing against that.
irb(main):011:0> require '../../home/mike/Documents/ruby_test/mytest.so'
LoadError: cannot load such file -- ../../home/mike/Documents/ruby_test/mytest.so
I would greatly appreciate if anyone can shed some light on what is going on with require?
BTW, I am aware I can solve this issue by giving the exact file path. This question is about trying understand what is happening beneath the surface.
require '/home/mike/Documents/ruby_test/mytest.so' # this works
tl;dr: IRB is special and has some odd rules. Ruby in general works just fine with relative paths.
require will search the load path (which you can see by inspecting $: or $LOAD_PATH). This will not include the directory that you launched IRB from:
> $:
=> ["/usr/local/rvm/rubies/jruby-head/lib/ruby/2.2/site_ruby", "/usr/local/rvm/rubies/jruby-head/lib/ruby/stdlib"]
So there's no joy there, unless you explicitly add your directory to the load path. This is what Rubygems and Bundler spends most of their time doing - they manage the load paths for gems so you don't have to worry about it. However, this doesn't help you with single files.
Additionally, require_relative will search from the directory that __FILE__ is in, but in IRB, this is a non-directory (irb) value! This is why you get the "can't infer basepath" issue when trying require_relative from IRB; since the currently executing file, __FILE__, isn't a proper path, require_relative can't figure out where to start from.
When you are not running from IRB, this isn't really an issue; require_relative 'mytest.so' should work just fine when you execute it in a script, since the currently-executing script will populate __FILE__. That is, if you have loader.rb and mytest.so and execute loader via ruby loader.rb, require_relative should work just fine.
If you want to run this in IRB, consider something like:
require "#{__dir__}/mytest.so"
which will expand out to the current working directory, which should by default be the directory you've launched it from. I would recommend that you not do this in a script, though, since it depends on __dir__ not having been changed, and that may be difficult to guarantee.
From the documentation:
Loads the given name, returning true if successful and false if the
feature is already loaded.
If the filename does not resolve to an absolute path, it will be
searched for in the directories listed in $LOAD_PATH ($:).
If the filename has the extension “.rb”, it is loaded as a source
file; if the extension is “.so”, “.o”, or “.dll”, or the default
shared library extension on the current platform, Ruby loads the
shared library as a Ruby extension. Otherwise, Ruby tries adding
“.rb”, “.so”, and so on to the name until found. If the file named
cannot be found, a LoadError will be raised.
For Ruby extensions the filename given may use any shared library
extension. For example, on Linux the socket extension is “socket.so”
and require 'socket.dll' will load the socket extension.
The absolute path of the loaded file is added to $LOADED_FEATURES
($"). A file will not be loaded again if its path already appears in
$". For example, require 'a'; require './a' will not load a.rb again.
The answer to your question is that it simply isn't designed to.
You could use require_relative if you want to require files relative to your files' path.
You could add your projects library folder to the $LOAD_PATH to get the functionality you are asking for, that is, require 'my_library'
In IRB for loading local files, you may want to use load instead, as it gives you the ability to load file/library multiple times, where require will load the file/library only once. The __FILE__ variable works in IRB just like it should. It is the identification of the file (in this case the open process) in which the variable is invoked.
I have git cloned a repo from Github, now I want to experiment with it, as in I want to poke around the code and mess with it. I've created a file test.rb that should load this gem, but I want to load my locally checked out version, what's the right way to do this?
Right now I'm just using a bunch of "require_relative 'the_gem_name/lib/file'", which feels wrong.
When you require 'foo' Ruby checks all the directories in the load path for a file foo.rb and loads the first one it finds. If no file named foo.rb is found, and you’re not using Rubygems, a LoadError is raised.
If you are using Rubygems (which is likely given that it is included in Ruby 1.9+), then instead of immediately raising a LoadError all the installed Gems are searched to see if one contains a file foo.rb. If such a Gem is found, then it is added to the load path and the file is loaded.
You can manipulate the load path yourself if you want to ensure a particular version of a library is used. Normally this isn’t something that’s recommended, but this is the kind of situation that you’d want to do it.
There are two ways of adding directories to the load path. First you can do it in the actual code, using the $LOAD_PATH (or $:) global variable:
$LOAD_PATH.unshift '/path/to/the/gems/lib/'
require 'the_gem'
Note that you normally want to add the lib dir of the gem, not the top level dir of the gem (actually this can vary depending on the actual Gem, and it’s possible to need to add more than one dir, but lib is the norm).
The other way is to use the -I command line switch to the ruby executable:
$ ruby -I/path/to/the/gems/lib/ test.rb
This way might be a bit cleaner, as normally you don’t want to be messing with the load path from inside your code, but if you’re just testing the library it probably doesn’t matter much.
Following apneadiving's suggestion in the comments, I created a Gemfile and added this line
source "http://rubygems.org"
gem 'gem_name', path: '~/path/to/gem/source/folder'
Then bundle install, and bundle exec ruby test.rb and it worked.
I'm new to ruby, but I'm working on my first ruby program. It currently has two files, one is a library of functions (xgync.rb stored in lib) the other is the executable xgync stored in 'bin'. (Project visible here https://bitbucket.org/jeffreycwitt/xgync/src) I've also created a symlink to my /usr/local/bin/xgync so that I can write the command xgync {arguments} from anywhere in the terminal.
The problem seems to be that bin/xgync depends on the library lib/xgync.rb. I've written this dependency in bin/xgync as follows:
$:.unshift(File.dirname(__FILE__) + '/../lib')
require "xgync"
However, i keep getting the following error:
/Users/JCWitt/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- xgync (LoadError)
from /Users/JCWitt/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
from /usr/local/bin/xgync:4:in `<main>'
can you see anything wrong with what I've written? Could the symlink be somehow messing things up?
Thanks for your help :)
When using ruby 1.9.x you don't usually alter the path with the $:.unshift when requiring other files in your project.
Instead the best practice is to use require_relative instead.
require_relative '../lib/xgync.rb'
require_relative requires files relative to the file you are currently editing.
But the error you experience appears, because you require a file, which does not exist:
bin/xgync
lib/xgync.rb
These are the files in your project according to your question, and the code-excerpt is from bin/xgync you extended the path to look for files in lib/ but you try to require 'xgync' which is a file, that is not present in lib/, so if you wanted to use this method (instead of require_relative you would have to use require 'xgync.rb'.
I'm quite new to Ruby language (up to now I developed in Groovy + Grails) but since I was curious about it I wanted to try Sinatra on Ruby 1.9.2-p0.
I have a trivial website that is contained in /mywebpage and has 2 files:
# blog.rb
get '/' do
'Hello World!'
end
get '/impossible' do
haml :index
end
and
#config.ru
path = File.expand_path "../", __FILE__
$LOAD_PATH << (File.expand_path ".") + "/views"
require 'haml'
require 'sinatra'
require "#{path}/blog"
run Sinatra::Application
then in the same folder I have a /views/ folder that contains index.haml.
I try to run the server with rackup -p8080 but when I try to get /impossible I receive the following error:
Errno::ENOENT at /impossible
No such file or directory - /home/jack/mywebpage/<internal:lib/rubygems/views/index.haml
By searching over internet it seems that this maybe caused by "." not being included in $LOAD_PATH so I tried to add it or add directly views ./views so that actually $LOAD_PATH.inspect gives me correct path: ..., "/home/jack/mywebpage/views"]
But still it doesn't seem to work. Being quite new to the framework and the language I was wondering if I'm doing something wrong. any clues?
Running Sinatra with Ruby 1.9.2 the template directory is no longer implicitly 'views', you need to set it yourself.
set :views, File.dirname(__FILE__) + "/views"
Note that currently Ruby also has Kernel#__dir__() method that is equivalent to File.dirname(__FILE__).
This, and other issues with 1.9, will be have been solved in Sinatra 1.1. You could use this fork: http://github.com/rkh/sinatra/tree/1.1
I ran into a similar problem, and solved it like this. I didn't dig into the problem, but this is what I found and it works. It'll supposedly be fixed in the next version of Sinatra (which they should really get out the door, just to fix these few 1.9.2 bugs).
#!/usr/bin/env ruby
require 'rubygems'
require 'sinatra'
enable :run
get '/' do
"Hello, world!"
end
Edit: It seems there are multiple bugs with Sinatra on 1.9.2. This one will fix Sinatra apps not starting on 1.9.2. I don't use a views directory (I like to keep my apps single-file), so I didn't run into your particular problem. This fix most likely won't help you at all. I probably should have read your problem more closely..
gem install sinatra --pre
I ran into that last week and didn't find a suitable fix on the Sinatra site short of tweaking the sinatra code. I'm using rvm for my development and switched to try sinatra on Ruby 1.8.7 and it works fine again, so that's where I left it.
Oh, since you're new to Ruby, you might not know about rvm, so here's the lowdown. RVM is Mac only and highly recommended for managing your Ruby version and gems. It makes it trivial to have multiple Ruby versions and alternate groups of gems for development and testing. Everything is stored in your ~/.rvm directory so it's easy to blow it all away if you need to.
http://rvm.beginrescueend.com/
I just looked at the Sinatra site again about the problem to see if there was anything new, but it appears they consider the following to be an acceptable fix:
http://github.com/sinatra/sinatra/issues/#issue/50
I'm a bit adverse to having to edit the source of Sinatra as recommended by issue #50, but it's not real hard to do. I'd like to see them put out an update so we'd have an official fix but I haven't seen anything yet:
gem env will tell you the "GEM PATHS". Sinatra's gem will be in one of those. The line mentioned in issue #50 goes into base.rb. On my machine it's something like ...gems/ruby-1.9.2-p0/gems/sinatra-1.0/lib/sinatra/base.rb.
Insert:
/<internal:/, # ruby 1.9.2-p0 hacks
at line 1020.
Save the file and you should be good to go.
I haven been all day training to fix this problem but i couldn't.
The question is easy, i don't want to put anymore the require 'rubygems' line everytime i require a gem...
If i put the require 'rubygems' before any other "require" the file runs perfect but if i don't put the require 'rubygems' line the following error occurs:
(...)in `require': no such file to load -- 'gemname' (LoadError)
I suspect that may be there is some path remaining where to check out the gems repository.
I want to ask you if there is a way to do this.
Thanks a lot.
Cheers,
Juan.
You could invoke you ruby script with
ruby -rubygems script.rb
or add rubygems to RUBYOPT
$ export RUBYOPT="rubygems"
put
require 'rubygems'
as first line of your ruby code and be safe.
of course you can invoke with -rubygems switch (as Peter Krenn wrote) instead of it
In Unix you can:
$ RUBYOPT="rubygems"
$ export RUBYOPT
$ ruby juans_masterpiece.rb
and in Windows:
SET RUBYOPT=rubygems
or right-click on My Computer->Properties->Advanced->Environment Variables
and then finally add the RUBYOPT variable there. Next time you open a cmd.exe run set and it will be there.
You don't have to put it every time you require a gem — you just have to have it before the first time you require a gem. When you require Rubygems, it replaces the default require with a special one that does all the Rubygems magic.
But that's only in 1.8. You don't have to require Rubygems at all in Ruby 1.9 — so that's a very easy solution to the problem as long as you aren't dependent on 1.8-specific things.
Right-click the Computer Icon, then select Properties, then Additional system parameters, then Environment variables, there is a GUI for changing opts, click Create, put name and value, OK. This is an approximate translation of how you do this on windows 7, if you can't find the place try to google for "changing environment variables in {your windows version here}"