Can anyone explain me or give me a resource where I can learn the differences between rails console and bundle console? Is there way to load all the gems automatically in irb instead of require gem?
Here is a good explanation: What's the Difference Between irb, bundle exec irb, bundle console, and rails console?
irb is the basic Ruby console. It ignores your Gemfile, and only core
Ruby classes are accessible without require-ing them. It can’t easily
load gems that Bundler installs outside of RubyGems’ load path.
bundle exec irb is like irb, if you also required bundler/setup. You
can only easily require gems that are in your Gemfile.lock, but you
can load those gems no matter where Bundler put them.
bundle console is like bundle exec irb, if you also called
Bundler.require. All of the gems in your Gemfile, except the ones
marked require: false, can be used without requiring them. It’s really
convenient when you’re writing your own gems, or working on non-Rails
code.
rails console is like running bundle console inside a Rails app, if
you also required config/environment.rb. You can play with your entire
Rails app, autoloads and database connections work, and everything’s
hooked up the way you’d expect. If you’re working in a Rails app, this
is the most helpful kind of console.
The answer from Aleksandr is great.
I just wanted to add there is also the option for running
bundle exec rails console
which combines everything from rails console and bundle exec irb answer from Aleksandr's answer.
Related
I want to use Jupyter notebooks as my rails console, exactly like django-extensions allows via shell_plus --notebook in Django.
Any ideas how to do this?
I saw this post which seems to be explaining how to do what I want, but I don't read Japanese or really understand what's going on here.
I created this gem to automatically do the things needed for running rails c on jupyter:
https://github.com/Yuki-Inoue/jupyter_on_rails
Add to your Gemfile:
gem 'jupyter_on_rails'
gem 'ffi-rzmq'
run bundle install, and then run:
rake jupyter:notebook
jupyter is now running and will have a kernel named to your Rails app, and it'll automatically load the Rails app on initialization.
require 'RAILS_ROOT_PATH/config/boot'
require 'RAILS_ROOT_PATH/config/application'
Rails.application.require_environment!
I'm currently using Ruby 2.3.0, Rails 4.2.6 and Jupyter 1.0.0. With this configuration all you have to do is require your Rails application's config/application:
require 'path/to/rails/application/config/application'
When I run a rails console using
rails console
everything is fine.
When I run a rails console using
bundle exec rails console
I get the following warning
Bundler is using a binstub that was created for a different gem.
This is deprecated, in future versions you may need to `bundle binstub my_gem` to work around a system/bundle conflict.
my_gem happens to be a gem that I've created that is completely unrelated and not used in the current project directory.
I've tried every solution in this question with no luck:
Bundler is using a binstub that was created for a different gem
I would appreciate any guidance on removing this warning or help understanding how binstubs work so that I can figure out what's going on.
Nowadays it's common for projects to have "specialized" versions of tools. E.g. in some projects the "rails" command may be expected to be run using "spring" (to start up faster).
So it's not uncommon to generate files in your project's 'bin' directory, and then use those versions when running commands, so e.g. instead of
bundle exec rails console
or
bundle exec spring rails console
you could simply expect the following to work correctly
bin/rails console
and not care whether the project needs spring or bundler or zeus or whatever.
So if you don't have 'bin/rails' in your project, you should generate one that suits the project, e.g. using
bin/rake rails:update:bin
If you don't already have bin/rake, you might have to use
bundle exec rake rails:update:bin
(so your bin/rake commands will also get a speedup from using spring)
Some people even put ./bin in their paths, so whenever they run rake (or whatever) they are actually running ./bin/rake if it exists.
Troubleshooting
for project specific tasks, use bin/* files, creating them if needed (e.g. using special rake tasks like in Rails or using bundle binstub <gemname>) - usually those have Bundler specific lines that will make Bundler happy.
for non-project gems (like your gem), find out where it is (e.g. which mygem) and check out it's contents - it's probably using e.g. "bundler/setup" which is confusing Bundler (because bundler expects a local Gemfile file). Maybe your gem is using bundler (it shouldn't if it's a "global" kind of tool and not a "project" tool).
Also, if you're using them, check if tools like RVM and .rbenv are correctly adding their stuff to your bin files (they usually need to setup specific paths)
If you still have questions, it's best to post the contents of the bin file causing problems - it's meant to be a plain Ruby file, so if there's something wrong, it's usually because of the file contents (and not anything else).
More info: https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
It happened in a project of mine. Because I ran bundle install with another ruby version.
Make sure your rvm is the correctly ruby version.
What is the major difference between running the rake command with and without bundle exec?
I have seen few posts stated that when you run the command with bundle exec then it will be run on scope of the gems version defined in the gem file. If that is the case, then it should be mandatory to run rake command with bundle exec?
bundle exec rake some:task runs the rake task within the context of your bundle.
You didn't explicitly mention Rails but i see you're post is tagged with Rails so a contrived example of this in action might be the following:
You have version 2.0 of the fictitious whateva-whateva gem installed on your system for some valid reason.
You decide you want to pull down an old Rails project from somewhere to check it out and run bundle install within the cloned project's root folder. That command will install all of the gems that the Rails app requires and one of them happens to be verison 1.0 of the fictitious whateva-whateva gem.
So the current state is this: your old rails app has a gem bundle that includes an older version of the whateva-whateva and your systemwide gems include a newer version of the whateva-whateva gem.
When you run rake tasks associated with your Rails app, which version do you want loaded? The older one of course.
In order to do this you can use bundle exec rake the:task and it runs the rake command within the context of your bundle -- the older version of the gem plus whatever other stuff was specified in the old rails app's Gemfile.
So yeah after all that, i think it's safe to say that BEST practice would be that you should always prepend bundle exec but to be honest I'm pretty lazy and rarely do it unless I see problems.
In other news, if you use Bundler's binstubs you don't need to add it. Here's a link to setting that up: https://thoughtbot.com/blog/use-bundlers-binstubs
BUNDLE_GEMFILE=/path/to/gemfile bundle exec can be used to precede any command (if BUNDLE_GEMFILE is not specified it searches up the file system and uses the first one it finds), not just rake.
Any command you run may invoke executable Ruby commands (such as rake) or require code from Ruby libraries (such as the Rake::Task class), and these things are typically provided by gems. gem env tells you where the gem-provided libraries and executables are. However if you use bundle exec it restricts the available gems to those specified in the Gemfile.lock file associated with the Gemfile your bundle exec context is using.
Using all the available gems on your machine (which can happen if you don't do bundle exec) can be undesirable for a couple reasons:
You may have incompatibilities in your full gem set.
It's harder to tell exactly what gems you're using, adding some unpredictability to your working environment.
Here's a quick way to see the difference.
gem install thin
Create a directory foo with two files: an empty Gemfile and a file foo.rb with the contents:
#! /usr/bin/ruby (or whatever the path to your system Ruby is)
require 'thin'
Make foo.rb executable.
Note that running thin and ./foo.rb from the command line both work, but preceding either with bundle exec will not work.
If you use bundle exec before any command in rails, It will search for the Gems Which are mentioned in our Gemfile, in application home folder.
Suppose, You have 2 applications, and using different ruby versions for each of them.
Without bundle exec the command might be failed to run, as it may take different version Gem to run that task. But If you start using bundle exec It will take the exact gem version to run the task/application.
I recommend you to use **bundle exec** before any command.
bundle-exec - Execute a command in the context of the bundle
This command executes the command, making all gems specified in the Gemfile(5) available to require in Ruby programs.
It's not for the only rake, instead applicable for rails, rspec, rackup command too.
Essentially, if you would have normally run something like rspec spec/my_spec.rb, and you want to use the gems specified in the Gemfile(5) and installed via bundle install(1), you should run bundle exec rspec spec/my_spec.rb.
Note that bundle exec does not require that an executable is available on your shell's $PATH.
For more detail, have a look to bundle exec doc.
I need to get the current working directory of a gem from within a Rails application.
I currently use
`bundle show foo`.strip
This works great in my environment, but:
it's slow because it requires loading a shell
it will probably break when somebody tries to run the app on Windows or on JRuby or when their $PATH points at a different ruby than the one used to start the app
So I'd like a way to do this without invoking a subshell.
The RDOC for Bundler hasn't been helpful. You used to be able to get this sort of information from Rails itself in Rails 2, but it appears that Rails 3 lets Bundler handle it.
If a gem is in your Gemfile/Gemfile.lock, its path appears in the $LOAD_PATH global variable. You can take advantage of this fact:
$:.grep(/activerecord/).first
$: is the same as $LOAD_PATH. You can use either.
Another approach:
Bundler.load.specs.find{|s| s.name == 'activerecord' }.try(:full_gem_path)
I am currently developing a standalone ruby application alongside a Rails application that works as its frontend. I am managing the dependencies of the Ruby app with Bundler, so there are two gemfiles.
I have a problem trying to execute the Ruby application from the Rails frontend via a system call to a rake task.
When I call the rake task from a standard IRB, it works; but if I try to call the task from a Rails controller or the rails console, dependency issues arise.
As a workaround I can add all the gems not present in the Rails application to the Rails Gemfile, but I guess this approach is wrong.
I think it might be a problem with the scope of Bundler. How could I work around this problem?
Thanks.
fork do
Dir.chdir("/your/project/dir")
ENV['BUNDLE_GEMFILE'] = File.expand_path('../Gemfile', __FILE__)
Bundler.setup
exec "rake -T"
end