This is happening in Puppet's bundle.
The Gemfile specifies
gem "puppet", :path => File.dirname(__FILE__), :require => false
But one of the gems I installed in $GEM_HOME appears in $: after all.
$ bundle exec ruby -e 'puts $:'
...
/home/puppy/puppet-git-clone/lib
...
/usr/lib/ruby/vendor_ruby
...
/home/puppy/gems/gems/puppet-3.7.5/lib
...
This is not a problem in and of itself, but apparently Ruby will load Puppet 3.7.5 instead of the 3.7.3 I checked out of the git repo.
$ bundle exec irb
irb(main):001:0> require 'puppet'
=> true
irb(main):002:0> Facter.value(:puppetversion)
=> "3.7.5"
Why is Puppet not loaded from the git tree and how can I debug this further?
Update
Puppets .gemspec might be involved. It's clever about specifying the version. I now worry that Rubygems does in fact load the installed 3.7.5 gem so that Puppet.version would truthfully report a wrong value, throwing off bundler. Could that be what's happening?
Update 2
As suggested in the comments, I tried settings the path and version statically in the Gemfile.
gem "puppet", "3.4.2", :path => "/home/puppy/puppet-git-clone", :require => false
As for the result, well - at least bundler is consistent in its views ;-)
Could not find gem 'puppet (= 3.4.2) ruby' in source at /home/ffrank/git/puppet.
Source contains 'puppet' at: 3.7.3
Run `bundle install` to install missing gems.
The quick fix is to add -Ilib to your ruby command:
$ bundle exec ruby -e "require 'puppet'; puts Facter.value(:puppetversion)"
3.7.5
$ bundle exec ruby -Ilib -e "require 'puppet'; puts Facter.value(:puppetversion)"
3.7.3
If we compare the load paths, you can see that adding -Ilib results in 3.7.5 not being present in the second load path:
$ diff <(bundle exec ruby -e 'puts $:') <(bundle exec ruby -Ilib -e 'puts $:') | grep 'puppet-'
< /Library/Ruby/Gems/2.0.0/gems/puppet-3.7.5/lib
It seems like this should be the default behavior, so there may be a bug in bundler.
Provided you've deleted your Gemfile.lock and removed all other versions of the gem before trying bundle exec ... although not explicitly defined by the same problem, this is a known problem with Bundler check this out:
https://github.com/bundler/bundler/issues/3585
And it ought to be fixed as of this merged Pull Request:
https://github.com/bundler/bundler/pull/3592
This will cause your "preferred source" to be favored, and used.
( Links used as answer because this refers to existing activities, not a solution I could put here in the answer. Not link-only answer. )
try this :
source "file://home/puppy/puppet-git-clone"
gem "puppet", "3.4.2", :path => "/home/puppy/puppet-git-clone"
why do you need require false?
After what you said in my previous answer, try this:
Add gemspec to your Gemfile near the top.
If you do this, the subsequent gem ... calls will override the gemspec which is ultimately setting the version.
Add it right here:
source ENV['GEM_SOURCE'] || "https://rubygems.org"
gemspec # and let me know if this fixes it
Like I recently said, I found the same problem you had, in my own projects. And I've solved it by a workaround. The idea itself is what I'm giving here, I'm not saying it's the most efficient or bug-free way. A variation of this approach worked for me.
It involves hijacking Gemfile and perhaps gemspec, depending on what's the offender in reality -- that part is still unknown. My most recent answer, the second approach I gave could solve this already. If not, you may need a workaround. There are many standing impasses for Bundler.
As a work around, insert a curator.
I suggest, at the end of Gemfile you insert a processor such as this one, to curate Bundler::Dsl yourself. We can focus completely on the gem you're looking to resolve, but it could be done for any and all gems.
For example... this is mostly a concept, it may run, but it may have a bug. You will need to harden it. This will remove everything but the version you expect:
PUPPET_VERSION = 'version desired'
until(current = self.dependencies.find { |d| d.name == 'puppet' }) == 1
current.each { |gem|
if !gem.version == PUPPET_VERSION
self.dependencies.delete(current)
end
}
end
I'm not sure which version you actually want. There are three versions mentioned, 3.7.3, 3.7.5 ... just plug in the one you do want. Any other versions will be purged from the dependencies Bundler is working with.
I had the same problem in past, I think you can specify your gem without the 'require: false' parameter and it will look for the Gemfile specific version.
gem "puppet", "3.4.2", :path => "/home/puppy/puppet-git-clone"
If you specify the 'require' option with 'gem' and run the irb command with bundle exec irb it always load the latest version for the gems which has declared with require: false option.
Related
If I have a local gem (gemfile.gem) how can I get the name and version information from code or the command line without installing the gem.
Reason: I'm installing a user gem to validate it and want to uninstall it to clean up. User gem is not something I control so I can't depend on naming conventions.
CLI Solution:
gem spec gemfile.gem name
gem spec gemfile.gem version
Ruby Solution:
name = Psych.safe_load(`gem spec gemfile.gem name`).to_s
version = Psych.safe_load(`gem spec gemfile.gem version`, permitted_classes: [Gem::Version]).to_s
# Now you can uninstall the gem with
Gem::Uninstaller.new(name, {:version => version, :force => true}).uninstall
You can see locked version in Gemfile.lock
cat Gemfile.lock | grep gem-name
Other option, but need bundle install first
bundle exec gem dependency | grep gem-name
Update:
If you need to check local gem version, for example some-gem.gem, you can use such command to parse all information from binary
gem specification some-gem.gem
or just
gem spec some-gem.gem
You can also look it with Ruby format
gem spec some-gem.gem --ruby
Of course you can use grep to filter lines with version word
But it's better to pass it as argument like this
gem spec some-gem.gem version
Your question is ambiguous. If you mean "How can I read in the gem name and version from the gemspec?" then you can use the output of Gem::Specification#load. For example, assuming you have a gem with a standard layout and foo_bar.gemspec in the root of your gem's project directory, you can use Git to find the top-level of your project and read in the gemspec:
$ cd "$(git rev-parse --show-toplevel)
$ ruby -e 'puts Gem::Specification.load "#{File.basename Dir.pwd}.gemspec"'
#<Gem::Specification name=foo_bar version=0.1.0>
You can then parse the output with sed, awk, or cut.
A Gemfile does not (necessarily) specify an exact version of a dependency. It might specify nothing (i.e. "any version is fine"), or ~> 1.0 (i.e. >= 1.0 and < 2.0), or whatever. Also, dependency constraints might further restrict the valid range of versions.
I'm assuming that this isn't what you meant by your question. Instead, you'd like to know what exact versions of dependencies will be installed by running bundle install, given a Gemfile.lock.
One way to achieve this reliably (i.e. rather than using grep and eyeballing which line(s) are most relevant) is by parsing the Gemfile.lock:
require 'bundler'
lockfile = Bundler::LockfileParser.new(Bundler.read_file('Gemfile.lock'))
puts lockfile.specs.find { |spec| spec.name == 'the-gem-you-want-to-check' }.version
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. :-)
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
I have seen many
You have already activated rake 0.9.x, but your Gemfile requires rake 0.x.x
errors.
Of course, they can be solved (temporarily or always) by some methods like the following.
bundle exec rake
The method above works but you always have to type bundle exec.
It can also be solved by
bundle update
But bundle update also updates your other gems.
Some say it can be solved by
gem uninstall unwanted_rake_version
Yes, the unwanted rake can be installed but it is still marked as activated thus, still giving the error.
One solution would be to explicitly specify the rake version in your Gemfile but, that is not the question. It is on how to set the default rake version, or activate that specific version in rvm or other types of ruby installations?
The newer versions of rake can be activated by supplying an optional first argument, that is the gem version.
$ rake 0.9.2
Alternatively, if you have an older version of rake you can update the rake script manually to include this parameter (or specify any specific version you want).
The rake script usually lives in /usr/bin/rake (or ~/.rvm/gems/ruby-#{ruby-name}/rake if using rvm). And dictates the version of them gem to load before parsing paramaters.
It looks like this on my system.
$ cat ~/.rvm/gems/ruby-1.9.2-p180/bin/rake
#!/home/tomcat/.rvm/rubies/ruby-1.9.2-p180/bin/ruby
#
# This file was generated by RubyGems.
#
# The application 'rake' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'rubygems'
version = ">= 0"
if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
version = $1
ARGV.shift
end
gem 'rake', version
load Gem.bin_path('rake', 'rake', version)
The important bit is gem 'rake', version changing version will force rake to a specific version system/rvm wide.
For more info, Katz' article explains nicely how binaries run under rubygems
When I get that error, its usually a result of working between projects that depend on different versions of rake. An easy fix is
gem uninstall rake
And then in your project directory (assuming you're working with Bundler) simply
bundle
I always uninstall rake first, command like this:
gem uninstall rake -v=version
then install another version
gem install rake -v=version