How do I make bundle exec irb aware of system-gems?
To load a project, we're using bundle exec irb. To make my life in irb a bit easier I had planned on using irb_rocket (with wirble and ruby-terminfo).
When loading just plain irb, it works as expected. However when using bundle exec irb, it can (obviously) not find my systems-gems.
I do not have the option to alter the gemfile, unless I can somehow make it only apply to my machine.
If it's worth anything; os x, source-control in git, ruby versioning in rbenv.
When requiring with the full paths of the gems, irb_rocket requires terminfo again which then throws a LoadError on require 'terminfo.so'. Changing the gem locally is not really what I want to do, but I guess it would work.
You could use Pry instead of IRB together with pry-debundle. If this is a Rails project you can just add pry-rails to your Gemfile so that it will be used as Rails console.
Related
There is fundamental problem with ruby gem sets where commands like rake xxxx might create error because command might use global version of rake while your gemfile requires very specific version.
I know 2 ways to mitigate this.
Use bundle exec in front of rake and rails commands. For example bundle exec rake db:migrate Adding this in front makes sure command is executed in relation of the current bundle meaning the bundle that got created when you run bundle install.
Using RVM. There is less known way of creating local gemset with RVM. First you create directory for your new app in this case mkdir myapp, cd myapp and then run rvm use ruby-2.3.0#myapp --ruby-version --create for creating local gem set with nothing in it. Now you can run gem install rails and rails new . to create rails myapp with it's dedicated gem environment in the folder you are in.
As nice extra RVM will swap to right gemset every time you cd to myapp directory automatically.
As for as I understand both approaches work, but are there any known issues why you would not use one of approaches above?
If you're an RVM fan like myself, I would go with creating my own gemset for every rails project I start. This will make it easier for me to just use rake and rails commands without specifying bundle exec every time.
Put in mind when sharing your code that some developers might be using rbenv or maybe not using a ruby version manager at all. One way you can make sure that everyone is happy and working with the same version of ruby, is to provide two additional files in your project directory (.ruby-version and .ruby-gemset) and track them in your project.
The .ruby-version file would contain the version of ruby you're using for example 2.4.1. Note that this is compatible with both RVM and rbenv and will switch to the correct ruby version.
The .ruby-gemset file is identified only by RVM; thus, switching to the correct gemset you have setup for the project.
This will make your project compatible with developers using rbenv while still making those of us using RVM happy :)
Putting all these considerations in mind, now you should care less wither people use bundle exec or not!
One reason not to use (2): if anyone else wants to work with your code, they will have to duplicate all that for themselves, rather than just remembering to type bundle exec. They have likely never seen (2) before, so this is perhaps non-trivial.
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
When using bundler with a project in general and Rails specifically, you have access only to gems defined in your Gemfile. While this makes sense, it can be limiting. Mostly I find it limiting when I want to use a certain RSpec formatter that the rest of the team doesn't use. Unless it's in the Gemfile, it isn't accessible.
Any way around it or I have to add it to Gemfile?
Update: my problem wasn't Bundler but Spork. When running RSpec without Spork I had no problem of using whatever formatter I wanted.
Update #2: it looks like that using Bundler is still the cause of the problem. The difference between using Spork and not using Spork, is that when running RSpec without Spork, it loads the formatter before loading your project and getting into the Bundler "sandbox".
With Bundler:
$ bundle exec irb
>> require 'fivemat'
LoadError: cannot load such file -- fivemat
from (irb):1:in `require'
from (irb):1
from /Users/arikfr/.rvm/rubies/ruby-1.9.3-p194/bin/irb:16:in `<main>'
Without Bundler:
$ irb
>> require 'fivemat'
=> true
In ChiliProject we allow users to create a Gemfile.local which is included into the main Gemfile on load. This allows users to specify additional gems without having to change our Gemfile to ease updates.
For that, we have included the following code at the bottom of our Gemfile.
gemfile_local = File.expand_path('Gemfile.local', __dir__)
if File.readable?(gemfile_local)
puts "Loading #{gemfile_local}..." if $DEBUG
instance_eval(File.read(gemfile_local))
end
The Gemfile.local itself is excluded from the repository via .gitignore.
I assume that none of these answers have been chosen as correct because they don't do a great job of solving the problem: having additional gems that you can use that by default don't require any changes to files already in the repository to achieve. That is, you don't have to modify any files, and you don't have to live with remembering not to check in your local changes. Here's how I do it.
The idea is basically inverting the dependencies of Holger's answer, such that there's no need to modify the shared Gemfile. Bundler allows one to specify which file is to be used as the gemfile, but strangely the documented methods do not apparently work with its configuration file and will not be fixed. There is a somewhat obscured feature of Bundler that any of the configuration options can be set in an environment variable or passed on the command line. Running all of your commands as bundle [command] --gemfile [yourgemfile] or BUNDLE_GEMFILE="[yourgemfile]" bundle [command] will cause Bundler to read whatever gemfile you want it to. I highly recommend using the environment variable approach, and either creating an alias or exporting the variable for your current session, particularly as I was unable to use the command line switch with the "exec" command.
Therefore, I run rspec like this: BUNDLE_GEMFILE="[mygemfile]" bundle exec rspec [filename], and I have the first part of this aliased as bem in my bashrc. Works like a charm.
Then, you should setup your source control to ignore your Gemfile, either in the project's .gitignore or, to keep the project entirely hygienic without changing even its .gitignore, to your personal global ignore file (which is by default in ~/.config/git/ignore and has the same format as a project's gitignore file).
One other thing to note is that Bundler will create a lockfile based on the Gemfile's name. This is super handy, as it keeps you from overwriting your project's Gemfile.lock if it's checked in, but you need to ignore this new lock file as well. If your gemfile is Foo.bar, look for Foo.bar.lock.
Finally, you can do something similar to Holger's suggestion in your custom Gemfile:
source "http://rubygems.org"
gem "fivemat"
instance_eval(File.read(File.dirname(__FILE__) + "/Gemfile"))
and you're good to go, as long as you remember to specify your Gemfile.
You can use something like this in your Gemfile:
gem 'foo' if ENV['ENABLE_FOO_GEM']
Then just set ENABLE_FOO_GEM in your environment.
export ENABLE_FOO_GEM=1
The gem will be disabled by default, but easily turned on (permanently) by anyone who wants to use it.
Add to .gitignore
Gemfile.local
Gemfile.local.lock
Add to the project a Gemfile.local.sample file with the following content:
# Include gems that are note meant to be part of the project but for development purposes
# That's why Gemfile.local and Gemfile.local.lock must be git-ignored
# To use these gems:
# 1. Create a "Gemfile.local" file (at same level of "Gemfile")
# 2. Prepend "BUNDLE_GEMFILE=Gemfile.local" before "bundle install" or "bundle exec rails c" and so forth.
eval_gemfile "./Gemfile"
group :development, :test do
# Suggested gems
gem "awesome_print", require:"ap"
gem "hirb"
gem "pry"
gem "pry-byebug"
gem "pry-rails"
gem "meta_request"
# My gems
gem "fivemat"
end
I believe the gem Devpack provides the functionality you are looking for.
The gem allows you to add a single gem to your Gemfile which will permit any developer to configure their own preferred set of development gems either for an individual project or globally by creating a .devpack file containing a list of gems.
(I am the author of this gem; I came across this post while developing it so thought it may be worth adding).
In case you still decide to do this (horrible idea):
You can add ruby code to your Gemfile to load a ~/.gemfile (or such) if it exists.
Something like:
eval(IO.read('~/.gemfile'), binding) if FileTest.exists?("~/.gemfile")
I'm new to Ruby. I have a .bundle file. I put it in the source folder and did
require('my.bundle')
But when I call the methods in the bundle, the definition is not found. Do I have to install them or include them in some other way to access them?
I am on Ruby version 1.8.7 (latest version on Mac).
I highly recommend using RVM to manage your Ruby installation, including your gems, so if you don't already have that, get it and follow the instructions for installing it. Make sure you do the part about modifying your bash startup script or you'll see weird behavior, like the wrong Ruby being called. Also, use the steps in "RVM and RubyGems" to install your gems or you can run into weird behavior with gems being installed under the wrong or an unexpected Ruby.
Second, use the gem command to install gems:
gem install gem_to_install
replacing "gem_to_install" with the name of the gem you want, and it will be installed into the appropriate gem folder for your Ruby.
If you are on Ruby 1.92, and trying to require a gem to use as a module in your code, use:
require 'gemname'
if it is installed via the gem command. And, if it is a module you wrote or have in your program's directory or below it, use:
require_relative 'path/to/gem/gemname'
If you are on a Ruby < 1.9 you'll also need to add require 'rubygems' above your other require lines, then use require './path/to/gem/gemname'.
Thanks, but my .bundle is not in gems. How do I install/require a .bundle file I already have?
If you wrote it look into rubygems/gemcutter or bundler for info on bundling and managing gems.
You can install a gem without using the app by going into the directory containing the gem and running setup.rb. See http://i.loveruby.net/en/projects/setup/doc/usage.html for a decent writeup or the official docs at: http://docs.rubygems.org/read/chapter/3
I have JRuby and Ruby (MRI) installed. It seems that I need to install gems twice - once for each of these platforms. Is this necessary or am I doing it wrong? After I installed the rails gem for MRI, should I have pointed JRuby to it, or was it necessary for me to also call: "jruby -S gem install rails"
You need to install gems for each different install of ruby that you have.
If you set GEM_HOME you can share your gem installations.
Some gems target specific platforms, e.g. Mongrel (there's a MRI one and a JRuby one). Also, JRuby cannot use gems that have native extensions (i.e. C code) unless they use the FFI (which most do not - yet).
Personally I have separate gem repos for MRI and JRuby. The little bit of extra hassle is worth the peace of mind when trying to track down a problem.
It's pretty easy to see what each repo has installed:
jruby -S gem list --local
vs.
gem list --local
You could even write a ruby script to sync one gem list to the other, but you'd have to be careful about platform specific gems....
I hit this problem when creating my gem, jimmy_jukebox, but made my gem work with both.
First, JRuby doesn't handle fork...exec (and even replies incorrectly to Process.respond_to?(:fork)), so I had to rescue NotImplementedError and use Spoon.spawnp instead.
I then created (in my gem's /bin directory) paired executables -- play_jukebox and jplay_jukebox; and load_jukebox and jload_jukebox -- each with the correct shebang line (/usr/bin/env ruby or /usr/bin/env jruby).
I'd love to know a better way. But I'd rather handle everything within a single gem than maintain and distribute multiple gems.