Use Pry in Gems Without Modifying The Gemfile or Using 'Require'

How to add pry when developing a Ruby gem

You can use the add_development_dependency in the gemspec file. You'll still have to require it in your lib/something.rb file within a begin .. rescue LoadError block. (Edit 2, see below)

In your case, it will be something like the following:

spec.add_development_dependency 'pry', '~> 0.9.12.2'

The purpose of add_development_dependency is to separate the gems into dependencies that get installed when you execute gem install mygem vs development-only dependencies that are installed only when you execute gem install mygem --development.

Edit: @Pierre-Louis Gottfrois' solution

Modify the Gemfile directly and add a test group. This question describes the process. This does not appear to be a preferred solution according to Yehuda Katz.

Edit 2: begin require ... rescue LoadError is apparently a common practice for Ruby scripts, according to this Making Ruby Gems article.

Require a gem outside the Gemfile

You should try if debundle.rb works for your purpose!

Unable to require pry via Bundler.setup for a Ruby application that uses a Gemfile

Bundler.setup will simply add the gems to the load path, whereas Bundler.require will do both the adding to the load path and the require.

I recommend using Bundler.setup so that your code boots faster. Then when you need to require pry, do this:

require 'pry'

Ruby (bundler) How to automatically require Pry

The trick is to use Bundler.require(:default) after require 'bundler/setup' - since the latter just sets up the load path. See http://bundler.io/v1.16/guides/bundler_setup.html.

Requiring pry gem into ruby script causes error

What eventually worked for me is I just uninstalled all of the pry versions I had installed via gem uninstall. Then: in my gemfile I specified a previous version of 0.11.3:

# Gemfile
source 'https://rubygems.org'
gem 'pry', '0.11.3'

I did bundle install and then ran my ruby script, and that worked for me.

How to use gems not in a Gemfile when working with bundler?

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.

how to not require certain gems/lines of code in production that I need in development

If you have just yes/no scenario for dev, dotenv family is an overkill. I would go with surrounding dev requirements with:

if ENV['DEV']
  require 'pry'
  ...
end

and then run development scenarios as:

DEV=true bundle exec ...

Since DEV env variable is not defined on your prod server, nothing will be included there.

Init for log_buddy might look like:

LogBuddy.init(ENV['DEV'] ? {:logger => Logger.new('my_log.log')} : nil)

---

Related Topics