I've installed Ruby 2.1.1 via source.
I've seen suggestions to type ruby -v, which I assume would show that the binary isn't corrupted, but are there more comprehensive ways to ensure that it's working as expect? Unit-tests, benchmarks, etc to validate it's functional?
Run make test after compiling in the directory you’ve compiled in. (This might actually happen by default, I can’t remember. There’s also make test-all, among others.)
ruby -v will show you the current version of ruby installed on your machine.
If you want, just create a hello.rb with puts "hello" and run it using ruby hello.rb to check if it is interpreting the ruby code correctly. So you know that its functional.
Related
In our Rails application we do require 'RRD' at some point, but that results in a cannot load such file -- RRD. So obviously I used homebrew to install rrdtool, but the error remains.
The docs at https://oss.oetiker.ch/rrdtool/prog/rrdruby.en.html provide two options:
Either:
$: << '/path/to/rrdtool/lib/ruby/1.8/i386-linux'
require "RRD"
In my /opt/homebrew/Cellar/rrdtool/1.8.0/lib directory there's no mention of ruby, which is because of the --disable-ruby-site-install flag in the formula, because when I skip that flag I do actually get something: /opt/homebrew/Cellar/rrdtool/1.8.0/lib/ruby/2.6.0/universal-darwin21. However replacing the path/to string with this path still gives the error.
Or:
If you use the --ruby-site-install configure option you can drop the $: line since the RRDtool module will be found automatically.
Which is a little confusing (and probably outdated) because here it seems that ruby site install is disabled by default and you have to enable it proactively, whereas in the formula it's actually actively disabled.
Either way: both options didn't do the trick for me and if there's a solution without homebrew that's also fine.
For good measure: I'm on macOS Monterey
TL;DR
For the most part, I'd say that using a non-standard gem without a Ruby version manager is your main issue. There are instructions on the rrdruby site for installing it, but they don't follow typical conventions, so your mileage will vary.
Some Practical Suggestions
The require keyword is for gems, not binaries. You need to have an rrdtool-related gem installed, available to your Ruby instance (usually through a Bundler Gemfile or gemspec, or via the RUBYOPTS environment variable or your in-process Ruby $LOAD_PATH), and then require the correct name of the gem in your code. For example, using the older rrd-ffi gem:
# use sudo if you're installing it to the system,
# but I would strongly recommend a ruby version
# manager instead
gem install rrd-ffi
# in your Ruby class/module file
require "rrd"
For the gem you seem to be using, you have to compile the gem first to make it usable, and then ensure it's available in your Ruby $LOAD_PATH (or other gem lookup mechanism) before trying to require it. The error message you're seeing is basically telling you that a gem with that name is not available as called within any of the standard lookup locations.
Again, I'd suggest reading the build documentation for your gem, and then seeing if you can install it as part of a Bundler bundle, RVM gemset, or other non-system approach if you can. Otherwise, follow the directions for the rrdruby tool, which is not available as a standard Rubygems.org gem, in order to make it available before trying to require it.
Beware of Outdated or Non-Standard Gems
Most of the RRD gems I found were quite old; most were 7-8 years old or older, so their compatibility with current Rubies is potentially suspect. The gem-builder you're using is newer, but doesn't seem to be designed as a standard gem, so you need to build it and install it in a suitable lookup path before it can be required. Installing gems as system gems is almost always a bad idea, so I'd strongly recommend building it from source and using a ruby version manager rather than following the rrdtool author's atypical suggestions. YMMV.
I have no knowledge in Ruby, but I need to run some tests in it. The code is in Ruby and Cucumber. I use intellij on Mac. When I first open intellij cucumber step definition where not recognised from feature file. In terminal I got:
Required ruby-2.1.2 is not installed.
To install do: 'rvm install "ruby-2.1.2"'
but
$ which ruby
/Users/myuser/.rvm/rubies/ruby-2.4.1/bin/ruby
so I run the install command as suggested and now I get
$ which ruby
/Users/myuser/.rvm/rubies/ruby-2.1.2/bin/ruby
Now my feature files connected to step definition as well. I will appreciate if anyone could explain me what happened. What prompted me to downgrade the version of Ruby and how it fixed cucumber.
Make sure you have ruby 2.1.2 set in File -> Settings -> Languages & Frameworks -> Ruby SDK and Gems
What I suspect is happening is you have run rvm use 2.1.2 in the terminal but when your IDE runs something it is using the ruby version set in the settings.
You probably have a .ruby_version file in the project root directory. This will enforce a specific version of Ruby. So the person who put it there is who to ask why the version was restricted like that. There may have been a good reason, such as that's what is being used by all your users.
It has nothing to do with Cucumber. rvm has some kind of operating system hook, I think, that runs whenever you cd into a directory. It looks for its special control fiels such as .ruby_version and .rvmrc file. This page describes this in more detail: https://rvm.io/workflow/projects.
I've installed RSpec on a win7 lappy and am following along the http://rspec.info/ homepage tutorial to make sure everything works. If I am reading their demo correctly bin/rspec --format doc should run the specification test file.
Instead, I get a system prompt for a text editor... ? I am confused.
Any explanation of what is going on or guidance about how to get my RSPEC configuration working in accordance to the makers homepage would be great.
FWIW Ruby 2.2.5p319, Bundler version 1.13.1 and gem -v tells me 2.6.7 (originally I had 2.4 but that is broken on windows, so I upgraded according to http://guides.rubygems.org/ssl-certificate-update/) Also, I have basic RSpec functionality and have completed the tutorial here: https://www.tutorialspoint.com/rspec/rspec_writing_specs.htm
Ah, I figured out what I need to do... I just need to explicitly call ruby:
ruby bin/rspec --format doc
...and the test gets run - YaY!
Per #JörgWMittag, I confirmed my Environment Variable Path to make sure ruby.exe was in there (C:\Ruby22\bin;).
Then looking at my Program Defaults, I thought that maybe I could tell win7 to associate any file named "rspec" with ruby.exe per https://support.microsoft.com/en-us/help/18539/windows-7-change-default-programs ...but I couldn't actually add file type "extensions" or "protocols" - I could only change the association of existing ones, but .rb and .rbw were in there... Maybe there is a way to do this manually, but I am not a windows expert.
Thinking on all this it occurred to me that I just needed to explicitly tell ruby to ingest the command... Heh.
I apologize if this is off-topic.
I would like to run gem commands, such as gem install, with a different ruby version than what is listed in gem env. The Ruby version I want to use is a pre-compiled version which I have the path for, so installing and using another version from RVM or similar would not solve my problem.
I do not want to change the RUBY EXECUTABLE permanently, just for one command at a time. I have tried to set GEM_HOME, GEM_PATH, PATH, RUBY and more. I have tried firing up gem with specific/version/of/ruby/path/ruby path/to/gem env, but I still get the default Ruby in my RUBY EXECUTABLE variable.
I even tried settingRUBY_EXECUTABLE=/path/to/correct/ruby, which also did not work.
What really surprised me was that when I edited the shebang in the path/to/gem file itself so it pointed to the correct Ruby, it still did not work! What is up with that?!
How can I change this variable so I can use gem goodness with my custom compiled Ruby?
This one is really beating me. I have now updated my rbconfig.rb to point to the desired Ruby path. I have looked at the rubygems source and replaced every single instance of the default ruby , in all the files I could find, with the path to the one I want. Even this did not set the environment correctly. Is this somehow hard-coded into the compiled ruby? If that is the case, why the star*4 is this done?
Try using rbenv (https://github.com/sstephenson/rbenv) or RVM to manage Ruby versions (https://rvm.io/). When you switch Ruby versions with rbenv, gem env will use use the new Ruby version. The following command can be used to change the Ruby version for a single shell:
$ rbenv shell 2.1.2
After hours and hours of research, stepping through the Ruby source with Pry, reading source code and more I figured out that this is not possible to do because it is hard-coded into ruby at compile time (wtf?). Anyway, the way to solve this is to simply recompile Ruby. Yeah.
There is also apparently a compile flag which you can set which removes this hard-coded environment: --enable-load-relative
After struggling with this for way to long I finally got this project working, where I have made an easy to use portable version of Ruby. Simply put, a folder with Ruby on it which you can move about, put on a USB stick or whatever, and it still works :)
I want my app to not be able to use any installed gems. Is there a ruby 1.9 startup parameter or way of doing this programmatically?
ruby --disable-gems
is the MRI (1.9) commandline parameter. "It prevents the addition of gem installation directories to the default load path". (The Ruby Programming Language, p. 391)
Edit 25-10-2012: Ruby core had the same idea as #rogerdpack in the comments and added the more verbose ruby --help parameter. Ruby revision!
Looking at the rubygems configuration file, I would attempt to hack out gempath or gemhome to see if you can override (instead of just append to) defaults.
If, for example, setting gempath to be empty, or to point to /dev/null, prevents using system gems, then that would be the way to go.
The main advantage to this, as I see it, is that your anti-rubygems config file can be passed to ruby 1.9 as a startup parameter (so not coded in), well documented, and checked into your repository.
All of this is, of course, disregarding that rubygems is part of ruby 1.9's standard library - so ruby may choke and die if it can't have access to its gems, depending on how much of ruby's base install requires gem functionality. YMMV.