For example, I'm developing a gem, and while I'm developing, I use pry instead of IRB, and debugger for debugging. However, I don't want possible contributors to have to install them (because they may not need them). My first idea was to put them in a Bundler group:
source :rubygems
gemspec
group :extras do
gem "pry"
gem "debugger"
end
And then people could use:
$ bundle install --without extras
But I want it to be a default that they're not installed. What would be perfect is that they're not in my Gemfile, but that I can still require them (if they exist on the computer). This solution would be ok because I don't care at which version they're locked. Can it be done?
You can add arbitrary load paths and then require gems from them. Check out the global variable $:
puts $:.inspect
# ["/var/myproject/releases/20200918191637/lib", "/var/myproject/releases/20200918191637/vendor", "/var/myproject/releases/20200918191637/app/assets", "/var/myproject/releases/20200918191637/app/controllers", "/var/myproject/releases/20200918191637/app/helpers", "/var/myproject/releases/20200918191637/app/mailers", "/var/myproject/releases/20200918191637/app/models", "/home/deploy/.rvm/gems/ruby-2.3.0/gems/bundler-2.0.2/lib", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/gems/2.3.0/gems/json-1.8.3/lib", "/home/deploy/.rvm/gems/ruby-2.3.0/gems/bundler-2.0.2/lib/gems/bundler-2.0.2/lib", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0/x86_64-linux", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0/x86_64-linux", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/x86_64-linux"]
Now let's append to $: and require a gem
require 'method_source'
# LoadError: cannot load such file -- method_source
$: << '/home/deploy/.rvm/gems/ruby-2.2.4#myset/gems/method_source-1.0.0/lib'
# ["/var/myproject/releases/20200918191637/lib", "/var/myproject/releases/20200918191637/vendor", "/var/myproject/releases/20200918191637/app/assets", "/var/myproject/releases/20200918191637/app/controllers", "/var/myproject/releases/20200918191637/app/helpers", "/var/myproject/releases/20200918191637/app/mailers", "/var/myproject/releases/20200918191637/app/models", "/home/deploy/.rvm/gems/ruby-2.3.0/gems/bundler-2.0.2/lib", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/gems/2.3.0/gems/json-1.8.3/lib", "/home/deploy/.rvm/gems/ruby-2.3.0/gems/bundler-2.0.2/lib/gems/bundler-2.0.2/lib", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby/2.3.0/x86_64-linux", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/site_ruby", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby/2.3.0/x86_64-linux", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/vendor_ruby", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0", "/usr/local/rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/x86_64-linux", "/home/deploy/.rvm/gems/ruby-2.2.4#myset/gems/method_source-1.0.0/lib"]
require 'method_source'
# true
That can be tedious if you have a lot of dependencies, though, so you might try this:
Dir['/home/deploy/.rvm/gems/ruby-2.2.4#myset/gems/*'].each do |gem_path|
$: << File.join(gem_path, 'lib')
end
bundle install is "opt-out"—unless you specify --without some_group, it installs everything.
If you absolutely don't want to have a given gem in your Gemfile, you could just gem install that rogue gem outside of your bundle. Then it'll be visible to you under irb and straight ruby (but obviously you'll get errors if you try to require it within code running under bundle exec).
You could add a conditional based on environment variables into the Gemfile. Example:
source :rubygems
gemspec
if ENV['WITH_EXTRAS'] == '1'
gem "pry"
gem "debugger"
end
The gems are then only installed/loaded, if you set the environment variable to '1' e.g. WITH_EXTRAS=1 bundle install.
Nowadays you can use the "optional" argument, and it will do exactly what you ask: it will not install the extras unless people bundle --with extras
group :extras, optional:true do
...
end
https://bundler.io/v2.3/guides/groups.html#optional-groups
Related
I have a test suite that is designed to run locally and on a cloud vendor. When the test is run locally I would like to use a RubyGem that makes use of native extensions that run much faster. On the cloud vendor however, I cannot include this particular flavour of gem and must use a different one.
Is there a way that I can, either by command line argument, or as a function in Ruby add or remove gem requirements?
You can wrap your require statements inside an if/else.
if `hostname`.strip == 'local'
require 'ruby_ext_gem'
else
require 'ruby_native_gem'
end
Or run the Ruby interpreter with the -r option.
ruby -rruby_ext_gem -rruby_ext_gem2 script.rb
Maybe bundler would be what you are searching for?
#Gemfile
source 'https://rubygems.org'
group 'local' do
gem 'ruby_ext_gem'
gem 'ruby-ldap', require: 'ldap'
end
group 'cloud' do
gem 'ruby_native_gem'
gem 'ruby-net-ldap', require: 'net/ldap'
end
# local
bundle install --without cloud
# cloud
bundle install --without local
#script.rb
#!/usr/bin/env ruby
require 'bundler/setup'
Bundler.require(`hostname`.strip)
I am using RubyMine (v6.0.2), but my teammates are not, so they need the "debugger" gem in the gemfile. I can conditionally un-require the Gemfile when running RubyMine (so the Gemfile can be shared and identical), but since the 'debugger' gem is not included, the Gemfile.lock file changes depending on whether the project was last run with RubyMine or not. This creates a lot of noise in redundant Gemfile.lock changes.
I've tried using 'debugger-xml' gem; that doesn't solve the issue.
So -- how can I run RubyMine 6.0.2, with the 'debugger' gem in the Gemfile, without having Gemfile.lock change?
I've been working on this issue from the other side of the table. I use the debugger gem, but have team mates that use RubyMine.
We discussed several potential solutions but they all involved conditional checks in the Gemfile that would result in a modified Gemfile.lock.
I googled around for a better solution and found this SO post: How to use gems not in a Gemfile when working with bundler?
Combining a few of the answers in there, I came up with this solution:
Remove the debugger gem from the Gemfile.
Create a Gemfile.local with the contents below.
Add Gemfile.local to the .gitignore file if using git.
Create a function and shell alias.
Start rails with $ be rails s
How it all works!
Bundler will use the file named Gemfile by default, but this behavior can be overridden by specifying a BUNDLE_GEMFILE environment variable. Bundler will use/create the lock file with the same name as the BUNDLE_GEMFILE.
The shell function __bundle_exec_custom will check to see if there is a Gemfile.local file in the CWD. If there is, then the BUNDLE_GEMFILE variable is set and used. Otherwise, the default Gemfile is used.
This will allow a developer to use any gems that they want for local development without having to impact the application as a whole.
Gemfile.local:
source "https://rubygems.org"
gemfile = File.join(File.dirname(__FILE__), 'Gemfile')
if File.readable?(gemfile)
puts "Loading #{gemfile}..." if $DEBUG
instance_eval(File.read(gemfile))
end
gem 'debugger'
Function and shell alias:
__bundle_exec_custom () {
if [ -f Gemfile.local ]
then
BUNDLE_GEMFILE="Gemfile.local" bundle exec $#
else
bundle exec $#
fi
}
# Rails aliases
alias be='__bundle_exec_custom'
I think I found it. Apparently, RubyMine does not deal well with the debugger gem being required into the Rails app, but has no issue with the gem just being installed.
The solution then is to include the gem in the Gemfile (and Gemfile.lock) but only require it outside RubyMine.
gem 'debugger', {group: [:test, :development]}.
merge(ENV['RM_INFO'] ? {require: false} : {})
The above code is from this comment on the JetBrains bug tracker, through this comment on a similar question.
It checks for the presence of the RM_INFO environment variable, which is set by RubyMine. The important thing is that it only affects whether the gem is required and thus should not change Gemfile.lock between installs.
I may have an even better solution that seems to be working for me in my Rails 4 app...
In your Gemfile, move all your debugging-related gems to their own group, as such:
group :pry do
gem 'pry', '>= 0.10.0'
gem 'pry-debugger', '>= 0.2.3'
gem 'pry-highlight', '>= 0.0.1'
end
In config/application.rb you will a find something like the following:
# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)
Add the following just below that:
Bundler.require(:pry) unless ENV['RM_INFO'] || Rails.env.production?
You may wish to modify the unless condition to suit your needs, but the important part is that RubyMine will set RM_INFO, which you can use to detect and therefore exclude gems from being required.
This will eliminate the ping-pong effect of bundling in RubyMine vs. command line, so this should work well in a mixed-IDE team.
One last note, if you're deploying to Heroku, you might want to exclude the :pry group from being installed on deploy:
$ heroku config:set BUNDLE_WITHOUT="development:test:pry"
awesome_print looks like a pretty nice gem, so I wanted to try it out.
I went to one of my projects and did:
gem install awesome_print
and it says one gem installed, documentation installed, etc.
Then, while I am in that project, I went to my Rails console to try it out, but when I did a require "awesome_print" as their help file says, I get a "cannot load such file".
Has anyone got this to work?
gem install will put the gem code on your computer, but unless the gem's source code files are on your load path, require won't be able to find them. bundle exec looks at the nearest Gemfile.lock and adds the source code for all the gems listed there to your load path. Rails initialization includes getting Bundler to do this for you.
One solution is to add awesome_print to your Gemfile. However, this will cause your application to have awesome_print as a dependency. Alternatively you can manually add the awesome_print library to your load path after starting up the Rails console and then requiring it:
$ rails c
> $LOAD_PATH << path/to/awesome_print-x.x.x/lib
> require 'awesome_print'
> ap {foo: {bar: {baz: :qux}}}
If you're using RVM, the path is likely to be something like:
~/.rvm/rubies/ruby-x.x.x-pxxx#your_gemset_name/gems/awesome_print-x.x.x/lib
Add it to your Gemfile like this:
gem 'awesome_print', :require => 'ap'
I add it to the development group, since that's the only time I need it. The gem doesn't have any other gem dependencies, so I routinely add it to my Gemfile.
Also, add these two lines to your ~/.irbrc file to set ap to be your default pager:
require "awesome_print"
AwesomePrint.irb!
Note that if you use this, however, any projects where awesome_print is not installed in its Gemfile will raise this error when you run rails c:
cannot load such file -- awesome_print
Depending on whatever else you may have in your ~/.irbrc file, this can cause other side effects, such as messing up your prompt. To avoid these, simply add the two lines to the very end of that file.
install it :
$ gem install awesome_print
include it in you GemFile, if you want :
gem 'awesome_print', :require => 'ap'
add this line to the file ~/.irbrc :
require 'awesome_print'
AwesomePrint.irb!
restart your shell!
just a note: I did this and it didnt work right away, probably need to restart the computer... or I just needed to close all shell tabs and open the terminal again!
Install the gem on your machine
gem install awesome_print
Get the path to which it has installed
gem which awesome_print
Add the following configuration to your ~/.irbrc and ~/.pryrc. This will load Awesome Print whenever you fire an IRB or a pry session.
*Remember $LOAD_PATH will hold whatever you got from typing gem which awesome_print
# ~/.irbc and ~/.pryrc
$LOAD_PATH << "~/.asdf/installs/ruby/2.6.3/lib/ruby/gems/2.6.0/gems/awesome_print-1.8.0/lib/"
require "awesome_print"
AwesomePrint.irb!
If you are looking to install it without having it in your Gemfile, this is how to do it:
$ gem install awesome_print
I was running into an issue where it was installing successfully but it not in the right directory.
In that case just put this in your .bashrc, this will set the load path:
export PATH="/home/user/.gem/ruby/2.3.0/bin:$PATH"
PATH="`ruby -e 'puts Gem.user_dir'`/bin:$PATH"
replace 2.3.0 with the version of ruby you are working with.
replace user with your username or if you are using vagrant then replace with vagrant
reload your .bashrc or exit the Terminal to reload changes, then install the gem again.
In my case, I struggled with PATHs and such, while missing something obvious!
# which ruby
/usr/bin/ruby
# ruby -v
ruby 2.3.7p456 (2018-03-28 revision 63024) [universal.x86_64-darwin17]
# locate bin/ruby
/usr/bin/ruby
/usr/local/Cellar/ruby/2.7.2/bin/ruby
/usr/local/opt/ruby/bin/ruby
# /usr/local/opt/ruby/bin/ruby -v
ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin17]
#
Aha! Version crud. I was running an old ruby. Thanks, Apple!
# sudo mv /usr/bin/ruby /usr/bin/ruby_2.3.7
# sudo ln /usr/local/opt/ruby/bin/ruby /usr/bin/ruby
Solved the problem!
There is probably something I could have told brew to do to fix things, but I was impatient. :-)
I'm developing a gem with Jeweler in a custom directory.
I want to be able to require the gem within any app (and also the executables files from $PATH), and without needing to build and install the gem each time I modify it.
I thought about 2 ways:
I make a symlink to $GEM_HOME/gems and $GEM_HOME/bin
I add the bin directory to $PATH and the lib directory to rubygems to be loaded.
But I bet there is a proper way to do this.
You can specify a local path in the gem command:
gem 'your-gem', '1.2.3', :path => 'path/to/your-gem'
Update: As #Nick points out in the comments,
This is specific to using bundler. In general, it's just require '/path/to/your-gem.
I'd like to add, however, that if you're using a custom-developed gem, bundle will probably make your life easier if you're not already using it. This is because with bundler, when you're done developing the gem (or at a stable/release point) you can load a gem directly from a github repository like this:
gem 'your-gem', :git => 'git#github.com:you/your-gem.git'
No need to mess around with your Gemfile
require 'bundler/setup' will put the right gem into your $LOAD_PATH and allow you to require it on the next line.
#!/usr/bin/env ruby
require 'bundler/setup'
require '<gem-name>'
I'd love to have a Gemfile in Bundler that just sets my own personal Gemfiles to always be bult into bundles...
aka ruby-debug, interactive-editor, and so forth.
Any idea how to do this?
We use this technique.
Puth this in your Gemfile:
eval File.read(File.expand_path("Gemfile.personal")) if File.exists?(File.expand_path("Gemfile.personal"))
And then add your personal gems to Gemfile.personal. Of course exclude Gemfile.personal from your version control.
One way to do this is to create different evnironments
group :scott do
end
Then
bundle --with-env=scott
I'm not 100% sure what it is you are trying to achieve, but;
If you just want to specify a number of development-only gems, you can specify a development group that can be excluded from deployments:
group :development do
gem "ruby-debug"
gem "interactive-editor"
end
Then on production or test you would do:
bundle install --without development
The cleanest solution I found so far is to use a separate Gemfile.personal and use a custom Gemfile path. I like this solution because you can use it in any project without modifying project code at all.
1. Add Gemfile.personal in to project root dir
# /path/to/your_ruby_project/Gemfile.personal
eval File.read('Gemfile') # use all gems from Gemfile
gem 'personal-gem1'
gem 'personal-gem2'
2. Install gems using Gemfile.personal file
BUNDLE_GEMFILE="Gemfile.personal" bundle install
# or
bundle install --gemfile=Gemfile.personal
Just remember to specify BUNDLE_GEMFILE every time you execute commands with bundler.
I personally put BUNDLE_GEMFILE=Gemfile.personal env variable in .env file using dotenv which ensures that Gemfile.personal is always used when I execute any command with bundler so I do not need to put it manually every time.
3. Put Gemfile.personal and Gemfile.personal.lock to .gitignore
For linux users:
touch ~/.gitignore
echo "Gemfile.personal\nGemfile.personal.lock" >> ~/.gitignore
This will affect all projects, so you do not need to update each project .gitignore separately.
My proposition does not depend on Bundler. As such does not clutter Gemfile* with your private gems for the price being a bit less convenient than answer by #ScottSchulthess.
How Bundler works
There is an array stored in $LOAD_PATH global variable which is a "load path for scripts and binary modules by load or require" (see Ruby docs) and Bundler modifies this array.
If you're developing a gem, $LOAD_PATH it will contain paths to all gems in the system. You can simply write e.g. require "pry" somewhere and pry gem will be loaded properly even if it's not mentioned in gemspec nor Gemfile. You don't have to add it to dependencies. (Of course it has to be already installed with gem install pry.)
A very different strategy Bundler takes when you're developing an application. In such case most of $LOAD_PATH will be removed on require bundler/setup (Rails calls it in config/boot.rb). Only essential paths and those pointing to gems specified in Gemfile.lock will remain there. So if you want to use pry without adding it to Gemfile, you got to append it to $LOAD_PATH before requiring it.
Solution for applications
gems_root = $LOAD_PATH.detect{ |p| %r{/bundler-} =~ p}.sub(%r{/bundler-.*}, "")
additional_gems = {
"pry" => "pry-0.10.1/lib",
"pry-rails" => "pry-rails-0.3.2/lib",
}
load_paths = additional_gems.values.map{ |p| File.join gems_root, p }
$LOAD_PATH.unshift *load_paths
additional_gems.keys.each{ |r| require r }
If you're using Rails, then save it in /config/initializers/00_custom_gems.rb and that's all. Outside Rails you additionally need to require it, preferably right after require "bundler/setup":
require "path/to/it" if File.exists? "path/to/it"
Remember to mention this file in .gitignore.
Sometimes proper gem path does not end with /lib but with architecture name. The easiest way to learn it is to add it for a moment to Gemfile and do puts $LOAD_PATH in aforementioned initializer. You can also learn those dirs from gemspec.
Solution for gems
When developing gem, you don't need to enhance $LOAD_PATH, only to require gems you want. If you need custom gems in tests and you're using RSpec, it can be done somewhere in /spec/support.
Another (less sane) idea is to add a file lib/development.rb:
require_relative "my_gem_name"
require "path/to/private/requires" if File.exists? "path/to/private/requires"
and refer to this file instead of to "my_gem_name" in your tests, demo application etc..